Nobody Hates Software More Than Software Developers

I completely agree that pretty much every proprietary software product that has come bundled with a device I purchased has been useless crap. There's probably one or two exceptions but I can't think of them.<p>I didn't find the rest of the article that interesting, but he definitely nailed his first point.<p>It's not so much bad programming, it's more a case of why? Why do I want to install something that by default will chew up memory by running in the background (and default to launch on startup), that I will never use, because I have so many better tools for the job.<p>I guess the argument is that it's useful for non power-users... Umm sure. How many of you have been asked to fix something on a relative or friends windows box only to find it grindingly slow because of all the run-time resident crap running on it? Like 10 things in the system tray? Update notifications launching one after another on boot? My first task is usually removing all of this stuff they NEVER use before even tackling the real problem they're having.

You should consider your code to suck over time, if you're "doing it right".<p>If you keep learning new and better techniques and practices, old code starts to look immature. If you code in the real world, you make compromises to get a project launched before you're living in an alleyway.<p>TicketStumbler may be a steaming pile of crap in some places and my deployment strategy may have devolved to "install random packages until it stops throwing internal errors", but it was not always this way. Not only have I managed to become an even more amazing programmer in the past year (against all odds), but I've had to cut so many corners the whole thing is beginning to look like a circle. These two factors, above all others, have caused me to rather loathe my code. But that doesn't mean I always do.<p>Maybe this was the point Jeff was attempting to make? If I am only good by hating <i>all</i> my code, I don't see how I could ever <i>be</i> good.

I'm a little bit nervous to say this, but this is another of Jeff's articles where I think "man, so many of this guy's problems would go away if he didn't hate Macs so much".<p>In my experience, Mac devs <i>don't</i> hate software, and Mac users don't have the instinctive "oh [App X I haven't heard of]? That's going to suck".<p>Gruber talked more about this in his Broken Windows essay -- <a href="http://daringfireball.net/2004/06/broken_windows" rel="nofollow">http://daringfireball.net/2004/06/broken_windows</a> -- and what he said about security is generally true for quality and polish as well. If I get a new app for the Mac, I know that it's going to have basic standards of fit and finish and will make a reasonable attempt at being a good Mac citizen, because otherwise the community will kill it.<p>When a new Mac app comes out, I'm usually fairly optimistic about what it will do. When a new Windows one appears, I'm sceptical.<p>This doesn't extend all the way to the quality of coding admittedly, but certainly at least until the iPhone came out Cocoa devs were a fairly select set of committed people, and the higher barrier to entry helped keep at least some of the crappiest C&#38;P coders out of the platform.

Awareness of your own limits, and the likely quality of your work, is a good thing.<p>But this descends into self-flagellation. <i>Waaaah, I suck, you suck, we all suck. We're all the equal-worst programmers EVER.</i><p>If you're doing research into programming languages, and you're explaining your work, or asking for funding, fine.<p>But coming from practicing programmers, it's a common, trite, pointless and irritating refrain containing zero useful information.

<i>In fact, I think you can tell a competent software developer from an incompetent one with a single interview question:<p>What's the worst code you've seen recently?<p>If their answer isn't immediately and without any hesitation these two words:<p>My own.<p>Then you should end the interview immediately. Sorry, pal.</i><p>It seems to me that few programmers would answer the question this way, competent or not. And it's probably not true for most competent programmers... I wonder if Jeff has actually received this answer from a interviewee.

