Hacker News new | ask | show | jobs
by dranka 2312 days ago
If you are working on an old code base for a reasonable time I recommend to get to know the old developers. Check out the commit history, who wrote what, talk with them a bit if they are still around to get a feel for them. After a while you will probably see patterns, guy A usually wrote solid code, guy B a bit more sloppy. If you are investigating a bug in a specific area of the code use git blame and start investigating any additions by guy B first
2 comments

Also, have the humility and the generosity to assume complex code is that way for some reason. The people who came before you are not likely to be such bigger idiots than you. If something looks wacko, slow down and ask yourself how it got to be that way.
1. Get to know old developers 2. Then decide whether to have humility or not on a case-by-case basis.

There are idiots out there.

When do you think humility isn't warranted?
This is a rule of thumb. You should always check your assumptions about code being correct or not. However, if somebody and their code have proven themselves unreliable, it is a useful optimization to first consider they are wrong, instead of first considering they are right (humility.)
Whenever reviewing things to identify potential issues. If you assume (even justifiably) competence, you'll miss the real issues that exist.

OTOH, when proposing to make changes of your own, humility is definitely called for.

If you were lucky enough to contact them that is! Attrition rate is such these days that many coders simply flee after a release or so, also depends on how old the code-base is. Git or other version control systems come quite handy, I agree.
Yes definitely. But only reading the code and looking at the history can sometimes be enough to build the picture when the same names repeatedly show up in troublesome code
..in my experience it can also lead to antagonistic thoughts about people who I have never met and only know through the code they wrote :)