The Mature Programmer
cbloomrants.blogspot.com
cbloomrants.blogspot.com
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.
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.
[] For the standard everyday bridge. New techniques and solutions are tried out for exotic bridges - bridges for high speed trains and such.
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.
One nice thing about software right now is an "engineer" can build on the code created by tens of thousands of other "engineers."
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.
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.
"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."
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.
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.
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...
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.
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?
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.
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're working overtime and you're working with old, boring, over-engineered technology, the only thing that's left is the joy of programming.
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?
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.
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.
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 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.
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.)
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
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 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?
A really post-mature programmer understands the values behind so that he does not need rules any more.
http://cbloomrants.blogspot.com/2011/11/11-22-11-mature-prog...
Don't believe me? Google 'great programmer' and peruse the 75 million results and ask yourself why it's such a popular topic.
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.
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?
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.
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.
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.
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".