> No heuristic is perfect, but it's fairly easy to quantify empirically from activity/records. Developers who are productive (actually write and ship large amounts of quality code) tend to be valuable and those that don't, aren't.
If you are factory line worker, yes.
If you are a developer or a manager (a "knowledge worker") -- what you could be observed to be doing has usually little correlation with result for the company.
I know people who are busy producing total crap, managers completing tons of projects achieving bad results, very energetically with huge fanfare. And I know admins that have everything so well automated and working reliably that they are watching youtube whole day, their managers none the wiser about what could have been. Or people who do nothing and have one brilliant idea a year that saves the company tons of expenses. And every other type inbetween.
In a lot of teams it is usual for senior developers to produce relatively little code compared to juniors, when looking at the value they are creating. Maybe because they spent most of their time doing other things like helping juniors, doing code reviews, designing new solutions, talking to clients. Or maybe because they are getting the most complex problems.
If you can measure this you would deserve Nobel Prize. A more likely explanation, though, is that you have no idea how complex the problem is.
In my experience working many decades, in most teams there are few individuals who are making things go and frequently not even their direct managers understand how people are exactly contributing to productivity.
I don't like to respond to my own posts but I forgot to include something which I think is important.
Unfair "heuristics" create unhealthy incentives that are typically way more damaging than having little clarity.
1. People feel treated unfairly and their engagement drops off a cliff at that point in time. People can be happy even accepting a punishment AS LONG as they FEEL they are being treated fairly.
2. People feel pressed to do things for show, just to appease measurements even if they don't believe it is right. Soon they are fine doing substandard or even completely shoddy work even in areas that are not measured, because that's what people do. People do not just selectively resign from doing good work -- if they feel they are asked to do bad work somewhere they will also do it in other areas and find a rationale for it.
3. People who will not accept bullshit and would want to do right regardless of unfair measurements, will evaporate from your company. They usually leave on their own. This will leave your company worse overall -- with no people who will tell managers the truth when it is needed the most.
4. The corporate, thinking they have measurements, stop looking to actually do better. The measurements become everything.
It is frequently better to not pretend you solved the problem and accept the problem is hard and try to do best anyway.
I've been around for long enough to see how all obvious solutions are flawed, but I don't see any good way out. I have a feeling that the coming decade whoever finds a practical solution to this problem will win the next round of tech wars...
One of the big value-adds for a senior engineer is being able to recognize tasks that just don't need to be done, ever, because they just won't contribute much value relative to other things.
Remember, it's not how much you get done. It's how much of the right stuff you get done.
Yeah, exactly. Now explain to somebody they need to come up with a measurements for all the things I have very efficiently declined to do... saving everybody time, effort and helping the really important task get the bandwidth it needed.
I keep hearing this argument about "knowledge workers" yet writers produce books, designers produce design documents, developers ship code.
sometimes you slow down because you're starting something new or you're blocked by other people, but in general productivity measured in code changes frequency / volume and the impact of the feature being worked on is rather straightforward (how many users use the feature, how much revenue it makes).
anyone who argues against this is ether on the poor side of this measurement or work in a cash flush environment where no one cared about this.
Developers do not just ship code. If you think developers only code you are naive and unfamiliar with developers' work.
Developers solve problems and then ship implementations of those solutions.
You can ship completely technically correct implementation to a wrong problem or wrong solution of a problem and it will look perfectly fine for an untrained eye.
My O(n^3) solution that has 1000 lines of code would be 5 times more valuable than 200 lines of code of O(log(n)) solution that I was able to write because I just fucking know what I am doing. The algorithm using lines of code as proxy for productivity will say the junior jackass did 5 times more work than me in the same amount of time.
And then you get the graybeard who changes a tiny bit in the data structure and makes entire problem go away. Find heuristics for that!
Only a person that delves in and spends a moment figures out that that half million lines of code is completely unnecessary because of Y.
The problem with measuring value of a knowledge worker is that you can't enumerate all possible outcomes to be able to tell with certainty that there is a better outcome, because you don't have the knowledge -- they have it. A person with knowledge has better library of possible solutions and better chance of finding it.
The value of knowledge worker in this case is being able to find better solution (because they have the knowledge you do not). The implementation, at least in case of developers, is usually the simple part of the problem.
Imagine you are in an unfamiliar city. You order a taxi and then spend 1h driving from A to B. The taxi is comfortable and the driver is perfect gentleman. You pay your fare and hop off at B.
Only after the fact you will or will not realise that actually, B was just one block from A and the driver essentially screwed you.
In this situation a map or instructions from somebody could tell you this, but with no map or instructions you are at the mercy of the driver who may or may not be doing good job and you will be unable to tell until after some time you got some more knowledge (got familiar with the city and got the Aha! moment).
You just refactored a piece of company software, severely reducing tech debt. Or made an in-house framework that made the others' work easier. Or mentored another engineer. By that formula you should be fired immediately.
Developers ship solutions to problems, which often involves some code. A developer who solves the problem in a fast, cheap, maintainable way with an off-the-shelf package is superior to a developer who solves the same problem in a slow, expensive way with many thousands of lines of unmaintainable code.
> but in general productivity measured in code changes frequency / volume
Oh my. I don't even know what to say to this other than:
> anyone who argues against this is ether on the poor side of this measurement or work in a cash flush environment where no one cared about this
If you can't point to the person on your team who's churning out mountains of crap because they think productivity is measured in lines of code, then...
is a full enough overview of an engineer's output in a crude manner.
if you implement a feature that makes 10$s per user for 100M users in 2 lines of code you're the best developer out there..... if you write 10000 lines of code to ship something that makes 0.005ct for 100 users ... you should not be employed.
As an engineering manager I advice every developer to find a way to learn to measure their output because that is a good way for them to know their value (ask for a raise, move to a different company ...)
If one line of code produces $1M of impact, should it be considered inferior or superior to a developer who produced a 100k line codebase with a couple thousand commits?
But measuring direct impact to the bottom line for a developer is just confusing the roles of the business development team / sales team and the devs. As a manager, do you choose who works on which feature? If so, doesn't that make your subjective choice (on who gets to make the $$$ feature) the only metric that matters?
The level of self importance expressed in all of these responses is quite amazing.
Being a developer/engineer is not a particularly unique or hard to acquire skill, it's highly prized only because it's a new domain and there's an imbalance of supply and demand of workers. In the longer run, wages will certainly regress far closer to the median.
What defines productivity will of course be context dependent, but the majority of companies are building products, and it's quite obvious which developers are contributing vs which aren't.
If you're building a novel system that requires a strong theoretical basis for decision making, then you can argue that low output people are potentially valuable. But 99.9% in industry aren't doing this.
And seems many are lacking situational awareness. I could easily rank all the developers in my org with a very high level of accuracy. If you can't you're a poor manager (or branch/subdivision for larger companies).
Seems the vast quantities of butts in seats, do little paid a lot, kind of workers are particularly triggered here. And boy, there are a lot of them.
Way off course. Replace developer with manager and you still get the same problem.
It is all about knowledge and making decisions. Nothing to do with the fact that software development is a new area.
Architecture (buildings) is a very old trade. And yet you would not dare to measure architect's performance by the number of sheets of drawings they produced.
Some architects are sought even if they produce little drawings.
Most architects produce a large number of fairly similar, mundane designs.
Some architects produce small number of well researched an thought through designs that make them sought after in the market and allow them to charge exorbitant prices for their services. They are name that is attached to the design and the owner of the building will tell their guests this and this architect designed my house.
See, it is not all about the quanitity.
Same goes with fashion design, writing books, and so on.
It is called knowledge work.
It is called this because the person uses their individual knowledge to perform the work rather than some kind of reproducible recipe.
A car mechanic that only looks up procedures in the book is one thing.
A car mechanic that has intimate understanding of the car and experience solving various types of problem is a knowledge worker. He might listen to your car's engine sound and go directly to solving the problem and his performance compared to the other guy will be in no way correlated with the amount of time he spent on the problem or number of times he hit his hammer.
If you are factory line worker, yes.
If you are a developer or a manager (a "knowledge worker") -- what you could be observed to be doing has usually little correlation with result for the company.
I know people who are busy producing total crap, managers completing tons of projects achieving bad results, very energetically with huge fanfare. And I know admins that have everything so well automated and working reliably that they are watching youtube whole day, their managers none the wiser about what could have been. Or people who do nothing and have one brilliant idea a year that saves the company tons of expenses. And every other type inbetween.
In a lot of teams it is usual for senior developers to produce relatively little code compared to juniors, when looking at the value they are creating. Maybe because they spent most of their time doing other things like helping juniors, doing code reviews, designing new solutions, talking to clients. Or maybe because they are getting the most complex problems.
If you can measure this you would deserve Nobel Prize. A more likely explanation, though, is that you have no idea how complex the problem is.
In those cases I like to remind people of this famous little story: https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
In my experience working many decades, in most teams there are few individuals who are making things go and frequently not even their direct managers understand how people are exactly contributing to productivity.