Should managers write code?

November 28, 2015 - 6 minutes read - 1247 words

Reminder, this blog represents my own opinions only and is on no way affiliated with my employer, Audible or Amazon. Still I think these thoughts are pretty common.

In 2014, I moved from a software development role on my team to managing it. During the time since, I slowly began to write less code, made a concerted effort to contribute on some projects, pick up bug fixes on critical projects, help with low severity issues, and do some side projects. I won’t pretend that the approach I’ve settled on is best for all managers, but I’ve found this to work well for me, and more importantly my team.

My code commits for 4 years at Audible

In full transparency, here is my chart of code commits across the Amazon code base. In fairness, small commits don’t tend to show well here, so the huge gaps in 2015 are mostly a case of smaller changes here and there rather than a total drop off. However, the drop off since switching to managing is fairly stark. So is this normal? Is it a problem?

Why Managers Should Not Code

There are a variety of reasons for managers, even ones with a technical background to stay out of their team’s code. The entire reason I moved into management was to focus on team and individual growth and career development. Every time I step in to solve a problem or write a line of code, that’s a problem someone on the team can’t learn from or a line of code they aren’t writing and improving.

Sometimes you can’t decide between Eclipse or IntelliJ, so you get two laptops

At Amazon, we strive to constantly improve the bar of our teams through hiring. This means that in the four years since I was hired, every single person hired since is better than me at something, typically coding and problem solving. I’ll admit freely and proudly that if I interviewed as a developer now, I don’t think I’d be hired. This is a good thing for growth and constant improvement. If I were to step in and prevent a team member from writing code or solving a problem, it means that we have lost a good opportunity for improvement.

Amazon deliveries in NYC. Each year the bar gets higher.

Lastly, my code is probably not super awesome now. Like any art, yes programming is an art, it requires hours of practice and keeping up with it to stay professional. With code reviews, the team can help with this, but how often are they going to tell the person they report to that their code is terrible? I believe I have a strong relationship with my team, but even I’m not deluded enough to believe in that level of transparency.

Why Managers Should Code

So in general, I don’t think managers, at least ones who prioritize the growth of their team members over short term objectives should be coding as part of the team. However, this doesn’t mean they shouldn’t be coding at all. There are several times I’ve jumped into coding last minute on a project to help with some small issues where developer’s time is better spent on harder problems. Fixing CSS or debugging some service call is not a super demanding task and if time permits to jump in, it can be a good way to better understand the problems the team is facing. I find that there is no better way to understand a code base and find areas to improve than to get into it elbow deep. Similarly, working on bugs that affect only a few customers, or aren’t in the critical path is also a good way to stay aware of the state of the code base, understand the product and customers better, and keep some skills sharp.

My dog tried to do too much coding and fell asleep

The Importance of Side Projects

A dog dressed as a lobster for Halloween at Amazon’s Seattle office. Don’t let others define you.

Since I’m advocating that managers don’t do much coding within their teams, that thirst for knowledge any good technologist has needs to be satisfied somehow. This comes with side projects. A side project is traditionally something you do on the side, i.e. at home, but I think there is plenty of room for side projects at work as well. Sure, you may not get a ton of time for this during the hustle and bustle of normal work hours, but for any strong technical manager, you’ll find a way to make time. I have always been a fan of the saying that “there is no such thing as no time for something, there is only a lack of prioritization.” If you are truly passionate about learning new technologies and getting better as a computer scientist, you’ll prioritize it. I’ve worked on a few side projects in my management time. Here are some examples that might help spark some ideas for you.

Contribute to the company hackathon as a developer. This past year I worked on an android app for the first time, learned about Facebook and Twitter social cards and sharing, and learned a lot more about streaming technologies all through hackathon projects. If you don’t have a company hackathon, start a team one. The creativity and morale boost that comes out of it will astound you.
Write some integration tests, or even better, try to build a better test automation or integration testing system. I took an existing service testing framework that was deprecated from lack of features and use and enhanced it to work with our services. We didn’t end up using it, but it taught me a lot about our architecture as well as how to build a good testing framework (hint: minimize manual writing of test data)
Build a side project using your company’s API. Our API is still in beta, but a few parts of it including authentication and catalog data are available internally, so I wrote a small web site that would grab this data and display it, using only end user facing APIs. I learned a ton about Login with Amazon, REST, JSON, and a ton of Java third party tools in the process.
Set up a website on AWS. AWS has become an essential part of any developer’s toolbox and I don’t just say that because I work for Amazon. A huge number of tiny start ups build on it as do huge players like Netflix. Just setting up an RDS database, EC2 host, load balancer, SSL cert, domain name mapping, and reading from the DB was a hugely rewarding, though sometimes frustrating lesson in a ton of things. I feel more powerful and certainly more useful as a result.

Amazon’s newest Seattle buildings. There’s a mini golf course on the sky bridge, the only place at Amazon where we don’t want to raise the bar / par

Again, there is not one size fits all approach for managers. My approach has been to do enough coding to keep relevant, be able to deep dive on issues and solutions, and earn the respect of my team, but never at the cost of harming development opportunities for team members. The beauty of a large tech company is that there is room for many approaches and people with different approaches naturally balance each other. Whatever approach works best for you is one worth sticking to, provided you can find that balance.