

Why your previous developer was terrible - sshamoon
https://medium.com/p/506a06ae35ea

======
collyw
Sometimes the previous developer really is that bad.

I inherited a colleagues work after she left. One cron Job to launch a Python
script - auto-everything.py. Which in turn spawned new shells to launch a load
more scripts. One script even launched itself with new arguments. So trying to
work out where stuff was failing was a nightmare, before I even got to look at
the code.

Then the fun really began. Functions within functions, not to anything smart -
just because she hadn't bothered to work out how the module system works. Few
comments which were fairly useless "#Open file" above an open file statement
(what the hell is contained in the file??? Add that to your comment).
'Indexes' and 'indexes' used as variable names in that function. Big nested
hash structures with no explanation to its structure, or what it was for.

------
christiangenco
I often find that even when looking back on my own projects from just a few
months ago - projects that are 100% my own creations - I'm often horrified at
design decisions I made.

There really is something to be said for the advantage of having the complete
picture laid out in a working implementation over crafting something from
scratch with only abstractions to work with.

I've grown to greatly respect projects that do what they're supposed to do
regardless of their whacky and inelegant implementations. Sure I could rewrite
it to cut out half the bloat, but so could the guy who wrote this version.

~~~
collyw
I find the same thing sometimes. Though I usually use that as an opportunity
to ask, why it is so bad, and what it would look like if it was done properly.
Refactor from there if I have the time. If I don't have the time to refactor,
at least write a comment explaining the nasty part - that way it should be
easier to comprehend the next time.

------
rartichoke
I skimmed it honestly, it didn't hold my attention long enough but your
opening paragraphs were good and I definitely agree with what the article was
saying.

Also the current dev has no idea what the old dev's payment was like either
and I feel like this could be a huge deciding factor in the quality of work
provided by the old dev.

------
pjmorris
The thought expressed in the post reminds me of Norman Kerth's Retrospective
Prime Directive [1], [2]:

"Regardless of what we discover, we understand and truly believe that everyone
did the best job they could, given what they knew at the time, their skills
and abilities, the resources available, and the situation at hand. At the end
of a project everyone knows so much more. Naturally we will discover decisions
and actions we wish we could do over. This is wisdom to be celebrated, not
judgement used to embarrass."

[1] 'Project Retrospectives: A Handbook for Team Reviews', Norman Kerth

[2]
[http://www.retrospectives.com/pages/retroPrimeDirective.html](http://www.retrospectives.com/pages/retroPrimeDirective.html)

------
theandrewbailey
At my last company, I was working on a Java EE Struts app. After a few months
of despairing over how bad it was, I realized that it was built by database
people. That's why most of the logic was in sprocs, and they had no clue of
what thread safety was, or how to build a HTML widget and menu system that
consistently worked. Thank goodness that they knew about parametrized SQL.

------
Throwadev
I've found that no matter how good you were, as soon as you're gone you're
fair game for being scapegoated.

------
sshamoon
Would love any feedback

~~~
aidos
I really enjoyed this article, thanks.

As you point out, we're all guilty of being on both sides of this. Just
recently I took ownership of a project for a couple of months while it was
transitioned between companies. I found myself in the curious position of
being aware of being the scapegoat. It made me really aware of defending the
previous team as I knew full well there would be code I'd written that would
get bad mouthed if that culture was created. It was suitably humbling.

