The Do-it-Yourself Degree in Software Engineering: Bonus Round

So it’s six months later, you’re a coding rockstar, you know how to run a team, your organization follows the principles laid out in Peopleware, and now you’re wondering, “Hey, what’s next?” Here are some great reads that are illuminating but not part of the required curriculum. I consider everything I’ve posted earlier as the basic cost of doing business as a professional software developer. These are just for fun, but still very useful in making you an excellent engineer.



Dreaming in Code presents a sweeping view of the history of software engineering, told through the lens of Mitch Kapor and the Open Source Application Foundation’s efforts at developing Chandler, the Personal-Information-Manager-That-Will-Totally Change-Your-Life-If-We-Could-Ever-Ship-Running-Code. It brings together many of the lessons of the Mythical Man Month and Peopleware in the context of a real effort at building a new product.

Go To is another great history of software, focusing more on the sequence of technical developments between World War II and where we find ourselves today. The exciting running thread throughout the book is the number of great advances that have been made by individuals building the exact tool to suit their own needs. If there was every a compelling argument against software design by committee, this is it.

The Innovator’s Dilemma is an excellent read because it shows over and over how entrenched players in a market are unseated by small teams working with great focus on an emerging market or technology. Every time someone tries to convince me that Google can never be unseated from a position of dominance in search, or that Microsoft and Yahoo are the companies we should be concerned about, I tell them to read this book. For a big company, the competition isn’t the hundred-billion-dollar software shop down the road, it’s a few folks in an apartment somewhere using sheets of plywood for desks and borrowed hardware.

There’s a great flipside to the Innovator’s Dilemma, too: if you’re thinking of building something, and you think it’s going to go up against some established megacorp, take inspiration from the number of times that some unproven David has taken down a Goliath.

Lastly, In Search of Stupidity presents a unique perspective on how so many software companies managed to compete with Microsoft and fail completely. The underlying thesis of the book is that Microsoft isn’t necessarily that great, but everyone else is so bad; Microsoft happens to be the one software company that didn’t make any horrendously stupid mistakes in the eighties or early nineties. You can debate that thesis, but it’s still entertaining to read some of the brain-dead things that Microsoft competitors did.

This is now the final final conclusion of my list. Please let me know if you end up reading any of these on my recommendation, and let me know what you think of the books. Enjoy.

The Do-it-Yourself Degree in Software Engineering: Software Engineering Management

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.