Congratulations on becoming a coding rock star! You can do anything you set your mind to. You might not be ten times more productive than the average engineer, but you’re probably six or seven times more productive.
This now puts you in an unstable equilibrium. Sooner or later someone is going to notice how good you are at building software, and they’ll ask you to take on some form of leadership or management role, in which you’ll be primarily responsible for getting other people to build software. Welcome to a life spent in meetings, doing “coordination.”
In all seriousness, even if you never get asked to manage other developers, understanding the principles of how to manage software teams will make you a better engineer. These two books are each a quick read and will equip you with an entire toolbox of ideas about how to make teams work well.
The first book to read is The Mythical Man Month, the classic software engineering text by Fred Brooks. There are any number of things that you can disagree with in Brooks’ treatise, but the logic of Brooks’ Law is fundamental in understanding how to deal with late projects. It’s been 40 years since he made the excellent argument that adding more people to a late project makes it later, and yet, even at enlightened software companies like Google, the first reaction to a late project is to add more engineers.
Once you’ve read Mythical Man Month, and you can argue successfully with your manager about how to make the right tradeoffs between schedule, quality, and features, it’s time to learn a little about how successful software organizations treat their people. For this, you need to pick up the classic Peopleware by DeMarco and Lister. A lot of people espouse theories about how to operate software organizations; these guys did the research and the experimentation to demonstrate what makes a difference between the mediocre software shops and the stellar operations.
I am proud to say that I no longer own a copy of Peopleware. Back in early 2003, when Sergey would still come out to NYC and hang out with the nascent engineering team out here, I managed to get him into a debate about running engineering organizations, and I learned that he had never read Peopleware. The next day I pressed my copy into his hands, and told him to just take it, as long as he promised to read it. We still don’t have private offices at Google, so I’m not sure if he ever actually read it, but at least I tried.
Congratulations on making it this far. Upon finishing these books, you will now be qualified for a degree in Software Engineering in the Real World. Tomorrow, just for kicks, I'll share a few more interesting reads that wrap up many of these ideas in a fun package.