yield thought

it's not as hard as you think

7 Reasons To Hate Your Code

with 85 comments

Incompetence is the cause of many ills in the software world, but increasingly I’m seeing a certain kind of competence as being just as destructive. You see, there are a lot of programmers who care deeply about their code. I did, but it turns out there are good reasons we shouldn’t do that; reasons why we should hate our code…

Reason 1: It keeps you open to change

The most productive way to write software is to release early and iterate quickly with feedback from real users, right? It saves us from implementing the wrong features, that it helps build a community and so on. What’s people don’t talk about as often is the impact it has on our relationship with the code. Putting a program in front of users is terrifying because they might not like it. The more lovingly we craft and polish every class before release, the more carefully we plan our abstractions and structures, the more emotionally attached we are to the way we have made it.

The result is that we instinctively resist making significant changes to the code based on early feedback, even though this was the whole point. It’s an unconscious, emotional reaction that we rationalize away to ourselves by claiming the users just don’t understand the feature, or that it just needs a bit more polish when, seen objectively, the best thing to do might be to restructure it completely do do something rather different.

In fact, the best way to remain responsive to your users is to hate your code.

Reason 2: Jeff Atwood says that you should

You can tell a competent software developer from an incompetent one with a single interview question: “What’s the worst code you’ve seen recently?”
If their answer isn’t immediately and without any hesitation these two words: “My own,” then you should end the interview.
Jeff Atwood

Every now and again people attack Jeff for his assertion that we write bad code, for his arms-wide-open group humility. I think people misunderstand him. The message is not you are a bad programmer, it’s that part of being – of becoming – a great programmer is writing code that you’re ashamed of. If you think all the code you write is wonderful, you’re probably not learning anything.

Reason 3: If you don’t hate your code, you’re wasting too much time on it

Andy Brice famously wrote that if you aren’t embarrassed by v1.0 you didn’t release it early enough – you spent too much time polishing it to meet your expectations instead of giving it to the user and finding out what they think of it. A corollary of this is that if you aren’t embarrassed by your own code then you spent time crafting and reworking it until you loved it. This is time that you should have spent trying to make a product the user will love.

Nobody cares if you refactor to use the Chain of Responsibility pattern or not; they want simple, elegant features that work first time. We should spend our time delivering that, instead.

Reason 4: It’s what Jesus would do

No one can serve two masters. For you will hate one and love the other; you will be devoted to one and despise the other. You cannot love both your code and your users.
— Matthew 6:24 (lightly paraphrased)

Reason 5: Loving your code for its own sake will make your product suck

Loving your own code is a kind of hubris. It presumes that you’re writing the code so that you can work on it in the future, or can show off a neat trick to your colleagues.

This love is misplaced; your code isn’t going to be judged on its internal beauty and consistency. It’s going to be judged by people who just want to get their work done. They’ll love it if it makes that easier and they’ll hate it if it distracts them from that task, if it makes their lives harder.

Creator: I love the power of Unix/AJAX/C#/whatever.
Customer: I want to finish my work and go play outside.
Scott Belkun

I once spent six months crafting a beautifully-constructed version 2.0 of our company’s product. We’d started again so we could use unit tests throughout, the code was completely modular and pleasant to work on. There was none of the spaghetti-code complexity that dogged the first version.

We demoed an early prototype to management and marketing who said:

Great, so it’ll be ready next month?

Aghast I pointed out we still had to add a whole bunch of features and do a ton of testing. Their faces fell, and at that point I realized that it didn’t matter how beautiful the new codebase was. It would cost too much to bring it up to the feature level of the old one.

Its intrinsic beauty wasn’t worth anything; only user-visible features weighed in the balance. The project was cancelled, and rightly so.

To worry about code aesthetics more than the aesthetics of the product itself… is akin to a song writer worrying about the aesthetics of the sheet music instead of the quality of sounds people hear when the band actually plays
Scott Belkun

Reason 6: Gandhi would want you to

Hate the User class, love the user.
— Mahatma Gandhi (lightly paraphrased)

Reason 7: It will make you a better developer

Like most people, I got into programming because I wanted to write things for myself and for my friends. During this enthusiastic newbie phase I was a happy user and a happy developer. My code sucked but I didn’t know that yet.

Later on I got into programming for its own sake, I ended up caring deeply about the kind of design patterns I was applying and whether this for loop could be refactored a third time. Eventually this abstraction freak phase left me almost incapable of creating any real value because I invariably got lost in the upper echelons of the software design and never finished any useful features.

Of course, when I started writing professionally I had to care about the features, and had to see my beautiful code mutilated again and again in the name of profit, of getting this feature out in time for the next release. This is enough to make anyone into a bitter veteran.

Eventually I started discovering the joy of programming again, via dynamic languages and web frameworks that made it possible to get useful programs out of the door on day one. I started writing side projects I actually wanted to use. I became free to write the minimum necessary to make something useful. I’d become the ‘guru’, who mistakenly believes he’s better than everyone else because he’s finally become productive again.

