On my newer competence

Posted on 2012-04-04 by Graham

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

I wrote:

it looks like my priorities for research goals over the upcoming year or so should be:

  1. Improve breadth and depth of API knowledge
  2. Investigate systems decomposition of a smartphone/desktop/internet system.
  3. Learn how to create and support DSLs
  4. Write and publish improved developer support tools

So how did that go?

  1. 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.
  2. My work on GNUstep web is only part of this goal.
  3. 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.
  4. 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.

Computer Science

  • 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 :)

Software Engineering

  • Source Control: level 3.
  • Build Automation: level 3.
  • Automated Testing: level 3.

Programming

  • 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.
  • Code Organisation Across Files: level 3.
  • Source Tree Organisation: level 3. For these two I’ve decided it’s what you see in the IDE (Xcode, AppCode and Eclipse are my regular haunts) that really matters, though I try to make the filesystem layout match that.
  • Code Readability: level 3. I’m not quite that bastard who rejects code because it doesn’t conform to the standard; though I used to be :-(
  • Defensive Coding: level 2. Still don’t have a “library” for doing that (I’ve written an iOS security library that’s internal to O2, but that’s not what this is about.)
  • Error Handling: level 3 (with s/xception/rror/, because we appreciate that error-handling should be sympathetic to the platform/framework style, just like other code.)
  • IDE: level 3. It was mainly working with AppCode that spurred me into investigating ways to automate IDE functions.
  • API: still going to claim level 1, because I’d say it’s for other people to decide whether they think I have sufficiently “vast and in-depth knowledge”.
  • Frameworks: level 2.
  • Requirements: level 3.
  • Scripting: level 3 (though this improvement only just scraped in this year.)
  • Database: level 1. I’m starting to see more projects where a better knowledge of databases is required, if one of those lands in front of me I’d better improve at knowing databases. However as I said last year it’s the kind of thing where I can use an ORM to get it mostly correct, then investigate whether any issues remain that require deeper inspection.

    • Experience

    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.

    Knowledge

    • 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.
  • Platform Internals: level 2.
  • Books: still level 1, but I’ve written two now. I don’t imagine writing any more, there must be a better way to share knowledge.
  • Blogs: level 3.

    • This year’s goals

    Some of the things I planned for last year still need to be done:

    1. DSLs
    2. 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.

    1. 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.
    2. 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.

    About Graham

    I make it faster and easier for you to create high-quality code.
    This entry was posted in Business, software-engineering. Bookmark the permalink.