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

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.

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.

[] For the standard everyday bridge. New techniques and solutions are tried out for exotic bridges - bridges for high speed trains and such.

One nice thing about software right now is an "engineer" can build on the code created by tens of thousands of other "engineers."

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.

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.

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.

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.

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?

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.

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

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

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.

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

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.

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.

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