[Dayshine]

"Process improvements" is a bit weird. You measure software engineering performance by their dev ops skills?

It's a completely different skillset, and you're probably only measuring how eager people are to have breadth of knowledge or how familiar they are with your specific system.

Similarly, the explanation for "Debugging and troubleshooting complicated issues" is a bit odd. Why is knowing where the log files are, and knowing how to do complicated test setups for your specific environment a performance measure. Again, that's not really measuring skill but familiarity.

The other two measures are just "Do they complete tasks" and "Do they follow code review guidelines", neither of which are very good measures beyond pass/fail.

The conclusion is: > Once a set of skill areas for a role is landed and agreed upon you will want to make sure your team knows in advance what they are being measured on

So, to do well in your business, I need to pick easy tasks, snipe code reviews, make pointless CI tasks and spend all my time learning the build/test processes not actually developing the product? :)

[sanderjd]

Your comment seems to fall into a common fallacy, that "developing the product" is entirely done by writing the code. That isn't true, there is no product if it is not built, tested, deployed, and debugged. Lots of programmers consider this "pointless" grunge work, but there is a reason it tends to be picked up by the more senior engineers on the team. This sort of work has more foundational impact than just writing feature code; it benefits all features written in the future.

[Dayshine]

No, of course other things are important.

But if you measure only ancillary things, that's a pretty bad measure.

I don't expect every one of my team members to understand the entire build system, testing setup, logging system. That's a waste of their time. They should know some, and perhaps one of the areas in depth.

[sanderjd]

My point is: Those things aren't ancillary. They aren't a waste of time. Good developers can figure out how to use logs to debug issues. They can figure out how to fix the build and deployment system when it's broken. They can figure out how to set up testing environments. If not them, then who? Managers look for people who are self sufficient. All of this stuff is a necessary and important part of the job.

[eropple]

> It's a completely different skillset, and you're probably only measuring how eager people are to have breadth of knowledge

In my experience, this skillet being measured is the critical indicator for high-quality development talent at a healthy shop. You might need one deep-magic wizard for a particular area. You need breadth everywhere. You need to kill "that's not my job" stone dead when you see it.

Writing code is easy. And it's usually an additive process, even when the code is subtractive. All the other stuff, the being-a-person-in-a-community stuff (because that's really what it is), is multiplicative. So I pretty unashamedly hire for curiosity and for breadth. When it's necessary, I contract out hard expertise until curious people can develop it internally.

[jimbokun]

> You measure software engineering performance by their dev ops skills?

Absolutely! That is the "dev" in dev ops.

I think there are few things that increases the productivity of a dev team more than improved processes.

> Why is knowing where the log files are, and knowing how to do complicated test setups for your specific environment a performance measure.

Because if you don't know those things you are much less helpful to your product team.

[AstralStorm]

You'd find a cushy job in a few corporates by doing just that.

Someone else then gets to do hard tasks and gets bad reviews because they're slower at this and the numbers do not tick up.