To help someone move up the hierarchies, they have to have an intrisic (sic)
desire to do so. Arguments like “but it works” or “it gets the job done” are
tell-tell signs of someone happy at the lowest level of the technical
hierarchy and your cue to just quietly back out of the debate.
And the pyramid itself doesn't follow any logical ordering either. E.g. the implication that "beautiful code" is also fault tolerant is a total non sequitur. We get it, 37signals is moving the industry forward, it says so right in the infographic. I'm not even disagreeing with the fact that this company has been extremely influential, and I did enjoy reading their book - but appointing yourself king of the hill while casually dismissing technology you don't agree with as being lower level, that's just bad form.
And speaking as an ex-salesperson, this general model is extremely relevant when attempting to persuade someone to change. Within the narrow confine of a single decision, different people are at different places in a hierarchy like this, and you are wasting your time if you argue at the wrong level.
It’s important to remember that placement in the hierarchy with respect to a specific choice is not a value judgment about a human being. I spend a lot of time daydreaming about programming languages, but when there’s a plumbing problem in my house I just want it fixed. Someone might be a latte-sipping derivatives poet but happy to hack together some Perl to process some data feeds.
It’s up to you of course, but I find I get a lot less out of essays I read if I get sidetracked into making value judgments about the authors. If there’s something there worth thinking about, why let the other stuff distract you?
Similarly, I find I get a lot less out of essays when it seems that the authors are making value judgments about me.
If you’d rather not, you go your way and I will go mine.
What I was saying was, if you remove the author's identity from the document and just look at the actual words on the paper, you find that the words on the paper have a pretty clear value judgment embedded in them: that "a single consultant serving local businesses in Schaumburg, Illinois" is by definition someone who doesn't care about beautiful code, quality engineering, etc. A beyond-saving rube, in other words.
If a warehouse full of monkeys produced the same argument in the same words, I'd have reacted to it just as strongly. Elitism is a turn-off for me.
All I’m saying is that once I decide to read it, I try to let go of that and take the article on its own merits. It could be that an idiot has written something interesting. Or the reverse, a well-repsected person is just plain wrong today.
(And in reality, I’m just as prone as the next guy to think about the author. This business of being detached and zen-like is me aspiring to read essays at a high level on the hierarchy!)
I find that people are much more likely to perceive value judgments and look for hidden meanings in things when they are feeling insecure. Did that guy just insult me? Is he trying to imply that I don't move the industry forward? How dare he?!
Unfortunately, this is a world constrained by time and by knowledge. I do not have the time or expertise to evaluate everything I read in a clinical fashion.
Given those constraints, who the author is becomes a very powerful signal. If Neil De Grasse Tyson says something about astrophysics I can probably take it at face value, at least until I have a reason to question. On the other hand, someone with a self-interested reason to get me to believe something will rightly get far more scrutiny, even if they are eventually proven completely right.
I'm not saying this article does have ulterior motives, just that acting as if every article has no author and hence no motive behind its writing is naive.
The interesting thing is that insanely great progress requires operating at all levels of the hierarchy. Consider the oft-quoted maxim, “Real artists ship.” This does not suggest that there is no room for dreaming, but rather that the highest form of artistry is the application of pragmatism to manifesting our dreams.
The bottom line is that the sense I get from the kinds of rhetoric in the OP is not the kind of high-minded idealism you express but rather just a bunch of software aestheticians casting value judgements on the people who are focused on making things happen. My perception could be wrong, I'll grant you that.
Have been sitting on that sentence just waiting to use it or are you feeling particularly poetic today?
Thanks either way. Very nicely phrased.
The world needs people actually getting relevant stuff done right now, and the world needs the dreamers who focus on Utopia. Ideally, both learn from each others' experiences, without declaring that really, they are the group the world really needs.
In fact, I suspect most serious developers travel up and down this pyramid all the time. Sometimes they are trying to push the state of the art forward, sometimes something that "sorta works" and ships ontime is just fine.
As for "beautiful code" being fault tolerant, it could be argued that any code which is not fault tolerant is not beautiful. I am not sure if that is right or now, but beauty tends to be somewhat subjective and that seems a valid interpretation.
First, the fact that "beautiful" is very subjective... what makes code beautiful? Is it the idea expressed, the syntax, the cleverness?
Second, the fact that this subjective property could imply that something is fault tolerant, without being clear of what you mean by fault tolerance. This being a very large research area requires one to be precise of what one is talking about, before saying that you solve the problem by writing "beautiful" code.
DHH 10 Jul 12
Kathy, that’s a great point. Also, this pyramid can be applied in finer resolution within your stack. For example, I’m perfectly content to be at the “Well engineered” level when it comes to my use of MySQL, but when it comes to Ruby and Rails, I want to be at “Moving industry forward”.
Elon Musk is moving industries forward. The first time I used an iPhone it was so beautiful I could cry.
But, Rails? I mean, not to harsh on Rails at all, it's a great tool.
Moving an industry forward whenever you use Rails? WTF?
Say what you want about it now, Rails had a huge impact on the web development industry when it first came out.
Languages are great, but its hard to tell
If the proliferation of so many languages moves the industry forward or backward. Wasn't the whole point of the tower of babel story that god created so many languages to slow down progress?
The "pioneers and revolutionaries" play with the form itself (Moebius, Picasso, Stravinsky). The "storytellers" use the medium for their ideas (Schultz, Dickens, Capra). Neither approach is superior to the other, and the line between them is certainly fuzzy.
The original Macintosh operating system, for example, was probably pretty lousy code by any modern standard, but certainly moved the industry forward. TeX, on the other hand, is arguably excellent code, and still used today, but probably never had as many users. Which is "better"? Neither, of course! In McCloud's terms, Apple focused on "form", and Knuth focused on "idea".
"Good enough is fine
A lot of people get off on solving problems with complicated solutions. Flexing your intellectual muscles can be intoxicating. Then you start looking for another big challenge that gives you that same rush, regardless of whether it's a good idea or not."
This is somewhat different than what's written in this article:
"Arguments like “but it works” or “it gets the job done” are tell-tale signs of someone happy at the lowest level of the technical hierarchy and your cue to just quietly back out of the debate."
And here's the deal: they're both right, but you need to recognize when each situation is right. The terminology for this is called "maximizers vs satisficers". I wrote something about that and programming here:
And the book that is widely cited is this one:
But getting back to the discussion: there are times when you really should be looking for the best whatever it is you're looking for. But if you try and do that all the time, you'll spend all your time looking (or worse, deciding everything sucks and you can do it better yourself) and not enough time doing what it was you set out to do.
Which, in the end, simply means that you have got to do the thinking and make your own difficult decisions, rather than listen to trite advice from business books or blogs, or hacker news comments, no matter how insightful they may sound!
You can have a pretty abysmal code base with beautiful design on top and amazing UX and be rolling in piles of money, and be perfectly aware that the code sucks but made the decision that beautiful code was not the priority or competitive advantage of the business.
In other words, beautiful code is code that nobody uses.
In other words, ugly code is code that must be rewritten to be maintained. Depending on the innate complexity of my problem that can be an acceptable trade-off.
Beautiful code should also be easy to maintain; usually that means making each layer of abstraction as simple as it can be, and adding a new layer of abstraction to handle additional complexity.
In this way, I may write more new code to handle newly discovered edge cases or new features, but at least I am not rewriting old code to solve the same old problems plus the new ones. That gets old really fast.
Not sure if this is a useful observation, or only an observation.
(that links comes directly from the article in question)