Hiding Considered Harmful
The Genius Myth
Deep down, many engineers secretly wish to be seen as geniuses. This fantasy goes something like this:
- You are struck by an awesome new concept.
- You vanish into your cave for weeks or months, slaving away at a perfect imple‐mentation of your idea.
- You then “unleash” your software on the world, shocking everyone with yourgenius.
- Your peers are astonished by your cleverness.
- People line up to use your software.
- Fame and fortune follow naturally.
“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 reactionis to hide in a cave, work, work, work, and then polish, polish, polish, sure that no one will see your goof-ups and that you’ll still have a chance to unveil your master‐piece when you’re done. Hide away until your code is perfect.
Another common motivation for hiding your work is the fear that another program‐mer might take your idea and run with it before you get around to working on it. By keeping it secret, you control the idea.
Why is hiding considered harmful?
If you spend all of your time working alone, you’re increasing the risk of unnecessary failure and cheating your potential for growth. Even though software development is deeply intellectual work that can require deep concentration and alone time, you must play that off against the value (and need!) for collaboration and review.
Early Detection
It’s easy to make fundamental design mistakes early on. You risk reinventing wheels. And you forfeit the benefits of collaboration, too.
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 a nearly misstep are high.** The more feedback you solicit early on, the more you lower this risk**.
Remember the tried-and-true mantra of “Fail early, fail fast, fail often.”
The Bus Factor
Bus factor (noun): the number of people that need to get hit by a bus before your project is completely doomed.
How dispersed is the knowledge and know-how in your project? If you’re the only person who understands how the prototype code works, you might enjoy good job security, but if you get hit by a bus, the project is toast.
If you’re working with a col‐league, however, you’ve doubled the bus factor. And if you have a small team design‐ing and prototyping together, things are even better—the project won’t be maroonedwhen a team member disappears. Remember: team members might not literally behit by buses, but other unpredictable life events still happen.