The Mature Programmer

http://cbloomrants.blogspot.com/2011/11/11-22-11-mature-programmer.html

by jblow • 15 years ago

226 70 15 years ago

cbloomrants.blogspot.com

knieveltech3• 15 years ago

"The Mature Programmer would say that "clever code is almost always dangerous code". But fuck him. The problem is that when you get carried away with being "mature" you suck the joy right out coding."

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.

derleth• 15 years ago

I bet IBM is full of mature programmers.

kenjackson2• 15 years ago

Market cap $225B. I'm sure it is.

wattjustin2• 15 years ago

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.

absconditus• 15 years ago

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.

click170• 15 years ago

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).

dap• 15 years ago

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.

randomdata• 15 years ago

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.

yxhuvud• 15 years ago

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.

rimantas• 15 years ago

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.

_delirium2• 15 years ago

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.

drumdance• 15 years ago

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."

cageface2• 15 years ago

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.

einhverfr5• 15 years ago

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.

kenjackson2• 15 years ago

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."

radicalbyte3• 15 years ago

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.

shadowsun7• 15 years ago

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.

konstruktor• 15 years ago

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.

einhverfr5• 15 years ago

I read him mostly as saying "don't take this so far that it kills the creative spark" which is a very good caution.

calibraxis• 15 years ago

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...

josephg• 15 years ago

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.

dustingetz• 15 years ago

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.

radicalbyte3• 15 years ago

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.

knieveltech3• 15 years ago

"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.

davedx• 15 years ago

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.

j_baker2• 15 years ago

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.

knieveltech3• 15 years ago

"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?

mahyarm• 15 years ago

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.

_m4• 15 years ago

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.

biesnecker• 15 years ago

Exactly. There is much joy to be derived from a codebase that works, that is maintainable, and that is understandable.

codeonfire2• 15 years ago

Don't believe me? Google 'great programmer' and peruse the 75 million results and ask yourself why it's such a popular topic.

georgemcbay2• 15 years ago

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.

skeptical3• 15 years ago

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?

codeonfire2• 15 years ago

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."

psykotic• 15 years ago

Charles's blog is basically a stream-of-consciousness brain dump. He's not trying to convince you or anyone else, trust me.

rickmb• 15 years ago

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.

einhverfr5• 15 years ago

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 ;-)

jblow4• 15 years ago

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.

jblow4• 15 years ago

(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.)

nessus42• 15 years ago

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.)

einhverfr5• 15 years ago

"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

_delirium2• 15 years ago

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.

__abc• 15 years ago

I couldn't agree more

apaitch• 15 years ago

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.

j_baker2• 15 years ago

I think that was actually his point.

wwweston• 15 years ago

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?

akkartik• 15 years ago

The first comment is teh awesome.

http://cbloomrants.blogspot.com/2011/11/11-22-11-mature-prog...

epo• 15 years ago

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.

skeptical3• 15 years ago

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".

wwkeyboard• 15 years ago

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

JabavuAdams• 15 years ago

Fantastic article! I'd forgotten about that one.

Joeri• 15 years ago

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.

lalalalaXX• 15 years ago

I read this as "A mature programmer mangles their time and productivity well"

The Mature Programmer

Related Stories