Metrics are at best guidelines to help ground subjective observations. They all have huge gaping holes and if you want to plug those you’ll spend more time measuring than working. The best guide of if you are doing ok is how good other people think you are doing. Does the PO think you deliver fast enough given the complexity, do you help out other devs when possible, do other devs respect the quality of your work?
The best Software Designers have much lower rates of “surprises” in Production (i.e. stuff is put in production and only then people figure out something is missing, is not quite doing what’s necessary or worse).
Doing analysis upfront does help with doing the right code from the start (or close to it) rather than often going down directions that turn out not to work well and having to go back, AND it also helps with doing the right software design from the start (say, figuring out that you need a certain kind fast access persistent data stored hence need to structure the design taking it into account that you’ll have database access), AND it also helps with implementing the right Requirements with the right features (say, have the full details to integrate with other systems or how figuring out that “static” data elements are actually something that does change at sometimes, at an “admin” level rather than during normal use at a “user” level, so the whole thing needs some kind of admin layer).
This kind of stuff gets reflected in a more broader “customer” (internal or external) satisfaction of the “this software/software-changes usually do what we need straight out of the box and we don’t need to go back and forth to get it right” kind, which is even harder to measure and takes time.
I’m a senior dev. This is exactly it.
Metrics are at best guidelines to help ground subjective observations. They all have huge gaping holes and if you want to plug those you’ll spend more time measuring than working. The best guide of if you are doing ok is how good other people think you are doing. Does the PO think you deliver fast enough given the complexity, do you help out other devs when possible, do other devs respect the quality of your work?
Even then, the measuring should be multilayered.
The best Software Designers have much lower rates of “surprises” in Production (i.e. stuff is put in production and only then people figure out something is missing, is not quite doing what’s necessary or worse).
Doing analysis upfront does help with doing the right code from the start (or close to it) rather than often going down directions that turn out not to work well and having to go back, AND it also helps with doing the right software design from the start (say, figuring out that you need a certain kind fast access persistent data stored hence need to structure the design taking it into account that you’ll have database access), AND it also helps with implementing the right Requirements with the right features (say, have the full details to integrate with other systems or how figuring out that “static” data elements are actually something that does change at sometimes, at an “admin” level rather than during normal use at a “user” level, so the whole thing needs some kind of admin layer).
This kind of stuff gets reflected in a more broader “customer” (internal or external) satisfaction of the “this software/software-changes usually do what we need straight out of the box and we don’t need to go back and forth to get it right” kind, which is even harder to measure and takes time.