Elf Sternberg: Programmer Competency Matrix

So I've been looking at Sijin Joseph's "Programmer competency matrix," and I'm going to go through it because I kinda want to know where I stand. But I have to tell Sijin once thing: information architecture is something he needs to improve on. By using the first person in his "about me" page, he somehow managed to avoid telling people his name throughout most of the blog! As a recovering web designer, I'm shocked whenever I see someone's blog or website work really really hard to avoid putting its identity in the header.

So let me go through the matrix.

Computer Science

Data Structures: Level 2, almost 3

I'm a little weak on some data structures, especially those that are hybrids, such as an efficient Least-Recently-Used hashtabe, as well as those that lead to persistent storage.

Algorithms: Level 2, almost 3

More or less the same thing.

Systems Programming: Level 2, almost 3

Again, I feel like I'm weak with some of the features of systems production, such as dynamic linking, JIT compilation, and garbage collection. I know what those things are, and I've implemented primitive versions of them, but things like generational garbage collection and peephole optimization aren't yet in my vocabulary.

Software Engineering

Version Control: Level 3

I use Git for everything. I started with CVS, then SVN, now Git. I use Git for tracking my documentation. Hell, I use Git Flow to track my fiction writing!

Build Automation: Level 3

I've written build automation systems. I understand how build systems can be partial or complete; can be topological, reordering, or recursive; can have static or dynamic depedencies; can perform a cutoff if a dependency is identical to the previous iteration and therefore its dependents don't need rebuilding.

Automated Testing: Level 2

I love getting into TDD when a problem becomes complex enough that functional products need to be defined, described, and generated. I don't have much strength with UI or performance tests.

Problem Decomposition: Level 3

Also: knows damn well when not to implement the super-clever hyper-abstract generic solution when the next guy who has to look at and maintain my code isn't a level 3!

Systems Decomposition: Level 3

But... I have a tendency to work only at level 2. I don't enjoy doing heavy integration at the process or container level; it's abstract and distant, and feels a bit like abdication to entropy.

Communication: Level 2

It depends on the kind of communication. I have no trouble describing what I want to buid, or am going to build; I have more than once saved a project by being the only one on the team who knows how to drive a UML rendering tool. But sprint planning, negotiating for who builds what when, that's always rough.

Code organization: Level 3

I work really hard to make my code readable and beautiful. I know the next person to read it will hopefully appreciate it. I use a thesaurus constantly to make sure I've used exactly the right name for a variable or other symbol.

Source tree organization: Level 3

I tend to work simply, with the best practices of my industry in mind. Kinda a reason I don't like Go: there are two "best practices," and they're completely at odds with each other.

Code readability: Level 3

Cyclomatic complexity checks for the win! This one is actually a bit hard to hit in my favorite language, Lisp, because it encourages that kind of complexity with anonymous functions and efficient local dispatch, but I manage.

Defensive coding: Level 2

I'm okay at it, and I know what to look for. I use linters and other semantic checkers a lot. But I'm definitely falling back on common tools, rather than custom tools, for my efforts.

Error handling: Level 2

I'd love to be level 3, but level 3 is only possible in languages the industry doesn't use.

IDE: Level 3

I work in Emacs. What do you think?

API: Level 2

I'm not sure what he means here by "API." Does he mean the ones we use in common practice, like HTTP and REST and GRPC? Sure, I know those. But what about the ones built on top, like OpenAPI? Those are as varied as the use cases. Does he mean LibC? I don't work much in LibC these days.

Frameworks: Level 2

I consider that a badge of honor. There are too many frameworks out there. The only reason to write a framework these days is to fill in a gap in a language that doesn't already have one. Frameworks are like Patterns: holes in the language.

Requirements: Level 3

This actually goes back to "communication." Because I know Rational Rose, I know how to extract requirements and scope them out better than most people.

Scripting: Level 3

Just go look at my Github!

Database: Level 2, almost 3

My SQL is pretty good; I've even published solid and testable extensions to Postgres. I do know some optimizations and can talk about storage engines, but the industry is getting pretty fuzzy these days.

Experience

Languages with professional expertise: Level 2, almost 3

And yes, I hit the bonus round. I can talk about monads.

Platforms with professional experience: Level 2

I've been pretty monogamous about my platforms. That gives me a lot of depth when talking about Unix-based services on AWS, but yeah, I can't talk too much about Azure or GKE at the moment.

Years of professional experience: Level 3

Yep. More than ten years of experiences.

Knowledge:

Tools: Level 3

Yep, written tools other people use. Knows better than to use an ORM.

Languages: Level 3

Try me.

Codebase: Level 2

Here's the thing about Sijin's "level 3:" I don't believe this is a valuable skill. If your codebase has this kind of headaround problem, you have a codebase with poor decomposition.

Upcoming technologies: Level 3

I tend to be a neophile and love playing with new things. Unfortunately, I often love playing with new obscure things like Typed Assembly language and Python Lisp, which means that my neophilia often has me working in spaces where there's not much legacy life. Ah, well.

Elf M. Sternberg

Full Stack Web Developer

Where one teaches, two learn.

Blog

PROGRAMMER COMPETENCY MATRIX