Let’s face it, great developers can take their pick of jobs right now. These same developers know the value of coding in the open and will want to build up a portfolio of projects they can show off to their friends and potential future employers.
Tom Preston-Warner in Open Source (Almost) Everything
I am 24 years old and fancy myself a very self-aware software developer. I am at the stage in my career where I believe the lion’s share of software developers spend the entirety of their careers, somewhere between competence and proficiency. In Japanese martial arts, there exists the concept of Shuhari, which describes the stages of learning to mastery. Michael Norton gave an excellent talk at Windy City Rails this past summer where he extends the concept of Shuhari to professional software developers. Applied in this context, Shu encompasses novices and advanced beginners, Ha encapsulates those who are competent and those who are proficient, and Ri represents the experts and innovators in our field, people like Michael Feathers, for instance. Ascending from proficiency to expert-level is extremely hard, so hard that most people never do it.
Everyone who gets paid to write software got into doing so for slightly different reasons. For me, it is the acceptance that dedicating myself to a body of work where I will never be done learning means that I will never be bored. So at 24 years old, I can look at this information in two ways. I could be content that I am already at or near the ultimate stage of progression for most software developers at a relatively young age. But doing so would violate first and foremost my personal reason for what I have chosen to devote my life to. It would also violate the premise that I want the benefits bestowed upon the great developers that Tom Preston-Warner refers to. For obvious reasons, I want to be able to take my pick of jobs, and I, without qualification, recognize the value of coding in the open and wish to build up a portfolio of open source contributions. But remember I’m not an expert yet, so what are the action steps?
Let’s take a brief sidestep. I love Backbone. I was a relatively early adopter and I can’t be sure, but I’m reasonably positive my proficiency with it got me my current job. I’ve been wishing to contribute for months now, for all of the reasons I previously mentioned as to why a developer would wish to participate in open source. But I have not. Why? Because I suck at reading other people’s source code. When I first gave it a go at understanding the Backbone source, I thought the annotated source code would make it easy for me to grasp. It did not.
The annotated source of Backbone is beautiful, but I far prefer simply reading the standard source. It’s much more familiar when the comments are above the code in vertical space, and there is something about horizontally aligned comments that my brain actually works less efficiently with.
Let me walk you through an attempt to understand the source for Backbone.Events. We’ll do this twice, first by reading the first few lines of source and the comments, and then once again by reading the first QUnit test written for the Events module.
So from this we can learn a few things:
- Backbone.Events is a module that can be mixed in to an object to provide it with custom events
- You can bind with ‘on’ or remove with ‘off’ callbacks
- Calling ‘trigger’ fires all callbacks in succession
This is actually superb documentation, and the code is also written very well. Reading the source in this way is extremely helpful for someone wishing to write application-level client-side “programs” using Backbone, and it was helpful for me when I first attempted to do just that. But as Justin James highlights in his blog post 10 tips to go from a beginner to an intermediate developer, if our goal is to learn by looking at senior developers’ code, this blob of source doesn’t really do that much for us.
So how can we do better? Let’s go another direction and navigate from the root directory of Backbone to /test/events.js. And let’s just look at the first QUnit test defined in this file.
This code is very easy to understand. Moreover, I’ve actually learned something about how the system works. So what do we learn by reading this test?
We also can pick up some extra breadcrumbs in regards to coding-style from Jeremy Ashkenas, someone who I would consider to be at least at the expert realm of the earlier Shuhari discussion.
- We can fill in the blanks (if any) of what we don’t know regarding QUnit syntax and assertions (the equal method as well as the fact that the tests are run in an anonymous jQuery.ready() function).
- We can fill in the blanks (if any) of what we don’t know regarding object.trigger in Backbone.Events.
My plan for the New Year in furthering my level of mastery in software development is to engage in this practice with open source repositories like Backbone. If you have anything to correct and/or add, please feel free to join the conversation on Hacker News, tweet @_kulte or email me at zafriedman at gmail dot com.