13 ms·

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

"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 15y ago
I bet IBM is full of mature programmers.
- wattjustin 15y 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.
  - bediger 15y ago
    I'm going to disagree with "getting things done". Three words: IBM Global Services.
    - aangjie 15y ago
      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..
    - wattjustin 15y ago
      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.
- kenjackson 15y ago
  Market cap $225B. I'm sure it is.
  - BCM43 15y ago
    You confuse mature programmers with mature marketers.
    - deleted 15y ago
      [deleted]
101001010101 15y ago
Words of wisdom. I'll take ultra simple, "boring" code over clever code every time. As a not-so-famous musician once said: "It's a fine line between clever and stupid."
absconditus 15y 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.
- dap 15y 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.
- click170 15y 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).
- randomdata 15y 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.
  - wladimir 15y ago
    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.
cageface 15y 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.
- einhverfr 15y 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.
- kenjackson 15y 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."
shadowsun7 15y 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 http://news.ycombinator.com/item?id=3310114 on how the author knows what he's talking about.
konstruktor 15y 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.
- einhverfr 15y 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 15y 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.html http://howwework.thinkrelevance.com/stakeholder_narrative.ht...
josephg 15y 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 15y 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.
  - ryanklee 15y ago
    > 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?
    - deleted 15y ago
      [deleted]
- radicalbyte 15y 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.
davedx 15y 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_baker 15y 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.
- knieveltech 15y 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 15y 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.

derleth 15y ago

I bet IBM is full of mature programmers.

wattjustin 15y 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.
- bediger 15y ago
  I'm going to disagree with "getting things done". Three words: IBM Global Services.
  - aangjie 15y ago
    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..
  - wattjustin 15y ago
    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.
kenjackson 15y ago
Market cap $225B. I'm sure it is.
- BCM43 15y ago
  You confuse mature programmers with mature marketers.
  - deleted 15y ago
    [deleted]

101001010101 15y ago

Words of wisdom. I'll take ultra simple, "boring" code over clever code every time. As a not-so-famous musician once said: "It's a fine line between clever and stupid."

absconditus 15y 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.

dap 15y 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.
click170 15y 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).
randomdata 15y 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.
- wladimir 15y ago
  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.

cageface 15y 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.

einhverfr 15y 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.
kenjackson 15y 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."

shadowsun7 15y 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 http://news.ycombinator.com/item?id=3310114 on how the author knows what he's talking about.

konstruktor 15y 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.

einhverfr 15y 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 15y 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.html http://howwework.thinkrelevance.com/stakeholder_narrative.ht...

josephg 15y 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 15y 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.
- ryanklee 15y ago
  > 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?
  - deleted 15y ago
    [deleted]
radicalbyte 15y 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.

davedx 15y 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_baker 15y 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.

knieveltech 15y 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 15y 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.