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

The Art To And Power Of Saying No

Dear new developer,

There’s an art to saying no. And there’s power in doing so.

I worked on a project that was creating a Yahoo clone early in my career. The lead developer got sick. I said “yes, I can help.” I jumped in and helped out, a lot. I ended up working 96 hours in a single week. The site launched. I was thanked by my company with … a t-shirt and six-pack of beer.

I have learned since then how to say no.

The art is in saying no without being a jerk, and to making sure that everyone realizes that they are all on the same team. My best advice for that is to flip things around and say “yes, but.” “Yes, I’m happy to shift to working on task B, but should I finish task A first.” “Yes, I can help you with the release, but Jane is waiting on this feature.” This makes it clear that you are happy to help, but have other obligations as well.

After you describe the two options, ask for prioritization. Especially as a new developer, you simply don’t have the bigger picture. Maybe task B is blocking three other developers from making forward progress. Maybe that release is really important because of a bug fix that needs to go out before the launch of a new product. I have never once been dinged when I asked for prioritization. It shows that you care about working on important things, are aware that there is a bigger picture, and are flexible.

However, be aware that as soon as you juxtapose two tasks that both need to get done, you will be asked to estimate those tasks. Practice that, as it is a skill you’ll need as a software developer.

The power of saying no is in protecting your time. You only have one life to live (#yolo). When you have a salaried job, there’s very little downside to your company in trying to take more hours. Even if they are really nice people, you are the person responsible for establishing and protecting your boundaries. If you say yes all the time, you may end up working a lot of hours.

The other issue is that it feels good to work, especially as a new developer. “Look, I’m getting stuff done.” “I’m building cool stuff.” But the point of life is to live, not just to work. As I look back over my career, I’m proud of what I’ve built, but a lot of what I’ve built is gone. Don’t let a company suck you in and not learn to live a life.

Learn to say no.

Sincerely,

Dan