Things learned from a senior developer

Dear new developer,

This post by a Bloomberg developer catalogs everything they learned sitting next to a senior developer for a year. Lots of good stuff in there. Favorite excerpts:

How to handle an outage:

For when things go wrong, and they will, the golden rule is minimizing client impact.

My natural tendency when things went wrong were to fix the problems. Turns out, it’s not the most optimal solution.

Instead of fixing what went wrong, even if it’s a “one line change”, the first thing to do is rollback. Go back to the previous working state. This is the quickest way to get clients back on a working version.

Only then should I look at what went wrong and fix those bugs.

This is really good advice. When you are under pressure in a production outage, the tendency to try to figure out what is going on can be very powerful. However, figuring out the root cause of the issue is probably not as important as restoring functionality to your end users. Roll back. If you won’t be able to replicate the issue in your staging environment (due to load or some other reason) save off your logfiles and note the start and end times of the outage for further analysis (slack is good for that).

On code reviews:

Code reviews are amazing for learning. It’s an external feedback loop on how you’d write code vs how they write it. What’s the diff? Is one way better than the other? I asked myself this question with every code review I did: “Why did they do it this way?”. Whenever I couldn’t find a suitable answer, I’d go talk to them.

After the first month, I started catching mistakes in my teammates codes (just like they were doing for mine). This was insane. Peer reviews became a lot more fun for me – it was a game I looked forward to – a game to improve my code-sense.

My heuristic: Don’t approve code till I understand how it works.

Code review is definitely a skill worth practicing. You don’t want to nitpick and I’m a fan of automated linters/code style enforcers. That way you can have all the ‘where does the brace go’ arguments once, and then have the rules automatically enforced. Of course you can look for bad variable and function names, and that is valuable (and non automatable). But in my mind there are two aspects code review that are harder, but more important:

• How does this fit into the overall system. Are there other components that should use this code or be used by this code? Is this structured correctly?
• Do I understand this code and what it is trying to do. This means you need to understand the problem that the code is solving.

The whole thing is worth a read.

Sincerely,

Dan