It’s the same story. We idolize him, but the fact is that he didn’t win every basketball game by himself. His true genius was in the way he worked with his team. The team’s coach, Phil Jackson, was extremely clever – his coaching techniques are legendary: he recognized that one player alone never wins a championship and so he assembled an entire “dream team” around MJ. The team was a well-oiled machine – at least as impressive as Michael himself.
So why do we repeatedly idolize the individual in these stories? Why do people buy products endorsed by celebrities? Why do we want to buy Michelle Obama’s dress or Michael Jordan’s shoes?
Celebrity is a big part of it. Humans have a natural instinct to locate leaders and role models, idolize them, and attempt to imitate them. We all need heroes for inspiration, and the programming world has its heroes too. The phenomenon of “techie-celebrity” has almost spilled over into mythology. We all want to write something world-changing like Linux or design the next brilliant programming language.
Deep down we all secretly wish to be geniuses. The ultimate geek fantasy is to be struck by an awesome new concept. You go into your Batcave for weeks or months, slaving away at a perfect implementation of your idea. You then “unleash” your software on the world, shocking everyone with your genius. Your peers are astonished by your cleverness. People line up to use your software. Fame and fortune follow naturally.
But hold on: time for a reality check. You’re probably not a genius.
No offense, of course—we’re sure you’re a very intelligent guy or gal. But do you realize how rare actual geniuses really are? Sure, you write code, and that’s a tricky skill that probably puts you in a bracket above a lot of the human population. But even if you are a genius, it turns out thatthat’s not enough. Geniuses still make mistakes, and having brilliant ideas and elite programming skills doesn’t guarantee that your software will be a hit. What’s going to make or break your career is how well you collaborate with others.
It turns out that this Genius Myth is just another aspect of our insecurity. Most programmers are afraid to share work they’ve only just started, because it means peers will see their mistakes and know the author of the code is not a genius. To quote a programmer from Ben’s blog:
I know I get SERIOUSLY insecure about people looking before something is done. Like they are going to seriously judge me and think I’m an idiot.
This is an extremely common feeling among programmers, and the natural reaction is to hide in a cave and work, work, work. Nobody will see your goof-ups; you still have a chance to unveil your masterpiece when you’re done. Hide away until all of it is perfect.
Another common motivation for holding your cards close to your chest is the fear that another programmer might take your idea and run with it before you get around to working on it. By keeping it secret, you control the idea.
We know what you’re probably thinking now: so what? Shouldn’t people be allowed to work however they want?
Actually, no. In this case we assert that you’re doing it wrong, and it is a big deal. Here’s why.
Hiding Is Considered Harmful
If you spend all your time working alone, you’re increasing the risk of failure and cheating your potential for growth.
First of all, how do you even know if you’re on the right track?
Imagine you’re a bicycle-design enthusiast, and one day you get a brilliant idea for a completely new way to design a gear shifter. You order parts and proceed to spend weeks holed up in your garage trying to build a prototype. When your neighbor – also a bike advocate – asks you what’s up, you decide not to talk about it. You don’t want anyone to know about your project until it’s absolutely perfect. Another few months go by and you’re having trouble making your prototype work correctly. But because you’re working in secrecy, it’s impossible to solicit advice from your mechanically inclined friends.
Then one day your neighbor pulls his bike out of his garage with a radical new gear-shifting mechanism. Turns out he’s been building something very similar to your invention, but with the help of some friends down at the bike shop. At this point you’re exasperated. You show him your work. He points out that your design had some simple flaws – ones that might have been fixed in the first week if you had shown him.
There are a number of lessons to learn here. If you keep your great idea hidden from the world and refuse to show anyone anything until the implementation is polished, you’re taking a huge gamble. It’s easy to make fundamental design mistakes early on. You risk reinventing wheels.1 And you forfeit the benefits of collaboration too: notice how much faster your neighbor moved by working with others? This is why people dip their toes in the water before jumping in the deep end: you need to make sure that you’re working on the right thing, you’re doing it correctly, and it hasn’t been done before. The chances of an early misstep are high. The more feedback you solicit early on, the more you lower this risk.2 Remember the tried-and-true mantra of “Fail early, fail fast, fail often” – we’ll discuss the importance of failure at length later in the book.
Early sharing isn’t just about preventing personal missteps and getting your ideas vetted. It’s also important to strengthen what we call the bus factor of your project.
Bus factor (noun): the number of people that need to get hit by a bus before your project is completely doomed.
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.
