gChats: Myth of the Genius Programmer

I attended a gChats session hosted by Google at 1871 and they presented a lot of interesting points that can be applied to anyone working on IT projects, and also developers! The talk was the final one of the event but arguably it was the most informative. It was given by both Ben Collins-Sussman, the co-designer and co-founder of SVN, and Brian “Fitz” Fitzpatrick, a senior software engineer who has worked on various version control systems (Collabnet, SVN, cvs2svn, CVS). They discussed about the topic of being “the genius” programmer, but it can be applied to being an elitist in any area.

One may think that being the “genius” is always a good thing, but in fact it inhibits progress. Rarely today is software developed by one person, so it is tough when one person holds information to oneself. This introduces the amazing concept of “the bus factor.” The speakers say the bus factor is how many team members need to get hit by a bus for something to be doomed. 🙂 One team member means if one team member (leaves the company, gets married and moves away, or any other external factors) then something they contributed will be lost. This is similar to the idea of “tribal knowledge” once told to me by Vinay Kudithipudi. It is important to not hold internal secrets to oneself or ones team because when “shit hits the fan” only one person is going to be able to fix the issue. Think about it, do you really want to get called every time there is a minor issue with something you are working on? While yes it’s good to be informed, small fixes can be better handed off to someone not on a critical task on a project. Plus incorporating support from other team members only means your end product will be more widely used and supported. It gives a sense of ownership to everyone, which means they will care just a little bit more about it! 🙂

So the speakers mentioned how to get out of this “genius mode” with 7 simple steps.

  1. Lose the Ego
  2. Criticism is not evil
  3. Iterate Quickly
  4. Practice is Key
  5. Be a Small Fish
  6. Be influenced
  7. Be vulnerable

1) No one wants to work with the elitist. As Fitz said during his talk, ‘Don’t be that guy.’ While yes it is nice to take pride in ones work, don’t let it fill your head with hot air. Realize that:

“You are not a beautiful and unique snowflake. You are the same decaying organic matter as everyone else, and we are all a part of the same compost pile.” -Fight Club

The sooner you give up this mentality, the sooner you will reap the benefits of working in a team environment.

2) Listen to criticism! Don’t get all worked up when someone criticizes your work. Use this as a learning experience to improve what you know. Without criticism you will never get better!

3) Iterate quickly means to fail early, fail fast, and fail often. Also document your failures internally with your team members. This will prevent a bunch of team members from going down the same road you went down. Just because you failed trying to implement something, doesn’t mean the rest of the team need to learn the hard way. Here’s what I tried, it didn’t work, don’t repeat what I did.

4) Practice makes perfect. If you fail, try and try again! The only way to learn is through mistakes and trying it for yourself.

5) Be a small fish is quite a good topic! When you are ALWAYS the “genius” in the room, do you really want to work in that environment? Are you really challenging yourself? Find new ways to challenge yourself by picking up something new and foreign to you. This will only help you better understand your product fully. While yes, it is good to be the “genius” sometimes, being the “genius” all the time will cause people to become complacent and lose motivation. 🙂

6) Be influenced means to be willing to change. If you are hard headed, you will never learn from criticism or comments made. You need to listen from the perspective of the other team members because sometimes they have valuable input! Everyone has a unique perspective that should be considered. 🙂

7) Be vulnerable. This was mentioned earlier when the speakers discussed about “private” repositories for open source projects. People always request the ability to hide their code mistakes (or mistakes in general) for the fear of looking stupid. The reality is we are all stupid, just less stupid in different areas. As Fitz mentioned, “Do people know what open source means? Maybe its the word open that throws people off.” Linux wasn’t developed completely by Linus Torvalds, he wrote a small piece of the kernel then people got interested and helped out. After a while more people helped out, and finally today look at where Linux stands!

“There’s a pervasive elitism at work in the programming community. Add anonymity to the mix, and everyone is suddenly elite.”

Both Fitz and Ben suggest to limit a team size to about 5 team members when you are making critical decisions on a project. Add too many hands in the cookie jar and no one will be able to get work done because you are all talking (more like arguing sometimes :P) about paths a project can take. “If you place a group of people in the Loop and tell them to sight see for five hours, they will only move 2-3 blocks in the city because they all want to see different things.” However, they also mentioned it is critical to include team members gradually and early into a project. Don’t load a bunch of resources into a project in the initial phase. This only wastes peoples time as you are busy creating something to work with, but don’t incorporate too late or else it will lack collaboration! Their steps, and level of engagement where as follows:

  1. Initial Idea – Come up with an idea to work with (1-2 people)
  2. Prototype – Come up with something that is inline with what you want, doesn’t have to be perfect. Consider this ground zero (1-2 people)
  3. Involve Collaboration – Get people working on it, introduce the team aspect. (1-5 People)
  4. Code, Code, Code – Do the work! (variable size)
  5. Take Over the World – Get your project out there and do what you do best Pinky…TRY AND TAKE OVER THE WORLD! (Optional Pinky and the Brain Quote 🙂 )

There were a lot of core things involved with a project but most of the time issues can be traced back to the lack of one of the “three pillars.” It could be a lack of respect, a lack of trust, or a lack of humility. As you can see, it impacts not only yourself, but also your team, your collaborators, your organization, and finally it hurts your users. The image says it all:
The Three Pillars of teamwork

Finally, they concluded with a talk about Agile and other various methodologies. They suggested that it should really be up to individual teams on what they want to implement. Their methodology is “We don’t care what you use. We follow get your shit done and deploy.” Agile is great, others are better too, but your end users aren’t going to care what methodology you use, if you never deliver. Pay attention to time constraints and get your work done is the main message (not looking to start the next holy war on project methodologies as I know this is a sensitive topic :P)

I hope this post was helpful and inspirational to some of you as it was to me! Please thank Ben Collins-Sussman and Brian Fitzpatrick for their excellent delivery as most of this post was presented in their talk! So the takeaways from this are: Don’t try to be a genius, Collaborate as early as you can, and Pay attention to timing. Doing these simple things will make you seem like a genius :).

Also you can all view my album of the talk here! Feel free to follow me on Google+ and share me some cool stuff! We will only learn together through collaboration!
gChats: Myth of the Genius Programmer Slideshow by Ben and Fitz

2 thoughts on “gChats: Myth of the Genius Programmer”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.