Levels of aspiration | Hacker News Reader

Levels of aspiration

37signals.com

72 pointshawke36 comments

  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.

For an article that claims we need software "in all shapes and sizes" the amount of smug superiority exhibited here is amazing. Yes, different people have different priorities when it comes to software choice, but applying an arbitrary one-dimensional quality pyramid to it and assigning users to levels corresponding from 'absolutely clueless hillbilly' to 'latte-sipping Ruby poet' is just wrong.

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.

It’s close enough to Maslow’s Hierarchy of Needs to work for me. I’m more concerned with whether the general idea adds some value to my thinking than trying to take them down a peg for any perceived smugness.

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?

I find I get a lot less out of essays I read if I get sidetracked into making value judgments about the authors

Similarly, I find I get a lot less out of essays when it seems that the authors are making value judgments about me.

Again you inject the authors into the discussion. Why don’t we pretend I have this warehouse full of monkeys tapping on typewriters. We walk by one of the monkeys and look at what it has written. Hmm, seems interesting. It could be all wrong, it could be useful. Why can’t we just just examine the words on the paper for what they are and see if they're useful to think about?

If you’d rather not, you go your way and I will go mine.

You're missing my point. I wasn't saying that the problem was that the document came from DHH or 37Signals. I like 37Signals!

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.

I kind of agree with you, but if I was walking by a warehouse of typing monkeys I would by default assume all of their articles are not useful. 37 Signals seems like a successful company to me. That is why I think the articles they write might have useful content.

Great point, I agree that the provenance of an article is useful for telling us whether we should consider reading it. Is it upvoted on HN? Was it written by some bozo named raganwald or by someone who has actually accomplished something significant? Did a trusted buddy tweet it?

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 agree with you. While the tone of the message matters in terms of how effectively it is conveyed (and how receptive readers will be to the ideas presented), it's not something to get too focused on.

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?!

In an ideal world, this is precisely what we would do.

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.

Because sometimes authors have ulterior motives that you have to watch out for.

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 irony of the whole thing is that it is usually the pragmatists and not the idealists who wind up "moving industry forward", because by definition, the pragmatists get things done. The world needs C not lisp.

I have great sympathy for your point that pragmatism has tremendous value. I disagree in a trifling way with statements like “The world needs C not Lisp,” it is obvious to me that the world needs both C and Lisp. Or it did, and both have contributed in various ways to progress, and C continues to be a useful tool.

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.

First of all, I think my statement "the world needs C not Lisp" was meant to be taken metaphorically, not literally. Of course there is a place for Lisp, but at the end of the day, who has gotten more done in the real world? That certainly hasn't stopped the Lisp hackers from looking down their noses, however.

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.

"the highest form of artistry is the application of pragmatism to manifesting our dreams"

Have been sitting on that sentence just waiting to use it or are you feeling particularly poetic today?

Thanks either way. Very nicely phrased.

And yet the ideas of Lisp are what's driving modern languages forward. The world needs both.

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.

"The world needs C not Lisp" is like saying "the world needs English not French."

I think your statement is open to an interpretation you didn't intend.

I think you may be reading this article far more harshly than I was. For one, I do not think the person sitting at "sorta works" is necessarily a 'clueless hillbilly'.

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.

I see tow problems with this.

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.

Reading his response to a comment in his blog changes the context of his perceived smugness. Doesn't it? Here is what I am referring to:

===========

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

===========

Changes the context of his smugness? Yeah as in erasing all doubt that the author is not merely smug but full on delusional.

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?

I highly doubt he's talking about moving industries forward by using Rails. More likely he means moving industries forward by creating and continuing development of Rails.

Say what you want about it now, Rails had a huge impact on the web development industry when it first came out.

Thanks for the correction, doesn't change my reaction.

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?

Scott McCloud's book "Understanding Comics" outlines a path of 6 steps for artists. He proposes that the greats all master the same first 4 steps, but then split on which of the final two is their primary tool.

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

Yeah, this article is distracting to me. I'm trying to get things done, but I feel guilty that I'm not "doing it right".

Someone once wrote, in their bestselling business book:

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

http://journal.dedasys.com/2006/02/18/maximizers-satisficers...

And the book that is widely cited is this one:

http://en.wikipedia.org/wiki/The_Paradox_of_Choice:_Why_More...

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!

For mature developers the choices here are not about innate skill but about tradeoffs. This blog post makes the error of projecting what is a multi-dimensional problem onto a single dimension.

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.

I would go a step further and say that, at least in my experience, the code bases that have yielded amazing UX, piles of money, etc. are almost never beautiful. The code may start out beautiful, but once people start using it they start surfacing naïve assumptions, flawed designs, bugs, etc. And if things are going well business-wise there's rarely time or resources to fix those issues in a beautiful, comprehensive way (since maintaining beauty frequently means massive refactoring or flat-out rewrites).

In other words, beautiful code is code that nobody uses.

To me, ugly code is code that gets the work done but at the price of too much complexity ( non-DRY, non-cohesive, spaghetti, callback soup ), not enough abstraction, too much abstraction, or too few quality control measures (tests). These things make it difficult to maintain any code.

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.

Would not the top of the pyramid intersect with the bottom in the land of computer science research, where new ideas are being developed but the software itself is often hacked together to the point of just barely working?

Not sure if this is a useful observation, or only an observation.

This diagram is kinda like a roadmap for how to succeed, IMO:

http://s3.amazonaws.com/37assets/svn/952-technical-hierarchy...

(that links comes directly from the article in question)

Good stuff!

how to succeed at what?

This is a great point, I've always been towards the bottom of the pyramid (just coding to "make stuff work"), so when people have tried to sell me on the latest and greatest, based on the beauty, etc... were never compelling enough for me to switch.

Why is Wordpress on the base level?

I used it as an example of what people who just modify an existing code base would use. Not Wordpress, the product, itself. I'm sure that's nicely done.

Thank you for the clarification.

Reply on news.ycombinator.com