

Guilty Developer Syndrome - panozzaj
http://22ideastreet.com/blog/2010/02/02/guilty-developer-syndrome/

======
ollysb
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.

------
jakejake
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.

~~~
singular
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.

~~~
jakejake
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.

------
mgkimsal
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.

------
DanielN
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..."

~~~
quanticle
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.

~~~
sopooneo
There is a rational middle ground.

------
j_baker
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.

------
alinajaf
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.

------
radarsat1
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.

------
swanson
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.

------
LefterisJP
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.

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

