This time last year, I evaluated myself against the programmer competency matrix. So where am I one turn around the daystar later? I have to admit that this was mainly because I was jet lagged in a hotel room in Seattle and had nothing else to do last year :-), but nonetheless it’s time to reflect on how things have gone.
Last year’s goals
it looks like my priorities for research goals over the upcoming year or so should be:
- Improve breadth and depth of API knowledge
- Investigate systems decomposition of a smartphone/desktop/internet system.
- Learn how to create and support DSLs
- Write and publish improved developer support tools
So how did that go?
- I improved here. I didn’t have a project for doing this, I just used the APIs some more. Things that I previously remembered but needed to look up I now automatically get right, and some things I didn’t know about I now do. There’ll always be room for more.
- My work on GNUstep web is only part of this goal.
- I haven’t done anything with DSLs, as I haven’t found a need for them in the last year. Maybe that’s because I don’t understand where they can be used :). Part of my GNUstep web project will include rules engines a la Direct 2 Web, so I guess I’ll have to tackle this soon.
- Again, in hand with the GSW project. I’ve already published a code generation tool. Some of the things I learned about at NSConference were very inspirational.
What about this year?
I’ll just dive into the matrix. If nothing’s changed from last year you won’t see any comments.
- Data Structures: still level 1. I’ve learned a little more about level 2 aspects.
- Algorithms: level 2.
- Systems programming: level 3, if you’re willing to accept that block-diagram-level knowledge counts as knowledge on the level chart 🙂
- Source Control: level 3.
- Build Automation: level 3.
- Automated Testing: level 3.
- Problem Decomposition: level 3.
- Systems Decomposition: level 3. As I said earlier, I made this a specific goal of the last year, and I believe it’s paid off.
- Communication: level 3. I’ve also done what I set out to do last year, and dialled back on the commitments to conferences and books.
- Code Organisation Within a File: level 3. As I said last year, this is subjective.
I skipped this section last year, but just for kicks I’ll go through it this time. No comparisons with last year, and if you can’t work out why you’re not allowed higher than Level 0 on any entry in the matrix ;-).
- Languages with Professional Experience: level 2. Functional programming I have worked with includes LISP, C++ and Java (yes, that Java).
- Platforms with Professional Experience: heh, this depends as I said in a recent talk on how you define “Unix”. Conservatively I could say Unix, Mac, iOS and Java: level 1.
- Years of Professional Experience: not that I think this matters, but level 2.
- Domain Knowledge: wait, which domain? In the world of telco (where I currently spend my time) I’m a complete noob. In fact I’ve spent most of my career as a complete noob. Whether that’s good or bad, and something I should or would want to change, is open for debate. Maybe that’s another blog post, later.
Yeah, having written that section I now understand why I left it out last time.
- Tool Knowledge: still level 2. I’ve written and published some codeine scripts, not sure it’s enough to qualify at level 3.
- Languages Exposed to: still level 2. I did some concurrent programming in Objective-C, but no Erlang, Oz or Prolog. OK, I have done some Prolog tutorials, and Oz is the operating system on my Cambridge Z88 but I’m going to assume that it’s a different Oz.
- Codebase knowledge: hard to gauge. We have about 100 repos on my team, some I’m not working on, some I collaborate on, some I’m the sole author. We’ll call this one unknowable for now.
- Knowledge of Upcoming Technologies: level 3.
This year’s goals
Some of the things I planned for last year still need to be done:
- Developer tools
To which I’ll add some things that, probably, don’t directly follow from the competency matrix, but which are nonetheless goals of mine.
- More do, less talk. A side-effect of being “the security guy” in my corner of the industry is that I do a lot of talking about security in other peoples’ products, and not much making products. It’s time to find a product I believe in, and own the crap out of it. That means investing my time in it long-term, not diving in and out like a consultant. Consultants are great and consultancy is great: but I want to build something.
- Mentor new developers. A recurring theme from my discussions in Appsterdam and at NSConf is that while I can certainly do a lot to become a better programmer, that won’t scale as well as making a load of other people better programmers. If I can help at least one person become a better developer than I am, I’ll improve my own abilities along the way and then there’ll be two people better than I am.
That will, I think, do for now.