[taesis]

My workplace uses a rubric for determining when a developer qualifies for a promotion (+raise), which seems very similar to this. I'm not sure why both spur an immediate sense of revulsion in me, but they certainly do and the feeling is intense. Just wondering, but does the same happen to anyone else? Did you ever figure out its root cause?

[Xcelerate]

> I'm not sure why both spur an immediate sense of revulsion in me

I get the same sense of revulsion, but I know exactly why. Because almost everything in that matrix can be learned within a day or two. Take any experienced programmer and pick out one of those concepts in the matrix that he/she hasn't used before. It would take very little time to grasp the concept. This isn't like teaching yourself homotopy type theory with only a calculus background.

VP trees — have you ever heard of them? Neither had I until I needed to quickly search and partition a set of 3D points with periodic boundary conditions. It took about a day to become an "expert" on these trees and implement my own library. Isn't that a much more valuable skill than pushing yet another kind of data structure and its properties onto an "interview-ready" list of useless facts?

[dasmoth]

I'm not sure I'd quite go as far as revulsion but this sort of breakdown doesn't really appeal to me, and I think the reason is that it's possible to tick most, if not all, of the boxes without actually delivering working, useful, software -- let alone something that's actually pleasant to use.

You can possibly argue that in this scheme, ability to think about the whole system falls under "systems decomposition" -- but that's just one box of many, and still doesn't quite relate to building things.

Ultimately, I guess I'd be happy to ignore any and all of these things if someone can build what I want or need.

[theparanoid]

Because it's BS. The list measures how in love with technology you are. Not results.

Smart and gets things done is a better measure and harder to BS.

[rdiddly]

Probably the sense that your livelihood (survival) is dependent on something arbitrary and potentially inaccurate/unfair.

I think it has value as a framework for someone doing hiring, basically just as a memory-jog for what to talk about in an interview. This would be only after going through and editing it - refining a criterion here, redefining one there, adding a row here, deleting one there, to make it fit the situation. But even then, it shouldn't be taken too rigidly. It's an approximation.

[cdegroot]

I have no clue. I mean, on the one hand I don't like evaluating people by checklists/matrices, but on the other hand - assuming that having to evaluate people for raises and promotions is a given - what's the alternative?

[userbinator]

assuming that having to evaluate people for raises and promotions is a given - what's the alternative?

... by looking at their accomplishments?

Ultimately, productivity is not about how many tools/frameworks/languages/etc. you claim to "know". It's about what you can do with what you know.

[dasmoth]

... by looking at their accomplishments?

Absolutely agree, but with the caveat that the software world currently seems to be on something of a "teamwork is everything" kick which can sometimes obfuscate what individuals are capable of. So judge results -- but be sure everyone is getting a chance to spread their wings at least some of the time.

[cdegroot]

Exactly that. You do agile, you do teamwork is everything, but at the same time you see people perform at more than their pay grade and you want to promote them. Some modicum of objectivity is needed - accomplishments are _mostly_ the team's accomplishments (I guess that is the main reason we all want lunch&learn talks, so you have some individual accomplishments), so looking at skills seems to be a decent next best thing.

[bonzini]

We have a similar thing for performance appraisal, but it does not evaluate technical competencies. Rather, it takes a generic set of skills ("focus on customer", "influence", "strategic thinking",...) and describes how someone in your role ("software engineer", "sales account manager",...) could apply these skills at the team, business unit or company level. The whole thing​ is a 100 page book, but really you only care about the 5 pages for your role (x2 if you are a manager). And it is explicitly not used for promotions. As a tool for identifying opportunities for improvement and personal development, I found it valuable.

[btschaegg]

I get that this will sound overly snarky, but does "strategic thinking" for non-lead programmers involve "actively resisted multiple manager requests to implement a hack because of an arbitrary deadline"?

(Of course it doesn't. But maybe it should...)

[bonzini]

It's not snarky, I agree with you actually. :)

But seriously... In general, "strategic thinking" for junior people is basically understanding your role in the team, the team's long term strategy, the team's collaborations with other parts of the company, and stuff like that.