But I haven’t become great yet. What might the next step be? I don’t know. Reading more code? Writing less code? Perhaps. But at the moment I have a feeling that to grow in another dimension – creating awesome software – I need to sacrifice the pride I’ve built up in my art:

The seventh step of humility is that a monk not only admits with his tongue but is also convinced in his heart that he is inferior to all and of less value, humbling himself and saying with the Prophet: I was exalted, then I was humbled and overwhelmed with confusion and again, It is a blessing that you have humbled me so that I can learn your commandments.
— The Rule of St Benedict 7.51-54

Until today I found this quote somehow ridiculous or inhuman, yet now I’m beginning to believe that overcoming our egos and admitting that we are writing unworthy code but writing it anyway is a vital step in becoming truly great programmers. Perhaps we can let go and accept that, ultimately, the code never really mattered at all.

Postscript: I’m not saying we should set out to write bad code. It’s vitally important to have an idea of how the code should end up, but instead of working and working until we achieve that and then shipping the product we must write the least we can get away with while gradually approaching the ideal. Understanding this distinction is crucial.

Note: Yield Thought has moved to http://yieldthought.com – check there for the latest posts!

Written by coderoom

April 22, 2010 at 3:45 pm

85 Responses

Subscribe to comments with RSS.

  1. I love this post! It could also be 7 reasons to hate your product / GUI / blog / speech … whatever. It’s so true. Awfully challenging though.

    Gil Reich

    April 23, 2010 at 8:17 am

  2. Beautifully disturbing. Awesome selection of quotes. Squeeze something Zappa said and a Star Trek/Blues Brothers quote in addition to the Bible, Belkun, Ghandi and medieval scholars and you’ll be on top of my personal writers list 🙂

    Writing clean code helps to stay flexible and allows for easy changes, but writing clean code is not the ultimate goal. Producing something that makes users happy is. Clean code is a means to achieve that.



    April 23, 2010 at 8:21 am

    • Heh, yes – a Firefly quote would’ve been good, too 🙂


      April 23, 2010 at 8:24 am

  3. This is an excellent post – it hits right where it hurts – and I mean that as a good thing. I think that most professional programmers go through these stages, and at some point, you learn the balancing act of writing code that is reasonably clever/beautiful/elegant yet functional, and done fast enough to matter to users.

    I want to add some food for thought.

    Now we’re at the point that even programmer/coders have to learn that their code sucks – something that all administrators and architects are always happy to admit. You only have to glance through a few database administrator forums or conferences, and bump – there it is: yet another DBA that can’t wait to tell you how their job consists mainly of telling those darn coders that “their queries suck”.

    Now, I invite everyone that calls him/herself a “data modeler” or “data architect” to read the article again, substituting “code” for “data model” and “data architecture” respectively. How does it feel? Is the substitution applicable to you too? Please explain why, or why not – I’d love to hear what you think.

    Roland Bouman

    April 23, 2010 at 8:35 am

    • I haven’t had much contact with the data modeling crowd but I suspect you’re dead on. While we’re at it we should probably get bureaucrats to do the same, substituting “code” for “process”…


      April 23, 2010 at 8:43 am

  4. Great post. Heart breaking, but true 🙂

    Indra Ginanjar

    April 23, 2010 at 8:35 am

  5. Edited by coderoom to break up the monolithic block of text

    While I agree that you shouldn’t get too hung up on the beauty of your code, I get a feeling that this mindset is to just rush your product out the door. There are several problems with this:

    First of all, if version 1 sucks, you will not get much feedback, because nobody will use your product. You can try to improve it and maybe version 2 will be awesome, but many people won’t care anymore since they have associated the name of your product with “failure” based on v1 and they have no incentive of trying out the updated version.

    Second, it seems 100% reasonable to say that if you care about your code, the code will be better than if you don’t care. You might want to “iterate fast” and get the code out the door so that you can change it based on user feedback, but if your code sucks, chances are that changing it is much harder than if it were a little bit better.

    The hard part of software development is to know when your code is good enough, and to care deeply about achieving that level of goodness before you ship. The trick is to realize that “good enough” is nowhere near perfect and can in some situation still be pretty bad. There is a balance between taking the time to write good code, and getting it out of the door ASAP. You should care about both, and focusing blindly on either of those will not result in the best product.


    April 23, 2010 at 8:43 am

    • Others have dealt with the “but what if version 1 is too bad” problem elsewhere; none of us are really experts but there are good arguments why this shouldn’t stop us releasing anyway.

      Paul Graham would say that version 1 can suck but it has to solve someone’s problem. It has to be something someone wants. It might be a poor shadow of what it will be, but that element needs to be present.

      Not wanting to make your code beautiful is not the same as making it unmaintainable.

      Even if you don’t love your code for its own sake, you have to be passionate about your user’s experience of the product.


      April 23, 2010 at 8:49 am

      • Thanks for editing the wall of text. I didn’t realize it was so bad when typing it up (and there seem to be no preview and edit functions).

        Anyway, I’m not so convinced by the links you provide about shipping crap products. The first seems to be an extremely convoluted story that (doesn’t really) lead to the conclusion that fast iteration is good. I don’t necessarily disagree with that conclusion, but as I stated in another comment below: rushing to ship version 1 might delay version 2.

        The first two links are about another kind of sucky product than I was talking about however. They seem to consider mostly that the product might have less features and not look as shiny as originally intended. This is where user feedback comes in handy, because it prevents you from wasting time on features that they don’t want. I also think that lacking features is not necessarily the worst thing that can happen in terms of ‘bad press’ (although if you’re demoing to potential investers it can be).
        However, rushed code probably contains more bugs, which will affect the quality of the product. Crashing the user’s system a couple of times will probably drive some of them away from your product forever. If your code is so ugly that it contains all these bugs, you have to fix that anyway. It is not a waste of time like working on features that your users don’t want.

        You say “Not wanting to make your code beautiful is not the same as making it unmaintainable.”. I agree to a point, but I’m also making the assumption that caring more about your code will make it more beautiful. And for me, beautiful is pretty much synonimous with maintainable/flexible/adaptive/etc. You link to your “flexibility manifest” and I completely agree that your code should be flexible. I’m just making the assumption that the code will be more flexible if you care about it. Do you think that is a false assumption.


        April 23, 2010 at 11:27 am

      • I don’t think anyone would recommend doing things that damage the quality of the end product. With the postscript I was trying to make this point as clear as possible – hating your code and loving the user doesn’t mean writing bad code – that’s not in the user’s interest.

        Hating your code means never sacrificing product functionality or stability (through more testing) for the sake of playing around making your code as pretty as possible.

        An example of hating your code and loving the user is spending more time getting in-depth unit tests working and trying to break your code instead of spending that time refactoring it to a more aesthetically-pleasing pattern of the month.


        April 23, 2010 at 12:30 pm

      • That sounds more like “tough love” than hate to me, but I think I agree with you. 🙂


        April 23, 2010 at 1:11 pm

  6. I kind of disagree with points related to pleasing users. I have basically two approaches — if I am focused at making users happy, I would take some shortcuts sometimes, but I will not hate the result — it is not perfect, but it is not perfect for a reason.

    But if my paycheck is not related to the code in question, and I do not have users waiting for something, I will try to make the code as perfect as possible. If it makes me release results later — so be it. If users do not care about internals, so be it (it does not mean that I wouldn’t try to be perfectionist about usability as well).

    Also, a lot of developer libraries show us that code can be quite good and useful at the same time. And Ayende posts tell that making good stuff and making stuff fast is not orthogonal, actually it is quite other way around.

    Andrey Shchekin

    April 23, 2010 at 8:58 am

    • Yes, I agree that developer libraries are something of an exception, because you don’t have the luxury of releasing early and iterating often – you need to keep the interface stable, and that means you need to put a lot of up-front thought and design into picking a good one.


      April 23, 2010 at 9:30 am

      • Still, to some extent it still holds. In the case of a library, the users are other programmers. No matter how elegant a library is implemented, what really matters is how good the interface is – the interface is the feature the users care about.

        Having a crap implementation of the interface in version 1 of your library is less important than delivering an interface that other programmers can use effectively (for example, consistent naming, balanced verbosity, memorizable parameters).

        Roland Bouman

        April 23, 2010 at 9:35 am

  7. @Jordi, I think the point of the post is that the code should not be the measure – the product should be.

    Of course, if the code is so bad that the product sucks, well, then sure you have a problem. But in practice, it is much harder to get products out of the door than to write beautiful code. Software patterns is something you can learn – making successful products, well, if that would be easy, we’d all be making them right now, no?

    Take for example what you say about caring about your code. Sure, it might be “better code”, but by what standard? Users don’t care, that’s for sure.

    You say that it is important to know that your code is good enough, and care about that. I would argue that the real key is to know where it is rotten, and accept that. There will always be rotten parts. Focus on those parts so it doesn’t fall apart next iteration.

    I do completely agree what you say about “good enough” and finding a balance though. (perhaps we agree more than my contradictions might seem to indicate)

    kind regards, Roland.

    Roland Bouman

    April 23, 2010 at 9:00 am

    • I think we probably agree more than it might seem. 🙂

      The question is whether you can have a decent product with bad code. I think the answer is ‘yes’. However, the bad code might prevent the product from getting better, because nobody cared to make it maintainable. Or, less extreme: it will take longer to make an improved version 2.

      This is why balance is important: you can try to rush version 1 out the door as quickly as possible, without caring about code flexibility and maintainability, but then it might take longer to write version 2. It might have been better then to have spent a little more time on version 1, so that you can iterate more quickly after that.


      April 23, 2010 at 11:00 am

  8. Quite a realization I had reading that post. Have examples all around of people falling in love with the code, including myself.

    Btw, you misspelt ‘Gandhi’

    Nishant Kyal

    April 23, 2010 at 9:12 am

  9. Hate is such a strong word but I get what you are after and I agree.
    Favoring close to home is a common and very human behavior but very often not in the best interest of anyone involved.

    Release early and often just can’t be taken as a best effort it has to be time boxed and unconditional (hehe this is just so easy to write, I know…) which forces us to disregard such considerations.


    April 23, 2010 at 9:15 am

  10. Do we hate it at the beginning to love it at the end? Or the other way around? Hmm…


    April 23, 2010 at 10:10 am

  11. Just what I needed to hear as I start my latest programming endeavour!

    Sam Dalton

    April 23, 2010 at 10:37 am

  12. Even if you *do* take the rather depressing view that it’s all about customers and money, what about long-term maintainance? Ever heard of a product reaching v2.0?

    What if pouring that extra love into the product in it’s early days would let you move twice as fast when adding features for v2.0? Maybe enabling you to outrun your competitors who are just putting all their resources into reaching feature parity with your first version.

    And if you share my view that it’s also about the people sacrificing significant parts of their life, then what the fuck are you talking about?

    Oh, and don’t listen to Jeff Atwood.


    April 23, 2010 at 11:05 am

    • Ah, but Adde, you’ve missed one point. More likely than not, by putting that extra love in the product in those early days, your competitors who released early blasted ahead of you, got the mindshare, and are winning.

      (At least, if they are doing stuff ‘right’ themselves)

      The biggest thing that you can do, is to make sure to develop a ‘community’ around your product. Get v1.0 out there, and then listen to feedback. There is nothing more than users like, than to actually see their feedback being taken into account, and the product changing.

      Now I do understand your concern about long-term maintenance and being able to reach v2.0 – But therein comes the other catch here.

      The point is, that if you have developed something as simply as possible the first time, it costs very little to throw part of the code away and write it again in the way v2.0 needs.

      That’s actually the core idea behind many of the ‘modern web languages’, such as PHP, versus the more ‘perfect’/’complete’ languages such as Java.

      PHP makes it easy to throw something up, quick, and get it working. Then rip out parts as you need and replace them.

      Whereas Java by it’s nature requires you to start ‘building a system’ in place, developing a deep structure from the ground up. In the process, yes, you need to have deeply thought about the future, to make sure you CAN reach v2.0 without going through that process again.

      (Replace PHP/Java with two other languages of your choice)


      April 23, 2010 at 12:33 pm

    • Are you really suggesting that making people’s lives better is depressing, but rearranging microscopic magnetic fields is fulfilling? 😉

      Writing flexible code that’s easy to extend and modify with future features is entirely different to writing aesthetically-pleasing maximally-refactored code: see the manifesto for flexibility.


      April 23, 2010 at 12:34 pm

    • Seconded – don’t listen to Jeff Atwood. If you’re a junior, yes, the answer should be ‘my own’. If you’re a senior, it better not be – you’re responsible for training other people. If they are already better than you, please give up your title and let them do the work.

      Yes, you should stay humble about your abilities – but please, also take pride in what you do and actually *know* where you’re in relation to others.

      Rachel Blum

      April 23, 2010 at 5:45 pm

  13. Thank you! >:D<

    I needed this article. You've just helped level up!

    Mihai Lazar

    April 23, 2010 at 11:18 am

  14. What a great article – I think you’re spot-on with what you’re saying, and I think (hope!) that I’m just starting to come out of the phase where I’m aiming for beautiful and elegant code instead of features.
    I think, reading through the comments, that some have misunderstood what you’ve said, particularly Adde – this isn’t about writing unmaintainable code to get things done, it’s about letting go of your hubris and not spending too much time making the code ‘just right’ from an artistic point of view.

    Writing code that you love isn’t the same as writing perfectly maintainable code, so writing code that you don’t like isn’t the same as writing unmaintainable code, though they – I hope – are related.

    This also links in with a habit I’ve recently rid myself of – futureproofing for things that I can’t possibly know anything about! Consideration of future requirements is useful, but adding lots of code for features that may never be is futile.

    Thanks @coderoom – your blog looks like it’s got some good content; now onto the flexibility manifesto…

    Rob Desbois

    April 23, 2010 at 11:59 am

    • I disagree, loving and caring about your code is just the thing that is supposed to stop you from futureproofing. You don’t let your ego hurt the ones you love, do you?


      April 23, 2010 at 12:07 pm

      • Of course I intend not to, though I can’t honestly say I never do – sometimes through my own mistakes I might.

        Back to your previous comment “What if pouring that extra love into the product in it’s early days would let you move twice as fast when adding features for v2.0?” – I agree completely with this. I think the point that the article – and Jeff Attwood – are trying to make is that love of your code /for it’s own sake/ isn’t beneficial.

        I doubt any decent software engineer would argue that forethought and care over what you write are a waste of time, but that’s not the point that’s being made.

        Rob Desbois

        April 23, 2010 at 12:21 pm

    • I’m glad you enjoyed it Rob! Trying to futureproof by over-engineering is something most of us do or have done, I think…


      April 23, 2010 at 12:37 pm

  15. LOL! Great post. Some WTFs but a good point of view.

    Mario Guenterberg

    April 23, 2010 at 12:35 pm

  16. Rob: And that’s where we disagree.

    I believe that loving your code is the only thing that’s going to lead to maintainable code. The *so called* maintainable code written by people who don’t have any feelings for it reads like a fucking EULA repeated over and over again.

    And I’m afraid love is precisely what it’s gonna take to save this industry, and this world judging from the recent cascade of incidents where software glitches are causing real physical damage. We have a responsibility to not let our efforts be guided solely by customers and greed.


    April 23, 2010 at 12:54 pm

    • Adde, looking back at some things I’ve developed, I have on a few occasions spent maybe 40% of the total time taken to achieve the following aims, which I expect you’ll agree are important and in production code should always be strived for:
      * fulfilled the initial requirements
      * was sufficiently futureproofed where applicable
      * was readable and maintainable

      I’ve then spent the remaining 60% of time tweaking and fiddling with the code structure and rewriting it not to improve the product itself, but really just chasing after some aesthetic, perfectionist ideal that is actually difficult to achieve.

      Perhaps you’re not as anally perfectionist as I sometimes am.
      Loving what you’re doing enough to create technically good code is obviously a good thing, but being a perfectionist and forever chasing that elusive ‘perfect code’ goal is not.

      It seems to me that you’ve never made this mistake – congratulations to you, that’s great. Nobody’s advocating bad code here, just discussing that we HAVE made that mistake, that’s all.

      Rob Desbois

      May 6, 2010 at 3:38 pm

  17. […] via 7 Reasons to Hate Your Code […]

  18. Adde: there is no use in polishing up the v1.0 because you do not know what the v2 will look like. You really cannot prepare for the unknown.

    Margus, been there, done that

    Margus Freudenthal

    April 23, 2010 at 1:00 pm

  19. I agree! Designing things to fit patterns just because the might be useful in the future or because the code should be beautiful is just wrong. I’m generally critical to anyone who says he/she writes code strictly according to certain patterns simply because this does not comply to the reality of the problem he/she might be facing.

    Mikael Halén

    April 23, 2010 at 1:16 pm

  20. What kind of mindset is this? You’re a web developer, aren’t you? Hahaha… :p


    April 23, 2010 at 2:29 pm

  21. Source code readability might in general be subjective but source code quality is generally not.
    Good quality source contains less bugs and handles exceptional cases well (i.e. http://www.openbsd.org).
    From the marketing department standpoint, time is money and for that reason they will indeed force programmers to sacrifice quality.
    So whether or not you will indeed sacrifice quality for saving time depends on what your primary goal is.
    So i do not see what the main point of this article is, since source code quality and marketing efficiency are two totally irrelevant matters.
    Is this supposed to be an advice on how to become a better `enterprise’ worker?


    April 23, 2010 at 2:40 pm

    • Do you define the quality of the code in terms of what it achieves for the user and its reliability, or in some vague aesthetic terms?

      It’s only the latter definition that leads us to waste time and become unreasonably attached to our existing, inflexible implementation and uninformed choices.

      The advice applies best if you’re founding or working in a startup. If you’re in a large faceless corporation with no contact to the customers and no leeway in defining the product then, well, you have my pity but I think it’s career advice rather than programming advice that you really need 😉


      April 23, 2010 at 3:10 pm

  22. Edit: slightly paraphrased by coderoom

    0 Reasons I Hate This Post:


    April 23, 2010 at 2:48 pm

  23. The first step to recovery is “admitting that one cannot control one’s addiction or compulsion” [1]

    Spot on. There has no day gone by that I had to stop myself and think “If it ain’t broken, don’t fix it”, and consequently reverting back to the state the code was in.

    [1] http://en.wikipedia.org/wiki/Twelve-step_program


    April 23, 2010 at 3:18 pm

  24. This is a good article. I’ve recently started working on a very old project and it looks terrible. The way I do things now is night and day. It will be interesting to see the way I do things a year/6mo from now and say how bad my previous code was.

    ernest leitch

    April 23, 2010 at 4:00 pm

  25. Just wanted to add my voice to the chorus of people who completely agree with you. Once code has passed a certain bar of quality, the returns from refactoring for refactoring’s sake become small compared to other things that can be done to improve the program. The wisdom is in understanding where that bar is.

    Dave Duchene

    April 23, 2010 at 4:08 pm

  26. […] 7 Reasons To Hate Your Code [https://coderoom.wordpress.com/2010/04/22/7-reasons-to-hate-your-code/] […]

  27. […] 7 Reasons To Hate Your Code […]

    • Hey, great article! Yes, we’re on the same wavelength here. Maybe it’s something about startups that the enterprise world doesn’t get (I’m not even sure if it makes sense when you’re six layers away from your users)…


      April 24, 2010 at 1:08 pm

  28. […] 7 Reasons To Hate Your Code « yield thought (tags: bestpractices career code coding dev development interview philosophy programming psychology software technology quality) […]

  29. Love your blog posts. Just went through and read them all, and I couldn’t agree more! Code a lot and do it fast with minimal documentation.


    April 23, 2010 at 7:40 pm

  30. Great post … it’s so important to value code craftsmanship over process. It’s too easy to get mired in Agile busy-work and take your eye off the thing that matters: the code.

    Have fun on your artisan journey!


    April 23, 2010 at 9:35 pm

  31. A very interesting post. To add a few comments:

    o Much of this is a part of more general principle, namely that only those who have humility, self-perspective, and a willingness/ability to see flaws in themselves, their ideas, their work, whatnot, will continue to develop in the long-term. Those who fail here will stagnate—and the sooner they become satisfied with themselves, the sooner they stagnate.

    o Jeff Atwood is horribly wrong. In particular, anyone who says “My own.” is likely to either be a very poor developer, have read very little code recently, or be someone who makes a hypocritical claim to seem insightful/please the interviewer. In neither case, he is a strong candidate. Being self-critical and humble is good—being self-deprecating or offering false humility is a very different story.


    April 23, 2010 at 10:03 pm

    • I like your point on self-deprecation and hypocrisy. After all, developers spend most time writing code (pleasing user is not an activity by itself, in software it can not be achieved by writing code).

      Also, I have seen developers verbally deprecating code they wrote on daily basis. And you know what, they actually wrote horrible code. They just tried to pass their own lazyness and inability to improve for a fundamental and unchangeable quality of their coding.

      Often, people blamed environment and their teams on giving too much constraints and providing bad example, instead of solving these problems themselves (code reviews, better planning, self-education).

      Andrey Shchekin

      April 24, 2010 at 8:15 am

  32. […] 7 Reasons To Hate Your Code Incompetence is the cause of many ills in the software world, but increasingly I’m seeing a certain kind of […] […]

  33. I think this is an ill advice.

    I *love* my code. For now. I just love to write it. My love lasts until the new iteration, at least. Then, it becomes some kind of legacy code, and I’ll be happy to throw it out or change it, because of my new love.

    Hatred should not drive your development (HDD?), tests should.


    April 24, 2010 at 9:12 am

    • Amen – may the love and joy of writing code never end! It’s the unhealthy addiction to perfecting our code for its own sake instead of making it more perfect for the users that I’m campaigning against.

      Love for the user should drive development. Don’t get me started on TDD 😉


      April 24, 2010 at 12:58 pm

      • You’re totally right. This is why I think TDD is good. According to the rules, you should not write a single line of code before having a failing test, but you should not write more than one failing test. Then write some code which makes the test pass, but then, start over (eg. don’t write code).

        If you follow this cycle, you won’t code l’art pour l’art.


        Odds are you’ll end up writing tests l’art pour l’art.

        This is why you’re right too.


        April 26, 2010 at 5:31 pm

      • You make an interesting point, which I’ve expanded upona little. Let me know if you have a blog or something I can link your name to.


        April 27, 2010 at 7:20 am

  34. Thank you, you have given me my “Aha” moment. I have spent years despising what people like Jeff Atwood have been saying about our profession, but now I realize that I thought that way because I was stuck into thinking they thought they were better than everyone else.
    Now I get what they have been trying to get into my thick skull. I believe this new way of looking things will allow me to kick my skills up a notch.

    Monkey With a Keyboard

    April 24, 2010 at 5:04 pm

  35. Awesome post, you’re really making me think long and hard about the code I’ve written lately. I think even when others on your team write crappy code, you should never get caught up in thinking too highly of your own code.

    Great post, keep ’em coming


    April 24, 2010 at 9:05 pm

  36. Amazing post. It gave me a moment of self reflection.

    In the end, I definitely agree with what you said.

    It’s difficult not to be emotionally attached to my own code, but it must be done if I can make any improvement.

    Thanks for the lesson.

    Alan Ning

    April 25, 2010 at 3:10 am

  37. Great Post !! I cant agree more.
    Do you think XP practices are somewhat responsible for this?
    Because most of the agile gurus always talk about code quality and stuff.


    April 25, 2010 at 9:41 am

  38. For those of us who learned to code by DIY and google blog search it is clear that code it’s only a tool-to-and-end and Product justify “bad” code most of the times.

    We might not be first class coders, but we are doers who help spread the beauty of the Internet to end-users as much as them.

    Anyway, thanks for taking the time to write down in words some arguments to helps us “sell” our good-enough coding skills.

    Your prose/quotes will make me come back for sure.


    Pol Moneys

    April 25, 2010 at 11:24 am

  39. […] a comment » While discussing our natural tendency to spend too much time and effort refactoring code, Jul (aka -jul-) raised an interesting point: This is why I think TDD is good. According to the […]

  40. Maybe someone who specializes in green field development can say that the worst code he’s seen lately is his own. A maintenance programmer who says that the worst code he sees is his own is a disaster in the making.


    April 27, 2010 at 6:27 pm

  41. So my white collar is really blue; We’re not artists, we’re workers; And the only object in life is to satisfy other people. Use me as your tool, masters for I was wrong to imagine I could better you.


    April 27, 2010 at 6:54 pm

  42. “it didn’t matter how beautiful the new codebase was. It would cost too much to bring it up to the feature level of the old one”

    Buying a new car costs more than replacing the brakes, transmission and engine of an old beat up car. However, a lot of people rightfully make the decision at some point that future maintenance and reliability costs should count in the evaluation of the necessity of a new car.

    What seems perfectly obvious when talking about cars, seems to be totally missed by manager when thinking about software.

    I recently rewrote the entire back end of the application driving my business. It took a year to build it the first time, and 3 months to completely refactor/rewrite. The cost of the refactoring will very likely be completely recovered in the first month after doing it. How? Because a system that is very inflexible in the old model, is modular in the new one, and this allows me to add in some functionality that two potential clients have asked for. Being able to say I can make that change in a couple of days rather than a couple of months may also allow to me to outmaneuver one of my competitors and land that client.

    So, having beautiful code has tangible value beyond mere aesthetics. Going back to cars – it’s like washing and waxing your ride every week. It may not make your car go any faster, but it will certainly pay off when it is time to sell.

    Matt V

    April 28, 2010 at 4:04 pm

  43. I think all that could be summed up on: You write code for your users, not for yourself. That understanding should be enough to balance the quality of the code you produce and your attachment to it, so you’ll embrace changes to it as needed.


    April 28, 2010 at 5:06 pm

  44. As I understand it, many comments here seem to miss the following point.

    It’s not that you shouldn’t love to code (as a verb), it is not that you shouldn’t love your code (when you’ve written it), it’s just that when you see your code, and you want to change it, you need to ask yourself the question: “Am I changing the code because the code is faulty, or am I changing it because I think it is ugly?”. “ugly” vs. “faulty” is the key here, because “ugly” is a matter of taste, and “faulty” is a matter of ones and zeros, true or false, or vulcan logic so you will. Faulty is testable, ugly isn’t.

    Using the always fit metaphore of cars: you could say a car is beautiful because it is green (sure, you may like it, someone else might not), but it is another discussion if the car runs well.

    class MyCarTest {
    function testAesthetics() {

    class YourCarTest {
    function testAesthetics() {

    Ultimately we all just want passing tests, don’t we? Your test fails, my test passes, who is right? We both are. And that’s exactly why it doesn’t matter. There you go.


    April 29, 2010 at 10:04 am

    • Yes, except I’ve seen plenty of coders that deliver *horrible* code with the argument “but it passes the tests”. Unless you’re doing a one-off, that’s not good enough – somebody will maintain the code base.

      And if it’s unreadable code, you just wasted a good amount of somebody else’s time.

      Readability is why aesthetics matter. (To some extent.)

      Rachel Blum

      April 29, 2010 at 9:23 pm

  45. […] Pro Tweets 7 reasons to hate your code https://coderoom.wordpress.com/2010/04/22/7-reasons-to-hate-your-code/ codinghorror – Fri 23 Apr 7:59 All Things […]

  46. […] 7 Reasons To Hate Your Code « yield thought 7 Gute Gründe warum man seinen eigenen Code hassen soll. Ganz Gute dabei und nette erklärungen dazu Detecting UTF BOM – byte order mark Wie man mit PHP prüfen kann ob eine Datei ein UTF-BOM (Byte Order Mark) enthält. Geht ganz easy. Max Stockner […]

  47. I’m impressed, I have to read it again…


    May 1, 2010 at 6:43 am

  48. […] 7 Reasons To Hate Your Code: Sieben Gr�nde, den eigenen Code zu hassen? Teils humorvoll, teils ernsthaft begr�ndet, gibt der Autor Aufschluss, warum guter Code nicht alles ist. […]

  49. Hi,

    Reasons 4 and 7 seems to be the funniest but reason 1 is exactly my problem all the time 🙂


    René Pardon

    May 2, 2010 at 12:37 pm

  50. […] if you work or play in .NET and want to help us find out how we can love you and not our code then go sign up and we’ll set you up with an account and explain what it’s all about in […]

  51. […] 7 Reasons To Hate Your Code […]

  52. […] doing anything – it was letting me do what I wanted. It had been designed by people who loved me more than their product (as Gandhi says you should). Was that all? Yes, because playing around for twenty minutes was all I […]

  53. […] PDRTJS_settings_1865847_post_456 = { "id" : "1865847", "unique_id" : "wp-post-456", "title" : "7+Reasons+To+Hate+Your+Code", "item_id" : "_post_456", "permalink" : "http%3A%2F%2Ffourthchamber.wordpress.com%2F2010%2F06%2F08%2F7-reasons-to-hate-your-code%2F" } Incompetence is the cause of many ills in the software world, but increasingly I’m seeing a certain kind of competence as being just as destructive. You see, there are a lot of programmers who care deeply about their code. I did, but it turns out there are good reasons we shouldn’t do that; reasons why we should hate our code… Read More… […]

  54. This is a silly, hypocritical article.

    First of all, if you *truly* hated your code, then you would not do it. The author assumes that you will go along with him in a I-don’t-mean-it-really-I-am-of-course-just-being-sensational-but-you-get-my-drift?

    So if we go along with him on his first point, and “hate our code”, then when we have to change it to accommodate a new user-feature we should be pleased to do it because it was, after all, so horrible? Nah! I don’t buy it, and I suspect neither does he.

    He, just like the rest of us, is vain but he wants to wear his vanity on his sleeve for redemption – a sort of modern day Edward the Confessor (another hypocrite).

    The error he makes is assuming that “the code” (or rather his version of “code”) is some abstract thing that is divorced from “the features”. Not all programmers are like this e.g. embedded (or “hardware” engineers) from washing machines to toothbrushes (my toothbrush wails at me when it wants recharging). He, I am guessing, is talking about some fancy PC based GUI thing that might or might not have a zillion useless features.

    It just goes without saying that folks do what they want to do and if that happens to be writing code then they like doing it and like it best when they love it.

    The code I loved the best is actually a piece of hardware – it took about a couple of days to make and used one d-type connector, one plastic box, one IC and two LEDs and one battery – it was the *simplest* solution to the problem (I will bore you with it sometime) that I could think of.

    Now I was so proud of this that I mentioned it to another contractor some years later and *he* had been given the exact same problem and he came up with the exact *same* solution!

    This is because there *is* only *one* solution. (that is the best).

    What the original hypocrite is trying to say, in his first “reason” is that one’s code should be the minimum necessary i.e. what everyone always says (but then never does).

    Personally I try to never ever ever ever ever use the phrase KISS because anyone who says that is simply projecting their own complexes onto others – just like the guy who says “I’ll pay you back tomorrow” or “Without a word of a lie.” he won’t and he does.

    Which brings up the second “reason” – it is so horribly obsequious – here it is in full

    You can tell a competent software developer from an incompetent one with a single interview question: “What’s the worst code you’ve seen recently?”
    If their answer isn’t immediately and without any hesitation these two words: “My own,” then you should end the interview.
    – Jeff Atwood

    What a boring arse-licker – at the very least he could have been a bit more inventive e.g. “Dunno, I’m too stupid to know.” or better still “Sorry but I don’t understand the question.” followed by “Is that the right answer?” while pulling a Neanderthal face.

    This second “reason” is a “lightly paraphrased” version of the old psychologist’s question: “Do you tell lies?” that expects the correct answer of “Yes.” but should, in my book, receive something sarcastic such as “That is not unmeaningless.” or something more to the point such as “That is self-referencing.”

    Who the hell is Jeff Atwood anyway?

    Notice how this guy is quoting “Jeff Atwood”, “Mahatma Gandi” and “Jesus” every other line. It stinks! It’s ghastly! – as Mae West once said “What do ya want little man? Status?” (no she didn’t – I just made that one up).

    Robin Pain

    Disclaimer: All opinions expressed above are not necessarily those of the management and no offense is intended, except to the original, anonymous author – who is evidently too “modest” to claim it.

    Robin Pain

    June 18, 2010 at 12:02 am

    • Robin, this would have made a fine blog post; unfortunately nobody’s going to read the 80th comment on an old article. Except me, because I get email notifications 🙂

      Have you confused “Hate your code” with “Hate writing code”? I love writing code and I hope everyone in our profession does. What the post argues is that if you love the code you’ve written for its own sake, then you’re directly and indirectly harming its users.

      It’s about writing software for other people to use. Maybe it doesn’t apply to toaster microcontrollers and one-off bits of hardware for your own use.

      I’m curious as to how you managed to find my blog without ever having heard of Jeff Atwood. You should check out Joel Spolsky and Paul Graham too.


      June 18, 2010 at 6:53 am

  55. […] 7 Reasons To Hate Your Code (coderoom.wordpress.com) from → Book Club ← Monastic With a Day Job – The Ladder No comments yet Click here to cancel reply. […]

  56. I usually fall on side of caring a lot about the code. I don’t think that’s always a bad thing. When I’m in situations that require some counter balance to this inclination, I’ve found the following mantra useful:

    If the code is reusable and the company goes out of business, is the code still reusable?


    July 25, 2010 at 4:57 pm

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: