OSCON: Programmer Insecurity and the Genius Myth

Two of my favorite presenters, Ben Collins-Sussman and Brian Fitzpatrick, did an OSCON session on “Programmer Insecurity and the Genius Myth.” Brian and Ben talked about how programmers’ insecurities cause all manner of troubles in programming projects, and then presented a number of tips for how to avoid these problems. They also asserted that there are very few genius “lone ranger”programmers in the real world — most highly successful and productive programmers work smart and collaborate well.

Programmer insecurities can hamper the progress of projects. Ben and Brian’s first tip for avoiding these insecurities is to “lose the ego,” which of course is easier said than done. They gave the example of the Apache Software Foundation, which practices a focus on the community and not on the code itself. This gives the project a strong community ego, which then limits individual egos from getting in the way.

“Criticism is not evil” was their next point. For instance, one person at Apple started a code review process, but after a week his manager took him to task since others complained that people were being too negative in code reviews. The team at Apple did not respond to the process well, since they were not used to critical review. Ben pointed out that open source hackers tend to receive more criticism than programmers in the closed source world, since everyone can inspect your code when its freely available. This gives open source programmers a thicker skin with which to deal with criticism and move on.

Embracing failure — unlike the adage that “Failure is not an option,” in engineering failure is commonplace. Doing something, even if you fail, is worthwhile since it provides opportunities for learning. If you allow yourself to fail, your code will improve over time — look at failure as an opportunity! Google believes that its good to “Fail fast.” If you embrace failure, then failing fast means that you can learn from your mistakes quicker and move on to write better code that won’t fail.

It’s important to not cover your tracks when you fail, suggest Ben and Brian. Your tracks provide you with the evidence of how you failed and how to learn from your failure. Brian said: “I hate it when Git users erase their commit histories to cover their tracks!” This goes back to the original point of ego — the perfect code didn’t simply pop into your head. All the little failures along the way provide key information about how your project evolved and they make you simply human.

Practice your skills. Brian practiced writing code on paper before his Google interview since he knew he would be asked to write code on a whiteboard or on paper. Having practiced this awkward task, he felt more comfortable during his interview (which he clearly passed, since he works for Google).

“Be a small fish.” If you never put yourself in a position where you’re scared, how can you grow as a developer? And “Be influenced.” If you want to be a leader, you need to be open to influence. Even the most effective leaders never have all the answers, so a good leader needs to take input from the other people on the team. If people on the team take turns being the leader, you can strengthen the team as a whole as well as strengthening each member. The last “Be” point was to “Be vulnerable.” It’s important to share your failures and admit when you’re wrong. People will respect people more who can openly admit their vulnerabilities.

Tools and how they affect collaboration and social behavior were Ben and Brian’s next topic. They reminded us that “You cannot apply a tech solution to a sociological problem.” For instance, access controls on version control systems are usually not needed. Project leaders should grant complete control, and if problems arise, someone should simply talk to the problem committer. Normally version control problems come from a lack of understanding the established methodology — people rarely commit code that they know violates the established methodology. The best fix is simple human-to-human communication, not locking people out of portions of the version control system.

Towards the end of the presentation, Brian and Ben asked about the right time to collaborate. Its clear that collaborating when you’re done with the project is too late, but when is the right time to start? If you start too soon, you’ll get too many people who will give input into a project that hasn’t fully formed yet — this can lead to chaos. Or, as SourceForge shows, if you start too soon, you may never get anything done, since there are thousands of dead projects on SourceForge that never committed a single line of code.

The sweet spot comes after the project has a concrete goal and scope committed to a web page, which makes it more “real” for new visitors. It also helps to have a coherent design document that outlines the basic architecture and layout of your project. But, what helps most is a proof of concept of the project — something that works but shows your direction and intentions. With a proof of concept, it’s possible for others to jump into your project and start contributing.

To conclude their talk, Ben and Brian summarized their points: Don’t try to be a genius! Collaborate early and often and pay attention to the tools you choose for your project. Also, pay close attention to the timing of your project and let yourself be influenced. If you do all these things, people may just think that you’re a genius!

Genius or not, I really like what Ben and Brian have to say. Thanks for another killer presentation!

tags: ,