News

Debugging teams: Creating relationships to get things done

Since this is a book about the social perils of creative development, it makes sense to focus on the one variable you definitely have control of: you.

People are inherently imperfect. But before you can understand the bugs in your coworkers, you need to understand the bugs in yourself. We’re going to ask you to think about your own reactions, behaviors, and attitudes – and in return, we hope you gain some real insight into how to become a more efficient and successful software engineer. You’ll end up spending less energy dealing with people-related problems and more time writing great code.

Before we get ahead of ourselves, let’s start by observing how programmers behave in general.

Help Me Hide My Code

The two of us have been speaking at programming conferences quite a bit for the past ten years. After launching Google’s open source Project Hosting service back in 2006, we used to get lots of questions and requests about the product. Back in mid-2008, we noticed a distinctive trend in the sort of requests we were getting:

Can you guys please give Subversion on Google Code the ability to hide specific branches?

Can you guys make it possible to create open source projects that start out hidden to the world, then get revealed when they are ready?

Hi, I want to rewrite all my code from scratch, can you please wipe all the history?

Can you spot a common theme to these requests?

The answer is insecurity. People are afraid of others seeing and judging their work in progress. In one sense, it’s just a part of human nature – nobody likes to be criticized, especially for things that aren’t finished. This attitude tipped us off to a trend within software development. Insecurity is actually the symptom of a larger problem.

The Genius Myth

The two of us lived in Chicago throughout the 1990s and got to witness the amazing run of championship wins by the Chicago Bulls. The national media was saturated for years with stories about this amazing basketball team. But what did TV and newspapers really focus on? Not so much the team, but Michael Jordan, the superstar. Every player around the world wanted to be MJ. We watched him dance circles around other players. We watched him in television commercials. We went to see silly movies where he played basketball with cartoon characters. He was a star, and every kid on every court practicing hoops secretly wished to grow up and follow his path.

Programmers have that same instinct—to find idols and worship them. Linus Torvalds, Richard Stallman, Bill Gates – all heroes who changed the world with heroic feats. Linus wrote Linux by himself, right?

Actually, Linus just wrote the beginnings of a proof-of-concept Unix-like kernel, and showed it to an email list. That was no small task, and it was definitely an impressive achievement, but it was just the tip of the iceberg. Linux is hundreds of times bigger than that and was developed by hundreds of smart people. Linus’s real achievement was to lead these people and coordinate their work; Linux is the shining result of their collective labor. (And Unix itself was written by a group of smart people at Bell Labs, not entirely by Ken Thompson and Dennis Ritchie.)

On that same note, did Stallman personally write all of the Free Software Foundation’s software? He wrote the first generation of Emacs. But hundreds of others were responsible for bash, the GCC tool chain, and all the rest of the software that runs on Linux. Steve Jobs led an entire team that built the Macintosh, and while Bill Gates is known for writing a BASIC interpreter for early home computers, his bigger achievement was building a successful company around MS-DOS. Yet they all became leaders and symbols of their collective achievements.

This is Chapter 1 from “Debugging Teams,” by Brian Fitzpatrick and Ben Collins-Sussman; cross-reference links to other areas of the book will be broken, as this chapter is excerpted from a larger work.

Leave a Comment