Guilty Developer Syndrome

Half the battle of writing software is crystallising what it should do, in detail. As you discover new edge cases and assimilate them into your code it's very easy to cling on to your initial vision for the architecture. When you return later on and look at the finished product it's all too easy to see that there's a better way to do things. Often you already know this by the time you're finished but you hit a deadline and the next feature/project takes priority over the refactoring.

What seems to happen with me is that I'm fairly happy with the initial release. Then as the changes start piling on, eventually one of them will require a major conceptual change. Of course that could take months, or you can put a band-aid on in 2 days. In this day and age of startup mentality I don't know many programmers who are afforded the luxury to spend months on a task that can be hacked in a few days. Anyway, the code can survive a few rounds of that before it starts getting really ugly and then I'm apologizing with the best of them.

The examples given so far don't necessarily translate to situations where I feel devs <i>should</i> feel guilty/bad, but there are situations, and I've left some messes behind in my day, often which I wasn't aware of at the time. I've taken over projects where the dev(s) should have known better, and in some cases <i>did</i> know better than what they delivered.<p>If you <i>never</i> feel guilty/bad about any code you've ever left behind - <i>never</i> - there's something wrong with you. You shouldn't go through life apologizing for every line of code either, but there's a balance to be struck somewhere that probably shifts over time.

I've had this feeling before and I've worked with people who express this feeling. My question is, what is the alternative to having this feeling.<p>You want to show that you are now knowledgable of better methods and you would like the criticizer to recognize that your mistakes are not ones that you are still making. Furthermore, you can't really blame the criticizer, they're just trying to help you become a better programmer.<p>It seems all you can really do is give the sheepish grin and say "yeah, well, that was written at a very foolish time in my life..."

Guilty developer syndrome is arguably a good thing. The reason being that having it means a developer <i>doesn't</i> have Nothing's Wrong, Everything Is OK Syndrome. That's the one you have to watch out for.

Paring helps to alleviate this guilt to some degree. By hashing out technical decisions with at least one other reasonably intelligent person and coming to an agreement, you can have just a little bit more confidence than if you were working on your own.

Yup. Similarly, one person I'm working with who is a good coder but who happens to have a bit less experience apologizes whenever I find a bug in his code. I just want to tell him, "don't apologize, bugs are just part of the game!" There are bugs in my code too ;) We fix them, and move on.

I've been taking the "then send me a pull request"-approach lately. There's no reason to be embarrassed about making something (even if it's sloppy) - especially if the person pointing out the flaws hasn't built anything themselves.

The post has some really nice points. Specifically that you can never know 100% of everything and most probably you won't make the best design decisions every time. The point is to manage to not feel bad when you (or someone else) finds out that something could have been developed in a better way but instead learn from it and use it in the future.

This always reminds me of the quote "Great art is never finished, only abandoned".