Nobody Hates Software More Than Software Developers

There is a lot of value in the comments on this article, but I am afraid that the idea that you can usefully hire someone based on the answer to one question is a bit oversimplified. In any project that I have done that spans any length of time, often the first code I wrote doesn't look up to snuff with what I wrote most recently. The later code looks better by virtue of a better feel for the environment and the tools and some obscure abbreviation-finder that seems to be at work in the background.

One concern that I would have if you think the worst code that you have seen is stuff you wrote, perhaps you are not reading enough of other people's code. I bet there is a lot of that amongst us all.

In the vein of simple questions that help in an interview, particularly for someone who purports to be an expert, is "Tell me five ways that it won't work". An expert ought to have some scars, and have learned from them, no?

I think this article makes some good points, and I found myself nodding a lot.

On the other hand, it (along with some of the HN comments) conflates a couple of unrelated issues: (1) how well software is written, and (2) whether software forces me to do things I don't want to do.

One of the parts I nodded along with, was his story of lunging for the computer when the camera software CD was inserted. But this doesn't have anything to do with whether the source of this software was readable, variable names, etc., nor is it related to the competence of the programmers or whether they are aware of their own failings. The issue is that such software is often written with a view toward taking over the way I do things.

I want to do things my way. That's the reason for my move from Windows to Linux, and it's why I use Firefox instead of IE when I do use Windows. It's why I avoid Flash when feasible, why I hate most children's educational software, and why I would not even glance at the software that came with a camera. Does this have anything to do with the quality of the code involved in these programs? I don't think so.

I don't understand your analogy. Is the Wizard of Oz repulsed because he thinks the illusion is bad, or because he knows how it's made? Would "This is the worst hunk-a-junk implementation of an illusion I've ever seen?" be an accurate interpretation of what he means?

Jeff's post and your comment both confuse me on this point - I can't figure out when either of you are talking about quality of implementation (when I read "code" I think implementation) and when you're talking about quality of user experience. I'm not even sure if you and Jeff are saying the same thing. Jeff spends most of his post talking about bad user experiences caused by programs written by people who are probably not experts, but then he ends by saying that all programmers should hate their own code. I, and most people on HN apparently, interpret this to mean that we should all hate the quality of our implementations. Not only is this weird on it's face (surely many people who read Jeff's blog, let alone HN, have seen worse code than what they usually write themselves), but it doesn't seem to follow from the rest of the post. My reading of your comment leads me to believe that you dislike all code/implementations on general principle, but I can't tell if you even refer to the user experience at all. The second to last sentence seems to, but I can't figure out how the rest of the comment relates to it because the rest of the comment seems to be purely about implementation (except for the reference to the Wizard of Oz, which is completely ambiguous in that regard as far as I can tell).

My experience seems to be different than yours. I might have thought of software as magic when I was exposed to computers for the very first time, but as soon as I learned a little bit about how they worked none of it was really "magic" any more. A good user experience might be smooth, or quick, or intuitive, or even delightful, but I don't see it as magic. Occasionally I see something and I don't know how it was done, and it that case I want to know. I want to look under the covers, just like I wanted to know how computers worked. The connotations of "magic" hardly arise, because I immediately move past the "I can't believe that works!" stage to the "how does it work?" stage. I assume (or in the case of computers, know) there is machinery under the covers even before I see it, and I want to see it. There is nothing necessarily repulsive about the machinery to me, and in fact the machinery has its own beauty that is largely independent of the user experience. My ideal piece of software delivers a fantastic user experience with beautiful machinery, but I understand that beauty in one part does not necessarily imply beauty in the other. The user experience is generally more important than the quality of the code, but there is no law that says code has to be repulsive. We seem to disagree about that.

I would not say that my own code was the worst I've ever seen, but I am always dissatisfied with it and with the user experience it delivers because I always think it could be better. I completely agree with Jeff's Parnas quote, and I also agree that Jeff is probably an incompetent programmer in the judgement of Parnas and others like him. So I maybe I agree with Jeff's intended point. On the other hand, I think Jeff has delivered some pretty good user experiences, and I think many programmers who really don't produce great code and/or create a net increase in programmer demand can and do deliver decent, or even fantastic, user experiences. (This is probably one of the reasons why we have so many incompetent programmers and don't live in Parnas's ideal world. Relatively incompetent programmers can still deliver good user experiences, so in the short term it's expedient to deliver software that way. In the long term, we have a shit ton of deeply stacked shit and all the really good programmers are spending their time making shit shoveling tools instead of advancing the state of the art, but hey. Just another tradeoff.)

Speaking for myself, I know I'm an incompetent programmer who would not have a job in my own ideal world, but my goal is to not be that guy, and I would prefer not to hire that guy, or the guy who has never seen worse code than his own, doesn't make a clear distinction between his own level of skill and the level of skill displayed by crapware developers, does not aspire to write anything terribly ambitious from a technical standpoint, and in fact has nightmares about it. I enjoy programing, and I am more suspicious of people who say they hate software than I am of people who say that their own code is not the worst they've ever seen.

I think Jeff is exaggerating a bit with his phrasing, but I think there's an important point there: humility is always important, and it's the only way you ever improve. As soon as you start being really satisfied with your own work, you stop trying to improve it, and that's a dangerous point to be at. Most of the best programmers I know personally are all highly self-critical about their work.

I also think it's important for one's job satisfaction and enjoyment of life that you take pride in your work and can be proud of your accomplishments, and I think it's important to be able to juxtapose that level of satisfaction with a constant drive to improve (I actually blogged about that topic a couple of months ago http://guidewiredevelopment.wordpress.com/2009/05/07/it-can-...)

It's also far too easy to assume that everything written by everyone else is crap simply because it doesn't map to how you would solve the problem, and while some of it certainly is crap, it's important to be charitable in your analysis there. Becoming better means being open to learning from other people's ways of doing things, and being a good teammate means giving your coworkers the benefit of the doubt and assuming that if something doesn't make sense to you or seems ugly, perhaps it's because the problem is more complicated than you thought, or perhaps they had to inherit some ugly legacy code, or perhaps the problem domain just wasn't well understood at the time the code was first written.