The Programmer Competency Matrix
One day, I decided I wanted to find a metric to understand and track my skill level as a software developer.
This is a difficult thing to measure, since there’s any number of variables one can pick and choose to include in the metric, and how do we assign weight to each one? Some variables elude measurement altogether. How do you identify your 10x programmers? It’s not clear how to track the impact one person’s work has on others in the team. This involves cataloging the interpersonal relationships and defining the data to collect on these interactions. An accurate, meaningful, useful metric is impossible to create, and there may even be philosophical barriers to its production.
However, lucky for me and others, I only want a practical and imperfect metric. I found that in the Programmer Competency Matrix.
The simplicity of it is just great. If somebody sees I claim a log(n) level in version control, they’ll understand I’ve worked with git and mercurial professionally, that my experience is not limited to cvs and subversion. Coverage is excellent, but also succinct. There are 32 categories, which not only cover technical skills, but soft skills like communication, reading, and blogging. One might argue IDE knowledge is overrated, but I see that category as being about source editors in general. I’m a vim guy, and I’ve worked with Visual Studio (or against it at times.) Knowing how to use the primary medium for your art is a key skill, like expecting a chef to know how to chop with a knife. Finally, I really like that the top level is open-ended. This means a developer always has room to grow. However, it also notes that when somebody reaches the log(n) level, there really isn’t any place to go. (I’m starting to sound like Nigel Tufnel.) Sure, I can always keep learning more languages, but after some pragmatic experience in a few that cover different development paradigms, adding more doesn’t put me above and beyond any others. I think I could hold my own with a developer that knew 15 languages versus my 10*, if we had to start from scratch on a new language tomorrow. Once you get close to or past those 10,000 hours, you can only get worse if you decide to slack off.
The point of all this is I want to especially challenge myself this year, and raise my average score. Maybe it’s stupid to put my weaknesses out there for everyone to see, but I also think it’ll only motivate me to do something about them.
Systems Programming (current level n^2): This is my weakest area. I’m not a hardware guy, and have had little interest about the computer’s internals. Still, it’s embarrassing to not give more than a cursory explanation of TCP/IP or multi-threading to somebody. My plan to improve this is to really dive into the books I have on the subjects, and get some first-hand experience with these things in a language like C.
Build Automation (n): Some limited success in this category was with MSBuild for C# .NET projects. I also currently work with maven, but a large part of it remains mysterious to me. However, I am improving. A current project I am working on is written in python. I would like to put the code up on github, but I want to understand and write a good setup.py file to go with it first.
Automated Testing (n): For whatever reason, I have been in development environments where unit testing is just not done. Occasionally in the past, my teams have flirted with some unit tests for a while, but the code always changes quickly and the unit tests rot. At one point, I had even written a set of classes to bootstrap CSUnit tests using custom attributes. I’d like to make a better, conscious effort in this area, but this is likely the area I’ll fail in this year. One of these obstacles is the lack of a build server in my current (professional) environment, for reasons too complex to discuss here. In my personal projects, I’m not too familiar with node.js and python’s unit testing frameworks, so I can definitely start there.
Defensive Coding (n): This is tied back to the automated testing dilemma. I’ve not had the pleasure to work in a team that had the discipline to unit test, so I’ve never really had the opportunity to stress-test an application with simulated faults. That actually sounds like fun, versus the droll unit tests I’ve had to write in the past.
IDE (n): I’ve already said I expand this section to include source editors in general. One of my biggest vim weaknesses is macros, which definitely separates the wheat from the chaff. Maybe I could write macros to help automate the droll unit test classes (hrm?!)
API (n): It’s not entirely clear how I could raise my level in this area. Most of the APIs I work with are fairly robust and complete. However, this year I’m getting more into web development, so maybe I’ll encounter something that I’ll need to improve upon to get my tasks done.
Frameworks (n): In this category, I actually have no interest at the moment in advancing to the log(n) level, because I do not want to write a framework. It’s not that there’s nothing new under the sun, but that I simply don’t have a problem to solve where my own homegrown framework would help. I’ve dealt with people who went down this rabbit hole and nearly took down entire companies with wasted time, energy, and effort in the name of a framework to rule them all. The answer to “Should I write a framework for this?” is almost certainly “No. Absolutely not.”
Scripting (n): Turns out, this current personal project for Freeside will be a great way to learn more advanced scripting techniques through python.
Databases (n): In this category, I still need more effort to understand advanced database topics, like indexing, optimization, and administration. I know enough to get by and not make a DBA’s work a living nightmare, but knowing how to debug more low-level problems encountered databases can only be a plus.
Languages with Professional Experience (n): There has never been the use of concurrent or logic language paradigms in any professional capacity in my career. However, I read a little about Erlang and would like to take a stab at it. I have an idea for a program that should be simple to write in Erlang, so the next time I’m free I’ll set towards that aim.
Years of Professional Experience (n): There’s nothing to do here but put in another 2 years to get a full 10 years of professional experience. I already crossed that mark in overall experience, but I want to keep things honest, since there is a huge difference between professional and personal work.
Tool Knowledge (n): I don’t really have good ideas for a new tool that I could implement and publish that people might find useful. I think of a program like Charles, which is extremely useful to many people. Yet to develop something like it is extremely ambitious. Maybe in my foray into node.js, express, and jade I might come up with something others might like.
Platform Internals (n): When I see this category, I immediately think of Mark Russinovich. That guy is a programming beast. He might actually be a level 1 (constant time) in this category. It is unclear if I can even approach that level in the next 10 years. It’s not to say I won’t try, but this type of work is very demanding, requires very deep knowledge, and mastery over the machine. It’s possibly the final boss of the Programmer Compentency Matrix.
So there it is: my response to the question, “What do you feel are your short-comings as a software developer?” I’d add I lack some experience in both web and mobile development, but that’s all just on the pile to improve upon in 2012.
* I’ve honestly lost track of the count. My online resume I think has the most complete list.