The Mature Programmer(cbloomrants.blogspot.com)
cbloomrants.blogspot.com
The Mature Programmer
http://cbloomrants.blogspot.com/2011/11/11-22-11-mature-programmer.html
12 comments
But he's not arguing that at all! If you've read the entirety of the essay, he's saying that there has to be a balance between the needs of a job and the compulsion to have fun/showoff/be a hacker. (And he says it in one of the most reasonable ways possible.)
I think there's real value in this. After all, there's a real motivation to want to write amazing stuff to show off to your friends (e.g make them say "WTF how did you do that?"), as well as play with new technologies; and as an engineer you have to worry about a different set of important issues (e.g. is the project on time?/ what needs to be refactored?/what to bring up in the next team meeting?). He's arguing for a way to reconcile the two while at work, beyond just programming on personal projects on nights and weekends^[1]
^[1] And that's leaving out the section at the end where he argues about sticking to a set of engineering best practices, and not trusting yourself to be good enough to know when to break them.
PS: Also, see georgemcbay's comment http://news.ycombinator.com/item?id=3310114 on how the author knows what he's talking about.
I think there's real value in this. After all, there's a real motivation to want to write amazing stuff to show off to your friends (e.g make them say "WTF how did you do that?"), as well as play with new technologies; and as an engineer you have to worry about a different set of important issues (e.g. is the project on time?/ what needs to be refactored?/what to bring up in the next team meeting?). He's arguing for a way to reconcile the two while at work, beyond just programming on personal projects on nights and weekends^[1]
^[1] And that's leaving out the section at the end where he argues about sticking to a set of engineering best practices, and not trusting yourself to be good enough to know when to break them.
PS: Also, see georgemcbay's comment http://news.ycombinator.com/item?id=3310114 on how the author knows what he's talking about.
This is exactly why I still believe that what we do is not engineering. How long would a civil engineer be employed if he refused to use proven techniques and complained that he was not having enough fun on the latest bridge project? This nonsense might be fine for game development, but there is a great deal of software that affects people's lives. It is time for our profession to grow up.
I'm not certain we know enough about the domain to say the profession can grow up. We're still building bridges by placing downed trees across rivers. It works, well even, but we're still trying to build a multilane causeway and it is going to take a lot more trial and error to get there.
I believe it is a good thing that we have people working with all types of mentalities. People building software to power airplanes can use the downed tree and know it is going to work, even if it is not pretty and requires a lot of extra effort. People building web startups can experiment with the cutting edge technology and see how it fares, slowly passing the good back to the more conservative groups.
I think we're pretty lucky that we, as an industry, don't need to completely grow up. It keeps us constantly trying new ideas, some of which are good.
I believe it is a good thing that we have people working with all types of mentalities. People building software to power airplanes can use the downed tree and know it is going to work, even if it is not pretty and requires a lot of extra effort. People building web startups can experiment with the cutting edge technology and see how it fares, slowly passing the good back to the more conservative groups.
I think we're pretty lucky that we, as an industry, don't need to completely grow up. It keeps us constantly trying new ideas, some of which are good.
Completely agreed. Software engineering is not mature yet itself, so pretending to be all-mature about it by sticking to 30-year old rigid "best practices" can be counter-productive at best.
People sometimes forget that new techniques might be more robust and safe than old ones, as various insights have been gained over the years.
Your other point is also good. The technology to choose depends on the domain. Web startups and airplanes/weapons being the extremes. There is no feelgood overall advice that applies to everyone.
People sometimes forget that new techniques might be more robust and safe than old ones, as various insights have been gained over the years.
Your other point is also good. The technology to choose depends on the domain. Web startups and airplanes/weapons being the extremes. There is no feelgood overall advice that applies to everyone.
How long would a civil engineer be employed if he refused to use proven techniques and complained that he was not having enough fun on the latest bridge project?
That's actually a common aspiration! You can't experiment a lot in a low-level job, but lots of people in the bridge-engineering business wish they had more leeway to experiment with new solutions, even if it wasn't quite at the Frank-Lloyd-Wright or Calatrava level of experimentation. This usually gets blamed on the bifurcation between big-name-architect vs. just-implement-it civil engineer, splitting a role that was more historically integrated between the design/engineering. Also, some blame it on crushing layers of government bureaucracy/regulation.
That's actually a common aspiration! You can't experiment a lot in a low-level job, but lots of people in the bridge-engineering business wish they had more leeway to experiment with new solutions, even if it wasn't quite at the Frank-Lloyd-Wright or Calatrava level of experimentation. This usually gets blamed on the bifurcation between big-name-architect vs. just-implement-it civil engineer, splitting a role that was more historically integrated between the design/engineering. Also, some blame it on crushing layers of government bureaucracy/regulation.
This is also why you'll find bridges that are under capacity. Some engineer was experimenting with a design he didn't fully understand.
Come on. Citation please. That's a pretty wild assertion.
Interesting information, but it doesn't support the assertion made by parent that experimentation has (often, it seems implied) been the root cause of poor bridge design implementation.
The profession will grow up as the tools mature. The reason engineers don't use new flashy techniques for bridge building is that there isn't that much happening[].
[] For the standard everyday bridge. New techniques and solutions are tried out for exotic bridges - bridges for high speed trains and such.
[] For the standard everyday bridge. New techniques and solutions are tried out for exotic bridges - bridges for high speed trains and such.
Don't paint us all with one brush. I suspect there's a significant bias in observation here because it's the sexy, fun stuff that everyone hears about. There are lots of people taking the profession seriously, but many of them are behind corporate walls or just not focused on making their work look flashy.
I think the problem comes from defining what 'grown up' is, because in my experience it changes depending on who you ask (corporate employee vs consultant).
What an individual programmer or even a team does may not qualify as engineering, but the infrastructure that has evolved over the last 30 years provides something approaching the reliability of the Brooklyn Bridge.
One nice thing about software right now is an "engineer" can build on the code created by tens of thousands of other "engineers."
One nice thing about software right now is an "engineer" can build on the code created by tens of thousands of other "engineers."
I think domains are too different for this analogy to apply.
When building bridge civil engineer knows exatly the environment wher it will stand and pretty much knows all the likely variations of it.
Software engineer? Not even close. I'd argue, that sofware solutions are _more_ robust given all the uncertainty.
At the place I work, every other project is crashing and burning, and we use Java, Oracle, Struts, SOAP and the most serious, enterprise solutions with rock solid support you can think of.
When you're working overtime and you're working with old, boring, over-engineered technology, the only thing that's left is the joy of programming.
When you're working overtime and you're working with old, boring, over-engineered technology, the only thing that's left is the joy of programming.
Fuck the joy of programming.
Are you fucking kidding me? Motivation isn't something you can just ignore. If you aren't motivated to work, you will eventually either stop working or hate your job. (Why would you keep doing something you don't want to do?)
Maybe if you're working with good people and getting paid well it'll be ok, but in that case you're relying on the people around you to motivate you. You will be less productive and less happy for 40 hours a week than people who honestly love the work itself.
Are you fucking kidding me? Motivation isn't something you can just ignore. If you aren't motivated to work, you will eventually either stop working or hate your job. (Why would you keep doing something you don't want to do?)
Maybe if you're working with good people and getting paid well it'll be ok, but in that case you're relying on the people around you to motivate you. You will be less productive and less happy for 40 hours a week than people who honestly love the work itself.
"Are you fucking kidding me? Motivation isn't something you can just ignore. If you aren't motivated to work, you will eventually either stop working or hate your job. (Why would you keep doing something you don't want to do?)"
I most certainly am not kidding you. You want to talk about motivation? How's a mortgage, a wife, a car payment and a kid on the way for motivation?
I'd take a job at McDonalds if that's what it took to keep my family afloat, and while I'm in a position where I do frequently enjoy the work, I've had plenty of jobs I didn't enjoy. Simply put, whether or not I'm having fun at any given moment isn't really relevant. Paying the bills is.
I most certainly am not kidding you. You want to talk about motivation? How's a mortgage, a wife, a car payment and a kid on the way for motivation?
I'd take a job at McDonalds if that's what it took to keep my family afloat, and while I'm in a position where I do frequently enjoy the work, I've had plenty of jobs I didn't enjoy. Simply put, whether or not I'm having fun at any given moment isn't really relevant. Paying the bills is.
The problem is, when you have 20 people of varying abilities hacking away for their own definition of the "joy of programming" on a project, it has a tendency to collapse under its own weight.
When you've only every worked on greenfield projects, or are working on a start-up who's only aim is to sell up before they explode, then yeah, code for fun. Just make sure that you're not expected to support it for 5+ years.
When you've only every worked on greenfield projects, or are working on a start-up who's only aim is to sell up before they explode, then yeah, code for fun. Just make sure that you're not expected to support it for 5+ years.
well, outside the startup community, there is a whole world of people who work a boring job so they can raise a happy family, or play with powerboats, or whatever. less productive, sure, but nobody really cares outside of a meritocracy. and who are we to say they are less happy.
> boring job
and
> who are we to say they are less happy
Well, it's fairly uncontroversial and trivial to my mind that a less boring workday makes for the happier employee, and happier employees make for happier people -- ergo, it can be safely said that to the same extent someone works a boring job, they are that much less happy than the person who works a non-boring job. It's not a matter of unjustified judgment at all -- who the hell doesn't want a job that instills a sense of self-fulfillment?
and
> who are we to say they are less happy
Well, it's fairly uncontroversial and trivial to my mind that a less boring workday makes for the happier employee, and happier employees make for happier people -- ergo, it can be safely said that to the same extent someone works a boring job, they are that much less happy than the person who works a non-boring job. It's not a matter of unjustified judgment at all -- who the hell doesn't want a job that instills a sense of self-fulfillment?
[deleted]
How old are you? Because usually when I hear this speech, it's coming from some 25 year-old who gets a couple of years of experience under his belt and is convinced that qualifies him as a wise old programmer who can condescend to all those younguns who don't know how to build a program (regardless of whether they actually are younger or less experienced than him).
Guess what? People want their jobs to be fun. Maybe you're a robot who only cares about the most efficient way to build a product, but I'm not. And I'm not going to apologize for wanting to build a stable and fun to build product.
Guess what? People want their jobs to be fun. Maybe you're a robot who only cares about the most efficient way to build a product, but I'm not. And I'm not going to apologize for wanting to build a stable and fun to build product.
"How old are you?"
36.
"Because usually when I hear this speech, it's coming from some 25 year-old who gets a couple of years of experience under his belt and is convinced that qualifies him as a wise old programmer who can condescend to all those younguns who don't know how to build a program (regardless of whether they actually are younger or less experienced than him)."
Cool story, bro.
"Guess what? People want their jobs to be fun."
People want all kinds of shit. Some get what they want, other's don't. What's up with this over-emphasis on being entertained at all times?
"Maybe you're a robot who only cares about the most efficient way to build a product, but I'm not. And I'm not going to apologize for wanting to build a stable and fun to build product."
Touchy much? Seriously who asked you to apologize for anything? Do you have a track record of blowing up multi-million dollar projects? Or writing "clever" shit that blows up, resulting in a bunch of overtime and/or after-hours pages?
36.
"Because usually when I hear this speech, it's coming from some 25 year-old who gets a couple of years of experience under his belt and is convinced that qualifies him as a wise old programmer who can condescend to all those younguns who don't know how to build a program (regardless of whether they actually are younger or less experienced than him)."
Cool story, bro.
"Guess what? People want their jobs to be fun."
People want all kinds of shit. Some get what they want, other's don't. What's up with this over-emphasis on being entertained at all times?
"Maybe you're a robot who only cares about the most efficient way to build a product, but I'm not. And I'm not going to apologize for wanting to build a stable and fun to build product."
Touchy much? Seriously who asked you to apologize for anything? Do you have a track record of blowing up multi-million dollar projects? Or writing "clever" shit that blows up, resulting in a bunch of overtime and/or after-hours pages?
I don't disagree with this in general, but the tricky thing about programming is that there is often more than one legitimate way to accomplish any given goal. And, in many cases, the established practice is significantly more cumbersome than some of the alternatives. For instance, all the developers that cast off J2EE for Rails were certainly disregarding common wisdom, but in many cases wound up saving their employers time and money by bucking the trend.
I know I was at least 5x as productive in Rails as I had been in Java/Tapestry, but at the time (Rails 0.8) if could have easily been argued that I was making selfish technology choices.
I know I was at least 5x as productive in Rails as I had been in Java/Tapestry, but at the time (Rails 0.8) if could have easily been argued that I was making selfish technology choices.
There's a difference between using a new technology and being clever. I've seen clever -- I've been clever. I've seen the "immature" dev who comes in and says, "So here I've written a dynamic binary interpreter that will inject into all known JS engines which will give me the ability to modify stackframes of the running Javascript program. So in scenarios where I write this code in JS, part of which will block a DCE, because I need a specific value on the stackframe, I can now access this below in Javascript. How you ask? With inline assembly in JS -- which I've also added. So now you can create a wide range of selectors."
"Like doing this common technique from jQuery?"
"Sure, if you want to suck the life out of programming you'll use that, but I prefer to keep my job fun. BTW, this will break on every rev of Chrome, so I have an alert set up to remind me to fix it for each new version. Anyways, I already checked it in. See you in three weeks, I'm going on that vacation I forgot to tell you about."
"Like doing this common technique from jQuery?"
"Sure, if you want to suck the life out of programming you'll use that, but I prefer to keep my job fun. BTW, this will break on every rev of Chrome, so I have an alert set up to remind me to fix it for each new version. Anyways, I already checked it in. See you in three weeks, I'm going on that vacation I forgot to tell you about."
And for certain use cases that is good. However I wonder how many of those who did so were even aware of what the costs of moving to a solution which doesn't really readily support (and indeed actively discourages) solid database engineering would be when moving forward into new markets. Indeed the same thing is going on with a lot of NoSQL adoption and I think a lot of people are going to be badly bitten by choosing it without really understanding what the tradeoff is.
My own view is that ideal design processes in fact look at the established practices sympathetically before disregarding them. Where they are not applicable, they should be disregarded.
My own view is that ideal design processes in fact look at the established practices sympathetically before disregarding them. Where they are not applicable, they should be disregarded.
To be honest if Rails is capable of replacing J2EE for your application, then you were working on a toy.
That's all part of the architectural choice: if you're building a toy, then you don't to build it with an industrial class framework.
I've had the experience in reverse: working on a system built on a toy framework which started to fall to pieces the second it became obvious* that it required industrial level tooling. In that case it lead to irreplaceable data loss.
* It was obvious to me from the start that an Enterprise-level framework was required. I got the hint from the 30-page auditing requirements specification.
That's all part of the architectural choice: if you're building a toy, then you don't to build it with an industrial class framework.
I've had the experience in reverse: working on a system built on a toy framework which started to fall to pieces the second it became obvious* that it required industrial level tooling. In that case it lead to irreplaceable data loss.
* It was obvious to me from the start that an Enterprise-level framework was required. I got the hint from the 30-page auditing requirements specification.
Oh come on. The evidence that tech like Rails can be used to build non-toy apps is abundant. When shops like Thoughtworks are bailing on Java for Ruby you know you can no longer shut down rational discussion of choices with weasel words like "toy" and "enterprise class". Rails is not the hammer for every nail but it wasn't long ago that doing the "right" thing meant pounding in every nail with a walrus like J2EE.
I think it's interesting that the emphasis on defending something like Rails is based on a comparison to J2EE. My real gripe with Rails is about how it disparages good enterprise-class database practices, and so this is why I'd call it a "toy" system.
That doesn't mean you can't do interesting things with it, but rather that you are essentially talking about an application closely tied to the db schema it stores its data in. The idea of enterprise-class applications sharing their data in a common database is something entirely foreign to (and incompatible with) the Rails way.
This doesn't mean it can't be used in an enterprise environment. For example, you could have a Rails/MySQL app with data imported periodically into a PostgreSQL multi-application database, but I wouldn't call the former "enterprise-class."
That doesn't mean you can't do interesting things with it, but rather that you are essentially talking about an application closely tied to the db schema it stores its data in. The idea of enterprise-class applications sharing their data in a common database is something entirely foreign to (and incompatible with) the Rails way.
This doesn't mean it can't be used in an enterprise environment. For example, you could have a Rails/MySQL app with data imported periodically into a PostgreSQL multi-application database, but I wouldn't call the former "enterprise-class."
> When shops like Thoughtworks are bailing on Java for Ruby
They're swapping Java for Ruby, not Java for Rails.
Ruby is, performance aside, a really nice language. It's certainly possible to build something "enterprise class" in Ruby. Especially as soon as you start treating Ruby as a meta-language and build your own DSLs in it
Rails on the other hand isn't really enterprise grade. It's constrained by Active Record, and the immaturity (and lack of popularity) of the alternatives.
They're swapping Java for Ruby, not Java for Rails.
Ruby is, performance aside, a really nice language. It's certainly possible to build something "enterprise class" in Ruby. Especially as soon as you start treating Ruby as a meta-language and build your own DSLs in it
Rails on the other hand isn't really enterprise grade. It's constrained by Active Record, and the immaturity (and lack of popularity) of the alternatives.
A codebase that I can ramp up on in 2 days is a well made codebase, not a boring codebase. Byzantine Java codebases that use an ancient version of struts and reams and reams of useless badly design xml configuration files are boring and take forever to ramp up on.
Younger people dislike C++ and Java codebases not because they're boring, but because they come with reams and reams of badly designed verbose crap that takes forever to learn and wastes everybody's time. They don't have to be, but statistically they do more often than not.
Younger people dislike C++ and Java codebases not because they're boring, but because they come with reams and reams of badly designed verbose crap that takes forever to learn and wastes everybody's time. They don't have to be, but statistically they do more often than not.
I don't read him advocating "fun" programming but describing some mental traps many of us have fallen into. "the correct adjustment for post-mature coding is very small" sounds very much like understanding the principles behind good practices and knowing the rare cases when it's reasonable to deviate from the practices because of the underlying reasons.
I read him mostly as saying "don't take this so far that it kills the creative spark" which is a very good caution.
I think risk management [1] is the best way to approach these decisions. When evaluating a tool/technique you're whose tradeoffs you're not entirely familiar with, simple rejectionism can kill you later with the poor maintainability and complexity of the toolset you just happened to currently be more familiar with.
Sensible risk management means you have fallbacks when a particular risk doesn't work out, while reaping the benefits of your speculative investments.
That said, while I don't like simple rejectionism (and probably would not tolerate such an environment for long), it's probably a lot better than teams which say Yes way too readily.
(Also, I question the actual cleverness of so-called "clever" ideas. Clever as in the random pun that took a fraction of a sec to think up, or clever as in the good hack that cuts the gordian knot?)
[1] http://howwework.thinkrelevance.com/stakeholder_narrative.ht...
Sensible risk management means you have fallbacks when a particular risk doesn't work out, while reaping the benefits of your speculative investments.
That said, while I don't like simple rejectionism (and probably would not tolerate such an environment for long), it's probably a lot better than teams which say Yes way too readily.
(Also, I question the actual cleverness of so-called "clever" ideas. Clever as in the random pun that took a fraction of a sec to think up, or clever as in the good hack that cuts the gordian knot?)
[1] http://howwework.thinkrelevance.com/stakeholder_narrative.ht...
I bet IBM is full of mature programmers.
Market cap $225B. I'm sure it is.
I will say IBM is run on sticking to procedures and tried and true methods. It may not be the most inspiring workplace, but it gets things done. I can't say it's what I prefer, but just a bit of insight. This doesn't apply to all subsidiaries, teams, and groups, but by and large this is what I see.
I'm going to disagree with "getting things done". Three words: IBM Global Services.
Well, spent the first 3 years of my life and literally fell sick at being treated like kid playing with fire..:-P.. a master's degree,1yr in a startup and 1 year freelancing later am just beginning to find some semblance of balance between the pressures..
I should say, within any one team working on something these procedures are used to get things done. I don't speak for the company as a whole but this seems to be the precedent for most.
You take that attitude to almost any other job, and you'll quickly will be told to leave.
The joy of being a professional, well paid developer is in creating the product, not the code. The joy of programming for programming's sake is something you do in your own time. Sure, any smart company will reserve work time for that, but not in the middle of building a product.
Same goes for the "healthy" opposition of a producer. If you need to be managed like that, please fuck off back to the playground, and don't dare call yourself "mature".
Most of this article reflects a "we are such special an unique snowflakes, we don't need to take responsibility for the consequences of our actions" that has become all too common in our business.
I'm all for spending truckloads of money on getting programmers the best tools and work-environment with all the nice toys, and giving them all the freedom in the world to do their job in any way they are most comfortable with. But the one thing I expect from them in return is to take responsibility for delivering results. Not to fuck around and be creative and "artistic" at the expense of those who are signing their paychecks.
The joy of being a professional, well paid developer is in creating the product, not the code. The joy of programming for programming's sake is something you do in your own time. Sure, any smart company will reserve work time for that, but not in the middle of building a product.
Same goes for the "healthy" opposition of a producer. If you need to be managed like that, please fuck off back to the playground, and don't dare call yourself "mature".
Most of this article reflects a "we are such special an unique snowflakes, we don't need to take responsibility for the consequences of our actions" that has become all too common in our business.
I'm all for spending truckloads of money on getting programmers the best tools and work-environment with all the nice toys, and giving them all the freedom in the world to do their job in any way they are most comfortable with. But the one thing I expect from them in return is to take responsibility for delivering results. Not to fuck around and be creative and "artistic" at the expense of those who are signing their paychecks.
Here's the thing:
Thinking through design criteria, trying to perfect them, asking all these small questions can be a joyful, creative act in itself. I think it's great when good developers can engage in heated debate as to which is the most solid design, backing away from the desire to be buzzword compliant and come up with a solid design.
In the end, I'd rather write code people looked at and said "That's elegant" than code that people looked at and said "that's clever."
This being said, if you don't realize that all of this is a creative endeavor then things will be formalized to the point of killing that creative spark.
I do think coding standards exist for a reason, but also that they should be no longer than necessary. Indeed, one issue with writing long coding standards is that usually they are a form of premature optimization ;-)
Thinking through design criteria, trying to perfect them, asking all these small questions can be a joyful, creative act in itself. I think it's great when good developers can engage in heated debate as to which is the most solid design, backing away from the desire to be buzzword compliant and come up with a solid design.
In the end, I'd rather write code people looked at and said "That's elegant" than code that people looked at and said "that's clever."
This being said, if you don't realize that all of this is a creative endeavor then things will be formalized to the point of killing that creative spark.
I do think coding standards exist for a reason, but also that they should be no longer than necessary. Indeed, one issue with writing long coding standards is that usually they are a form of premature optimization ;-)
I think you'll find the same attitude quite commonly among mathematicians. Some suppress it more than others, but fundamentally a large proportion of mathematicians would much rather come up with the interesting, elegant solution, even if it takes longer, than bang out a business-relevant boring/ugly solution. And when the opportunity arises, many do so...
A friend of mine described it as something like (paraphrasing, I think it was more eloquent originally): my job is using mathematics to serve [corporation], but my religion is using [corporation] to serve mathematics.
A friend of mine described it as something like (paraphrasing, I think it was more eloquent originally): my job is using mathematics to serve [corporation], but my religion is using [corporation] to serve mathematics.
I'm actually surprised that anyone could disagree with the OP, other than to nitpick. I found most of what he said to be so obviously true as to go without even saying.
Maintainable code is elegant code. Too much emphasis on the straightest line to results results in inelegant code, full of boilerplate, which becomes progressively harder to maintain. The line between elegant reusable libraries and impenetrable abstractions, however, is a fine one, and figuring out where that line is doesn't come without engineers who are willing to experiment a bit and refactor when they were wrong. Understanding of the tools and language features that allow the creation of elegant reusable libraries doesn't come without experimenting with them. Those who don't strive to continually learn new things and grow their skills become jaded with what they are doing, and eventually end up unengaged and consequently less productive, or they go do something else instead. There's a reason that the half-life of being a software engineer is 15 years. (Assuming the 15 year half-life story is true. It sounds about right to me.)
Maintainable code is elegant code. Too much emphasis on the straightest line to results results in inelegant code, full of boilerplate, which becomes progressively harder to maintain. The line between elegant reusable libraries and impenetrable abstractions, however, is a fine one, and figuring out where that line is doesn't come without engineers who are willing to experiment a bit and refactor when they were wrong. Understanding of the tools and language features that allow the creation of elegant reusable libraries doesn't come without experimenting with them. Those who don't strive to continually learn new things and grow their skills become jaded with what they are doing, and eventually end up unengaged and consequently less productive, or they go do something else instead. There's a reason that the half-life of being a software engineer is 15 years. (Assuming the 15 year half-life story is true. It sounds about right to me.)
"The line between elegant reusable libraries and impenetrable abstractions, however, is a fine one, and figuring out where that line is doesn't come without engineers who are willing to experiment a bit and refactor when they were wrong."
Hence my point about design being a creative act in itself, and where a lot of the joy really is to be had. Anything can be formalized to the point of killing the creative spark, but generally a mature approach to software development, but one which recognizes the fact that not only should we not get away from programming as a creative act of design but that in fact no matter how we try we cannot do so anyway is the best approach IMO
Hence my point about design being a creative act in itself, and where a lot of the joy really is to be had. Anything can be formalized to the point of killing the creative spark, but generally a mature approach to software development, but one which recognizes the fact that not only should we not get away from programming as a creative act of design but that in fact no matter how we try we cannot do so anyway is the best approach IMO
The irony of your reply is that this is probably what he would have said (or anyone else writing this blog entry) 10 years ago. The point of view he is writing from is 10 years later...
I am not explicitly saying that you would for sure agree with him 10 years from now, but I want to at least suggest it's a possibility.
For what it's worth, I run a software company, in which I sign paychecks, and I think what is said in this posting is pretty smart.
I am not explicitly saying that you would for sure agree with him 10 years from now, but I want to at least suggest it's a possibility.
For what it's worth, I run a software company, in which I sign paychecks, and I think what is said in this posting is pretty smart.
(In case it is not crystal clear, the whole point of the article is that he used to be a Mature Programmer a while ago, and is now in a post-Mature-Programmer phase.)
[deleted]
I couldn't agree more
Lots of negative reactions here, some of which might be coming from extrapolation.
I'm reading his main points as:
1) Enthusiasm can be as important to productivity as adherence to "best practices." Doing something fun/interesting feeds enthusiasm.
2) It can be helpful to have someone else taking on the cognitive load of managing the project.
3 & 4) Offloading decisions to conventions and heuristics can also reduce your cognitive load, even when you're an expert who knows when/why to depart from them.
Still seem controversial?
I'm reading his main points as:
1) Enthusiasm can be as important to productivity as adherence to "best practices." Doing something fun/interesting feeds enthusiasm.
2) It can be helpful to have someone else taking on the cognitive load of managing the project.
3 & 4) Offloading decisions to conventions and heuristics can also reduce your cognitive load, even when you're an expert who knows when/why to depart from them.
Still seem controversial?
I disagree to reduce programmers to geeks that only have fun when there is a ton of new technology and a fancy feature that only they like.
Most people I've worked with have fun when the project goes well, customers are happy and the like.
A really post-mature programmer understands the values behind so that he does not need rules any more.
A really post-mature programmer understands the values behind so that he does not need rules any more.
Exactly. There is much joy to be derived from a codebase that works, that is maintainable, and that is understandable.
And yet again a 10 year old article[1] from Spolsky captures most of the rants in both the post and the comments. What works for a game developer does not necessarily work for an internal cooperate developer.
[1] http://www.joelonsoftware.com/articles/FiveWorlds.html
[1] http://www.joelonsoftware.com/articles/FiveWorlds.html
Fantastic article! I'd forgotten about that one.
I would like to think that there's a happy medium between these extremes, especially considering that cleverness is not necessarily equal to incomprehensibility. Choosing the best tool for the job and writing clean code can be just as satisfying as writing clever code, and the two are not self-exclusive. I think one can take joy in writing quality software - one that works, one that does its job, and one that other people can understand and extend.
I think that was actually his point.
I would say that the mature programmer has learned that there is only one priority, UX, and that code must be built in the way that helps the user most. Depending on the use case, it can be pretty or ugly, fun or boring, oo or procedural. Sometimes the best choice is even to refuse to write a piece of code at all. Sometimes the best solution doesn't involve a computer.
That may have been fun for him to write, it wasn't fun to read. Given his attitude, I wonder if the same could be said of his code.
I read this as "A mature programmer mangles their time and productivity well"
The first comment is teh awesome.
http://cbloomrants.blogspot.com/2011/11/11-22-11-mature-prog...
http://cbloomrants.blogspot.com/2011/11/11-22-11-mature-prog...
I have to object to this blog. While some points I agree with, this is more formulaic drivel where some self absorbed person tries to tell everyone else what makes a [great|rockstar|mature|senior] [programmer|hire|architect|genius] and how he/she is one because why else would he/she be writing this blog? And, by the way, even experienced people are dummies because they do/don't do [testing|agile|documenting|coding|time management|getting things done] that I/we do/did at ACME corp.
Don't believe me? Google 'great programmer' and peruse the 75 million results and ask yourself why it's such a popular topic.
Don't believe me? Google 'great programmer' and peruse the 75 million results and ask yourself why it's such a popular topic.
I have to object to your post because you're arguing against some general situation which does not apply here. Charles Bloom is a great programmer. I've seen his code.
http://www.cbloom.com/3d/galaxy4.zip
http://www.cbloom.com/misc/index.html
etc.
Also FWIW he was the lead programmer at Oddworld on games such as Oddworld: Stranger's Wrath, which while not particularly well-known to the mainstream is one of the greatest modern console games ever made and which was also very technically impressive at the time of its release. He's also kind of a big deal in the compression world.
If you want to argue specific points he's made, bring them up and debate them on the merits, but don't handwave him away like he's one of those kids just learning Ruby who decided to put up a blog to show everyone how smart he is.
http://www.cbloom.com/3d/galaxy4.zip
http://www.cbloom.com/misc/index.html
etc.
Also FWIW he was the lead programmer at Oddworld on games such as Oddworld: Stranger's Wrath, which while not particularly well-known to the mainstream is one of the greatest modern console games ever made and which was also very technically impressive at the time of its release. He's also kind of a big deal in the compression world.
If you want to argue specific points he's made, bring them up and debate them on the merits, but don't handwave him away like he's one of those kids just learning Ruby who decided to put up a blog to show everyone how smart he is.
Well, all I can say to that is each engineer has to decide for themselves how much they will be swayed by popularity vs real supporting evidence. There's a great rush to quality in software engineering, just as there once was in science. Today, no self respecting scientist would write, "As mature researchers, of which I am the model because I'm telling you what one is, method A is the best because when I worked at Acme chemical for over ten years I personally implemented method A. I'm amazed at how other researchers still don't understand chemistry, and, by the way this is just a rant so I'm allowed to say whatever bullshit I want without the need to support it with fact."
I disagree. It doesn't mater how much credibility the author has, if subjective matters are presented as facts because the author puts himself in a position of unquestionable knowledge, a reader may very well argue that this is pretentious and has zero value.
Know, for many people, the author has enough credibility to write like this because they know his work. If you're one of those persons then you should read and take the author's word. But it still pretentious. Just because someone 'has the' to be pretentious doesn't mean that he/she won't be.
But most importantly, why would you care about those opposing this article?
Know, for many people, the author has enough credibility to write like this because they know his work. If you're one of those persons then you should read and take the author's word. But it still pretentious. Just because someone 'has the' to be pretentious doesn't mean that he/she won't be.
But most importantly, why would you care about those opposing this article?
Wait, what? Is there no such thing as someone who has enough experience that they are allowed to speak directly and clearly about an issue? Rather, you think people are supposed to be all mealy-mouthed so that you don't feel like they are too presumptuous?
That doesn't make sense. There are people in the world who are worth listening to. The "democratic" nature of the web means that a lot of people post a lot of crap, and maybe some people are so used to reading crap that they have just forgotten what it's like when people really know what they are talking about. I don't know.
There's a huge difference between Rails Bros and smart guys who attack the hardest problems they can, whenever they can. Charles is one of the latter people and has been for, I don't know, 16 years? I don't want to live in a world where someone like that is not permitted to speak in an uncushioned way.
That doesn't make sense. There are people in the world who are worth listening to. The "democratic" nature of the web means that a lot of people post a lot of crap, and maybe some people are so used to reading crap that they have just forgotten what it's like when people really know what they are talking about. I don't know.
There's a huge difference between Rails Bros and smart guys who attack the hardest problems they can, whenever they can. Charles is one of the latter people and has been for, I don't know, 16 years? I don't want to live in a world where someone like that is not permitted to speak in an uncushioned way.
You missed my point.
Even rails kids can write in such fashion if they want. The fact that nobody cares makes it pathetic though.
Obviously, many people will care about Charles Bloom's opinions. _That_ is the difference. Out of respect of his work they don't mind whatever style he uses. That's enough for them. Why wouldn't it be? Why would they care if others find it pretentious? I suspect the author itself could care less about those who find his writings pretentious.
Why do you care? All I am saying is that you cannot impose on others the respect you give to a third person.
Even rails kids can write in such fashion if they want. The fact that nobody cares makes it pathetic though.
Obviously, many people will care about Charles Bloom's opinions. _That_ is the difference. Out of respect of his work they don't mind whatever style he uses. That's enough for them. Why wouldn't it be? Why would they care if others find it pretentious? I suspect the author itself could care less about those who find his writings pretentious.
Why do you care? All I am saying is that you cannot impose on others the respect you give to a third person.
Sure. But if you expect that everyone should engage in mediocre speech, just because you don't know whether you should respect them or not, the result is kind of a sucky world.
People can oppose the article all they want. I will internally laugh at them a little bit because I've been programming long enough to realize he is absolutely right in this case, but I won't attack the opposers because they are probably basically just me 6-8 years ago. And me 6-8 years ago was much "smarter" and more "sure" of everything than me today, so I'd realize that debating this point with them will be fruitless.
As others have mentioned in other posts, Charles Bloom's blog isn't your typical "look how smart I am" programmer blog. He's been writing it for years just as a stream of consciousness, self-reference type of thing. I follow it because it is worth following for insight into whatever set of problems he is currently deep-diving into (lately it has been very threading heavy). I don't always agree with him on everything, but again, someone disagreeing with him isn't the part of this I have a problem with.
My point wasn't that Charles Bloom is beyond reproach, my point was that codeonfire lumped him into a group of people to which he is clearly and objectively not a member so that he (or she?) could handwave the whole article away without actually saying anything about it.
As others have mentioned in other posts, Charles Bloom's blog isn't your typical "look how smart I am" programmer blog. He's been writing it for years just as a stream of consciousness, self-reference type of thing. I follow it because it is worth following for insight into whatever set of problems he is currently deep-diving into (lately it has been very threading heavy). I don't always agree with him on everything, but again, someone disagreeing with him isn't the part of this I have a problem with.
My point wasn't that Charles Bloom is beyond reproach, my point was that codeonfire lumped him into a group of people to which he is clearly and objectively not a member so that he (or she?) could handwave the whole article away without actually saying anything about it.
Charles's blog is basically a stream-of-consciousness brain dump. He's not trying to convince you or anyone else, trust me.
I agree with some of his points, with others not so much.
I have myself to blame by following a link with such a title. This kind of writing is too pretentious for my taste. Everyone wants to have their own blub programmer blog entry. I do not like that attitude, from the beginning the author puts himself in a position of almost absolute knowledge, entitling him to point out other people's defects almost as facts.
I would much prefer an exposure of a practical example in reasonable detail so we all can clearly see such problem instead of the usual "the [insert adjective] programmer often does this mistake".
I have myself to blame by following a link with such a title. This kind of writing is too pretentious for my taste. Everyone wants to have their own blub programmer blog entry. I do not like that attitude, from the beginning the author puts himself in a position of almost absolute knowledge, entitling him to point out other people's defects almost as facts.
I would much prefer an exposure of a practical example in reasonable detail so we all can clearly see such problem instead of the usual "the [insert adjective] programmer often does this mistake".
I counter this with the following:
Fuck the joy of programming. On every occasion I've seen a multi-million dollar project crash and burn it was directly attributable to PM's lending credence to developers bitching about "boring" technology.
Here's the real joy of professional coding: 40 hour work weeks with no after-hours crisis pager. The only way you get those is through a rock solid codebase that's so boring you can ramp up the new guy in two days.