Comment by rickmb | Hacker News Reader

Comment by rickmb | Hacker News Reader

Parent Full thread

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.

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

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.

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

"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

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.

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

I couldn't agree more

Reply on news.ycombinator.com