For the last couple of years, I’ve posted a self-review based on the Programmer Competency Matrix: on my own competency from 2011 and on my newer competence from 2012.
This year, because writing on APPropriate Behaviour is continuing apace, I decided that I wanted to extend the matrix. Just as the book acts as a sort of “coder complete” for people who can program to think about what else goes into being a programmer, this could be the Programmer Courtesy Matrix to promote evaluation and reflection on those other things.
| Subject | 2n (Level 0) | n2 (Level 1) | n (Level 2) | log(n) (Level 3) | Comments |
|---|---|---|---|---|---|
| Tools (version control, continuous integration etc.) | Uses the tools at hand to do the requested tasks. | Understands the given tools and puts them to novel uses. | Can evaluate and compare tools and use alternatives where they would help. | Maintains programmer-support tools or automation wrappers for existing tools. | |
| Pair programming | Solitary worker. | Pair programs when requested. | Engaged pair programmer; pair produces better work than either developer alone. | Enthusiastic pair programmer; seeks opportunities to pair with new people, to learn from and to teach their pair. | |
| TDD | Doesn’t write tests. | Sometimes tests, just as likely after writing the code as before. | Writes code test-first. | Test-infected: discusses all problems in terms of how to write a test to demonstrate them. | |
| Higher-level software testing | Doesn’t test software. | Tests the happy path only. | Code tested comprehensively at multiple levels of integration. | Automates tests at user interface, integration and unit levels, relies on test output to direct future development work. | |
| Software architecture | Not responsible for architecture, or approaches different features on an ad-hoc basis. | Designs separate components to be a “conceptual fit” for the overall project. | Designs the overall project to support the necessary features and non-functional requirements. | Understands the trade-offs involved in supporting conflicting requirements, and can present customers with realistic alternative options when faced with such conflicts. | |
| Documentation | Doesn’t write any documentation. | Writes mechanistic documentation as required by local guidelines. | Comments explain why the code does what it does; code explains what it does. | Uses diagrams, long-form documentation (e.g. project wiki) where appropriate to guide other developers around the codebase. | While too much documentation can indeed be a bad thing, people tend to gloss over the fact that too little is also a bad thing. |
| Learning | Not learning. | Learns about the things needed to solve the current problem. | Able to synthesise ideas from across computer science and related disciplines. | A polymath; able to use ideas from other disciplines and crafts and apply them to programming. | |
| Sharing knowledge | Doesn’t share. | Discusses problems solved on current projects with colleagues. | Can extract solutions as separate chunks of knowledge and share them with peers, or on blog posts. | Presents information at levels appropriate for different audiences: blog readers, conference sessions, books, developer meet ups etc. | I’ve written before on tech conferences and sharing information. It’d be great to move from a small collection of frequent speakers to a large pick-and-mix curated by the conference organisers. |
| Critical Analysis | Accepts vendor recommendations. | Questions vendor recommendations, looks for alternative views. | Balances arguments from multiple sources, considers assumptions behind each argument. | Can use multiple arguments to synthesise a reasoned proposal taking the conflicts and trade-offs in the different approaches into account. | |
| Choice of technology | Uses whatever they’re told to. | Sticks with what they know. | Considers a few options. | Synthesises personal experience and that of others to choose the technology that best solves the requirements of the problem being considered. | |
| Communication | Doesn’t talk to anyone. | Talks to other people about computing things. | Can engage in discussions involving members of the team beyond the programmer group. | Can express ideas at levels and with sensitivities appropriate to various audiences: team members, competitors, customers, school children etc. | |
| Requirements Analysis | Builds what people ask for. | Understands and discusses conflicts between stated requirements and problems in implementing them; discovers and incorporates tacit requirements. | Understands the domain; discusses the software at a peer level with domain experts; can suggest novel applications to solve domain problems. | Understands the whole socio-technical system; can identify political or economic problems arising from suggested changes to the software and propose solutions (in the software domain or otherwise). | |
| Teamwork | Works alone on tasks assigned by other team members (or entirely alone). | Does what is asked by other team members; provides feedback when asked. | Shows some understanding of the team’s goals; picks tasks to complement those goals. | Plays an active role in shaping the team and its direction; understands how to best involve everyone else on the team. | |
| Business sense | Works on the tasks requested by the business. | Has some idea of what the business strategy is and where the tasks assigned fit into it. | Is able to self-assign work in relation to the business goals; discusses/questions other tasks in relation to those goals. | Can provide guidance on business direction based on knowledge of the market and capabilities, or runs the business/business unit. | |
| Professional ethics | Does whatever they’re told. | Does to another as they would be done to (the Golden Rule). | Does to another as they would be done to were they in the other’s position (Barry Boehm’s Modified Golden Rule). | Has a more complicated ethical system, including contributing to society, non-discrimination, respect for others and their property, and discovery and promulgation of better ways to perform their craft. Everything in their work can be related back to that system. | The “level 3” category here is based loosely on the ACM code of ethics but also reads like a summary of the rest of the table. |
This isn’t necessarily a complete reflection on the things in APPropriate Behaviour because that is still a work-in-progress, but it’s a good introduction to the sorts of things the book talks about, and a good evaluation of your own work in relation to the non-programming things I think programmers do.
An interesting pattern to observe is that the left column of the table is basically “does what you tell them to” and the right column is “has a complex world-view encapsulating both technological and social issues”; though the terms used on the right are more specific to the factor being discussed. This pattern is analogous to the Dreyfus model of skill acquisition, in which people go from rote learning of context-free rules (i.e. doing what they’re told to do) to having an intuitive model of how the thing works (i.e. making it part of their world view).
Pingback: Keeping track of your competency as a programmer
Pingback: The judicious selection of what to learn next » Big Nerd Ranch Blog