Guilty Developer Syndrome(22ideastreet.com)
22ideastreet.com
Guilty Developer Syndrome
http://22ideastreet.com/blog/2010/02/02/guilty-developer-syndrome/
14 comments
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.
This, to me, has a lot to do with the languages and tools used on a project - the more 'locked in' to a structure you are, the bigger that cost will be when something changes.
This has been a concern of mine w.r.t. oop as implemented in C# (and by extension java), as the structure can be very costly to change down the line when the inevitable 'pivot' in implementation occurs.
This has been a concern of mine w.r.t. oop as implemented in C# (and by extension java), as the structure can be very costly to change down the line when the inevitable 'pivot' in implementation occurs.
True and it seems like no matter how much foresight I have and how much abstraction we code in, eventually some change comes along that nobody saw coming.
The examples given so far don't necessarily translate to situations where I feel devs should 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 did know better than what they delivered.
If you never feel guilty/bad about any code you've ever left behind - never - 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.
If you never feel guilty/bad about any code you've ever left behind - never - 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.
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.
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..."
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.
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..."
The alternative is to be a smug overconfident jerk who trots out outdated or sometimes entirely wrong justifications for ill considered design decisions. The alternative is being a developer who continues to do things day after day in bash and C because Perl and Python are "too heavyweight".
Feeling guilty shows that you've grown and that you know more today than you did when you built the system you're feeling guilty about. I'll take the guilty feeling as a side effect of growth when the alternative is stasis and stagnation.
Feeling guilty shows that you've grown and that you know more today than you did when you built the system you're feeling guilty about. I'll take the guilty feeling as a side effect of growth when the alternative is stasis and stagnation.
There is a rational middle ground.
Guilty developer syndrome is arguably a good thing. The reason being that having it means a developer doesn't 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".