Programmer Competency Matrix

Last week, I found a interesting page, describing the:

Program Competency Matrix

The author, Sijin Joseph, explains the origin in his post:

Having worked with programmers with an extreme variance in skills, I sometimes get the feeling that there is an big lack of good programmers but when I thought about it a little more I realized that it’s not very clear cut, some of the programmers have strong areas and if you confine the tasks into their strong areas then they tend to deliver well. So I started thinking about all the lines on which we can evaluate a programmer, here’s what I have so far…

As you can see in the page, the matrix has four levels in columns, and rows grouped in categories:

• Computer Science
• Software Engineering
• Programming
• Experience
• Knowledge

I like all the matrix, let me show here some of my preferred rows, corresponding levels, and my auto evaluation:

Knowledge – Blogs

1. Has heard of them but never got the time.
2. Reads tech/programming/software engineering blogs and listens to podcasts regularly.
3. Maintains a link blog with some collection of useful articles and tools that he/she has collected
4. Maintains a blog in which personal insights and thoughts on programming are shared

I’m near 4.

Knowledge – Books

1. Unleashed series, 21 days series, 24 hour series, dummies series…
2. Code Complete, Don’t Make me Think, Mastering Regular Expressions
3. Design Patterns, Peopleware, Programming Pearls, Algorithm Design Manual, Pragmatic Programmer, Mythical Man month
4. Structure and Interpretation of Computer Programs, Concepts Techniques, Models of Computer Programming, Art of Computer Programming, Database systems , by C. J Date, Thinking Forth, Little Schemer

I miss some books, but I’m near 4.

Knowledge – Tools

1. Limited to primary IDE (VS.Net, Eclipse etc.)
2. Knows about some alternatives to popular and standard tools.
3. Good knowledge of editors, debuggers, IDEs, open source alternatives etc. etc. For e.g. someone who knows most of the tools from Scott Hanselman’s power tools list. Has used ORM tools.
4. Has actually written tools and scripts, added bonus if they’ve been published.

Well, I’m between 2 and 3, but I’ve written and published tools, so I feel near 4 too.

Knowledge – Platform internals

1. Zero knowledge of platform internals
2. Has basic knowledge of how the platform works internally
3. Deep knowledge of platform internals and can visualize how the platform takes the program and converts it into executable code.
4. Has written tools to enhance or provide information on platform internals. For e.g. disassemblers, decompilers, debuggers etc.

I’m in 3.

Experience – Years of professional experience

1. 1 year
2. 2-5 years
3. 6-9 years
4. 10+ years

Absolutely 4, but I deserve a new level… near thirty years … 😉

Programming – source tree organization

1. Everything in one folder
2. Basic separation of code into logical folders.
3. No circular dependencies, binaries, libs, docs, builds, third-party code all organized into appropriate folders
4. Physical layout of source tree matches logical hierarchy and organization. The directory names and organization provide insights into the design of the system.

I guess I’m between 3 and 4.

Programming – Code organization withing a file

1. no evidence of organization within a file
2. Methods are grouped logically or by accessibility
3. Code is grouped into regions and well commented with references to other source files
4. File has license header, summary, well commented, consistent white space usage. The file should look beautiful.

Hmmm…. I put myself in 2.

Programming – Communication

1. Cannot express thoughts/ideas to peers. Poor spelling and grammar.
2. Peers can understand what is being said. Good spelling and grammar.
3. Is able to effectively communicate with peers
4. Able to understand and communicate thoughts/design/ideas/specs in a unambiguous manner and adjusts communication as per the context

I like this row! I’m near 4 (in Spanish), I’m spread in 1-2 in spoken English, and between 2-3 in written English. The author comments:

This is an often under rated but very critical criteria for judging a programmer. With the increase in outsourcing of programming tasks to places where English is not the native tongue this issue has become more prominent. I know of several projects that failed because the programmers could not understand what the intent of the communication was.

Computer Science – System programming

1. Doesn’t know what a compiler, linker or interpreter is
2. Basic understanding of compilers, linker and interpreters. Understands what assembly code is and how things work at the hardware level. Some knowledge of virtual memory and paging.
3. Understands kernel mode vs. user mode, multi-threading, synchronization primitives and how they’re implemented, able to read assembly code. Understands how networks work, understanding of network protocols and socket level programming.
4. Understands the entire programming stack, hardware (CPU + Memory + Cache + Interrupts + microcode), binary code, assembly, static and dynamic linking, compilation, interpretation, JIT compilation, garbage collection, heap, stack, memory addressing…..

I’m in 3, absolutely.

Software Engineering – Automated testing

1. Thinks that all testing is the job of the tester
2. Has written automated unit tests and comes up with good unit test cases for the code that is being written
3. Has written code in TDD manner
4. Understands and is able to setup automated functional, load/performance and UI tests

I’m in 3, having worked a bit on 4.

Well, there are many more rows. But it’s not only important to compare now. If you are interested in continuous improvement, you must assest your current level in each row, plan the steps to increase each level (even the 4’s ones), and revisit your assestment regurarly. Call for help from your coworkers. Hint: improve the lowest level first.

Angel “Java” Lopez
http://www.ajlopez.com/en