Some time ago I read the developer skill matrix and thought it was very interesting. I put it in the infamous “Read later” bookmark folder, and actually came back to it! So last Monday, during our regular group catchup time, I presented this page. In fact every week one of us three engineers presents something to the others. It can be a new tool, an interesting webpage, or anything else we think might be of interest to the others.
So together with the team I went through the list and we discussed where each of us stands. The goal was not to adjust the salary, but rather to discuss how each of us can grow. The list has several entries, and for each entry there is a scale. It goes from Beginner through Intermediate all the way to Expert, in 5 levels. We didn’t get anybody auto-evaluating below Intermediate. Perhaps we didn’t hire junior enough people?
The Matrix
The list starts with General and Communication Skills, and this was already interesting. Even if I forget this part from time to time, I am well aware of the importance of these skills. For others it’s less obvious – perhaps when you’re a PhD you can get away for some time to neglect these skills. But even then you need to honour these skills when you want to publish your paper or work together with other people. Also when working in a bigger group on a common project. Then you need to convince the Scrum Master, the Product Owner, or whoever decides what you should work on or not. So communication skills are important.
The Core Software Skills are more down-to-earth for your regular software engineer. We discussed a bit the Strong understanding of popular and valuable design patterns. Personally I’m not a big fan of design patterns. Most of the time I see them applied it’s more of the rube-goldberg / code golf structures type, which should be avoided. But I’ve been convinced then that design patterns are in fact a good communication pattern for other developers.
For the General part of the core software skills, it presents an architectural view of the code development process. Something we unfortunately don’t have enough experience here, mostly because most of our projects are small 🙁
Finally the Infrastructure part is mostly about DevOps, something we’re actively promoting here at C4DT. It’s one of the first things we do for new onboarded projects: adding automated tests and deployment scripts, mostly using github workflows.
Conclusion
All in all it was a fun experience going through this matrix and discover what others like and don’t like. Perhaps I should’ve used it also in my class about computer programming to do a first self-assessment? But probably most of them would’ve just clicked “Beginner” for all categories…
— Linus