I think this article makes some good points, and I found myself nodding a lot.<p>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.<p>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.<p>I want to do things <i>my</i> <i>way</i>. 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 remember that scene from "War of the Roses" where the Danny DeVito character tells the horror story of the Roses to talk a new client out of engaging in an ugly and bitter courtroom battle. I think his line was (paraphrasing here) "when a man who could charge you $250 an hour wants to tell you something for free, you should listen."<p>I often feel that way about software. Remember the stages of a software project?<p>1) wild enthusiasm 2) profound disillusionment 3) search for the guilty 4) punishment of the innocent 5) rewards and accolades for the non-participants<p>Can't remember exactly where I read that, but software developers have experienced them all, over and over.<p>I don't necessarily try to talk people <i>out</i> of a new development effort. After all, there are clearly times when we need to write software, and some projects are smashing successes. But I kind of feel like that breed of lawyer who tries to get clients to see litigation as a true last resort.<p>I say - is there anything already out there that could solve your problems without a new development effort? How far would a much simpler approach go toward solving your problems - could you live with it? Basically, I want clients to understand just how risky a full blown development effort truly is.<p>Of course, if you need business... well, nothing like an angry divorce to keep the billable hours up, and nothing like a flailing software project funded by deep pockets to keep the cash flow positive....

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.<p>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.<p>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?

"How do I know, incontrovertibly, beyond the shadow of a doubt, that the world is full of incompetent programmers? Because I'm one of them!"<p>Those who can, code. Those who can't, blog.

Extrapolated...<p>Programming will make you hate software. Programming will make you hate programmers. Programming will make you hate computers.<p>Lisp will make you forget all of that.

<i>In fact, I think you can tell a competent software developer from an incompetent one with a single interview question:<p>What's the worst code you've seen recently?<p>If their answer isn't immediately and without any hesitation these two words:<p>My own.<p>Then you should end the interview immediately. Sorry, pal. You don't hate software enough yet. Maybe in a few more years. If you keep at it.</i><p>I have always enjoyed Jeff's columns and maybe I'm missing a subtle point (or just taking the bait), but this may be the worst "advice" I've ever read on hn.<p>If someone told me that the worst code they've seen recently was their own, I'd wonder why.<p>I feel confident in my own ability to usually write excellent code on the first try. Sure, it may need some refactoring, optimization, and flushing out of features, but it works, it generally works well, is very well documented, and can be easily enhanced by myself or someone else. If it's not right on the first try, I will fix it before I promote it. Shame on me (and anyone else for that matter) for leaving behind garbage for someone else to inherit. I've cleaned up far too many messes to allow myself to become like that.<p>I'm probably not alone when I say that I love developing new code and often hate maintaining someone else's mess.<p>Jeff is right about one thing though, almost everything I ever inherited was crap in one way or another, probably written by someone "less than senior".<p>I'd rephrase the whole interview question:<p>"What's the <i>second</i> worst code you've seen recently?"<p>"My own."<p>"OK then, what's the worst?"<p>"Everyone else's."<p><i>That's</i> the one I would hire.

As usual Atwood manages to destroy a valid perspective (be mindful of your code quality) with unnecessary hyperbole.<p>I wouldn't hire anyone who said their own code was the worst they'd seen recently. Whatever points they may win for perception and awareness are totally overshadowed by their lazy acceptance of the situation.<p>"Which areas of your coding could you most improve on?" - now that is a question worth asking,

Clearly the main issue of the post is the answer to the interview question. Although I think it's a very good answer and that to me it would probably mean I would be hiring a guy which is humble, which always views his knowledge has something that still could be better and has a view of his own code has something imperfect, and so he tries very hard to always know more and improve, and that would mean in the end he is just one of the best choices to hire, I think that in most companies that guy would never be hired.<p>Although it sucks, nobody gives any value to humility anymore. They want the confident, "I'm an expert" kind of guy, so giving as answer that the worst code you've seen lately is your own, without any kind of explanation of why you think that (that you view your knowledge has something which as always a long way to go) would probably be a instant KO to the poor humble interviewee.

What you'll end up with is hiring either incompetent programmers who know they're incompetent, or people with no self-esteem. Great. It seems more like either Jeff is incompetent (which he admits to) or self-deprecating, and assumes everyone else is.

I don't understand who votes these articles up anymore. They're just completely useless.