4 ms·

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 w

by dranka 7y 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

el_programmador 7y ago
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.
- dranka 7y ago
  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
  - dranka 7y ago
    ..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 :)
jeffrallen 7y ago
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.
- dottedmag 7y ago
  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.
  - betenoire 7y ago
    When do you think humility isn't warranted?
    - mqnfred 7y ago
      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.)
    - dragonwriter 7y ago
      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.

by dranka 7y ago

el_programmador 7y ago

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.

dranka 7y ago
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
- dranka 7y ago
  ..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 :)

jeffrallen 7y ago

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.

dottedmag 7y ago
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.
- betenoire 7y ago
  When do you think humility isn't warranted?
  - mqnfred 7y ago
    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.)
  - dragonwriter 7y ago
    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.