[johnfn]

> To take your envy(I sense it on the quoted remark) to another place, think about how you go about measuring productivity of a CEO, PO, PM, Scrum Master, Agilist/Agile-Specialist etc?

I have no envy; I'm a software engineer as well. I just don't seem to struggle, as others claim to, in measuring productivity. I find it fairly straightforward to see that some people are more productive than others, at least in my workplace where we can hold most things constant (e.g. meeting count, managerial ability, etc, etc). Yes, there may be external factors, and that's unfortunate. Yes, it's not fair that some people are more productive than others despite putting in half the effort. But I'm not going to stick my head in the sand and pretend it's invisible.

[WgaqPdNr7PGLGVW]

> I just don't seem to struggle, as others claim to, in measuring productivity.

Because you are measuring at a very broad and basic level.

Steve is more productive than Susan.

Great. How much more productive? Can you turn it into a number?

Can you still do it consistently when Steve and Susan are in different teams in different parts of the organisation trying to achieve different goals?

I've done DB upgrades that took 10 minutes and I've done DB upgrades that took 3-4 months. What changed was not my productivity but the nature of the problem. Yet from the outside they were both just DB upgrades.

If Susan had done the DB upgrade in 12 weeks could we confidently claim that Steve could have done it in 11 weeks? Steve hasn't even done a DB upgrade since he joined the company. Perhaps Steve could have done it in 10 minutes?

[theamk]

I don't think anyone can get numbers, but partial ordering is much easier.

If Steve and Susan are in different part of organization, the answer is "cannot compare". If they are doing different job, the answer is the same.

But every once in a while there is a scenarios when you can compare people easily.

There has a weekly rotation to be an support person for other team. During his week, John always answers questions quickly and to the team's satisfaction. Meanwhile James struggles to answer them and cannot troubleshoot product his team is writing. This has been going on for multiple months and hundreds of questions for each, so it's not "bad week" unlucky or fluke. We now know who is better at answering questions about product.

John and James are doing DB migrations, they did many dozens of them. The migrations are assigned randomly. But John is usually finishing his migrations with no problems, while James often caused outages or missing data. A few times James took over two months to migrate, so the task was taken from him and given to John. John had to discard everything James did and migrate everything from scratch. Now there is a migration for a very important client and CEO is fed up with random assignment.. who is he going to choose?

[gregors]

What your scenario doesn't address is that while John finished his migrations on time, James has designed the flagship order processing pipeline something that John could never pull off.

Or maybe while John is technically adept, he's also a huge jerk and belittles people at standup, while James is the quintessential communicator with jr devs, etc.

Real life is messy. I've seen more people get replaced due to attitude or teamfit issues than specifically due to technical incompetence.

[theamk]

Your first scenario: possible, but quite unlikely. If James cannot even perform migrations without causing outages or dropping data, the chances are that "flagship order processing pipeline" he made is similarly bad, and even if it works, it's likely has outages and missing data. I've never seen a developer who can only do hard tasks but is genuinely bad at simple tasks (They may refuse to do those, but if they start on them they'll do them well.)

Your second scenario is unfortunately very likely, people are jerks, and if they are also high performers (or high bullshitters) then can get away with it.

Either way I fully agree one one should be firing/promoting people based on a single metric, even if that metric is very relevant to the job description. That doesn't mean that "there is no such thing", or that if you really need to get that DB migration done, you want to choose a "quintessential communicator with jr devs".

[WgaqPdNr7PGLGVW]

> I don't think anyone can get numbers, but partial ordering is much easier.

Agreed.

> If Steve and Susan are in different part of organization, the answer is "cannot compare". If they are doing different job, the answer is the same.

These are the situations where we would get the most value from the metrics though.

The team level already has an Engineering Manager or Tech Lead who can directly deal with team level problems.

[rob74]

I would argue that here you are talking less about productivity and more about basic competence?

[johnfn]

> Great. How much more productive? Can you turn it into a number?

This is moving goalposts. OP's argument was "There's No Such Thing as Software Productivity", not "You Can't Convert Software Productivity into a Floating Point Number With 3 Decimals of Accuracy."

[travisgriggs]

There’s no real dependable/reproducible single linear measure of software productivity”.

Would that be a fairer assertion?

[gizmo]

By that measure there also isn't a real dependable/reproducible scalar that measures athleticism. Nonetheless some people are clearly more athletic than others. Also within a single sport we can easily see that some players are better than others. Here too you could object that people who play offense should not be compared to players in defense. Or that it's not individual players that matters but the team as a whole. And yet, we can still figure out easily who the star players are.

[WgaqPdNr7PGLGVW]

> This is moving goalposts.

Then I shall move the goalposts. Can you address my shifted goalpost?

I personally did not interpret the author as literally meaning there is no such thing as software productivity but I agree the way he wrote it was confusing and could be interpreted that way.

Even in his toy example he clearly stated Peter did a better job than Frank.

[InsideOutSanta]

"What changed was not my productivity but the nature of the problem"

I think that's the source of the problem: it's impossible to measure the "work" required to solve most software problems. If you tell me to carry a stone up a hill, I can put that in a formula and know exactly how much work I'll have to do. But if you give me a ticket to do a DB upgrade, I can, at best, make an educated guess.

So by the time I close the ticket, how much work have I done, and how do I know whether the time I've spent it proportional to the work I've done?

[nradov]

I've been on all sides of this issue and I guarantee that as an individual contributor you lack the perspective and visibility into all of the factors that make up net productivity for your colleagues. Once you get a little more maturity and experience you'll probably understand this better.

[hoppp]

There is a difference between observing productivity and measuring it. If you measure it must be quantized into units which is hard, but you can observe it as is and come to a good conclusion too, without measurement.

[ipaddr]

The ability to look productive is a different skill. The ability to create any impression is a skill some have. Creating fires and putting them out like a hero is another skill.

What are your eyes measuring? Are you being fooled?

[theamk]

If you are IC, it's pretty easy to see if your teammates are "looking productive" vs "are really productive", as you know all the code and how it works.

For other teams yeah, it's harder, or maybe even impossible if the teams are isolated.

[InsideOutSanta]

> If you are IC, it's pretty easy to see if your teammates > are "looking productive" vs "are really productive"

I'm not sure how true this really is. We all like to think that we're good at estimating other people's ability, particularly if we work closely with them, but how can you validate that impression?

Something that happened to me at one point in my career was that I joined a team that was half new hires with little experience, and half long-term employees with a lot of experience. Because the long-term employees were typically extremely busy, I ended up answering a lot of questions from the entry-level devs. So I spent time documenting the system, doing trainings, doing 1-on-1 code reviews, and so on.

During the performance review, feedback from the entry-level devs was that I was highly productive, and feedback from the long-term employees was that I was a slacker.

[jchw]

No offense but reading this comment with the utmost attempt at interpreting it in good faith, it kind of sounds like you're just going off of vibes and can't actually quantify productivity any more than anyone else can. Otherwise... How exactly are you quantifying it? If you had to show your work, could you?

[johnfn]

I dunno, the opposite side seems equally absurd to me. Do you work at a software company? Do you have coworkers? Are you honestly telling me that, gun to your head, you couldn't say that some are more productive and some are less? That if you had to choose a co-founder for your next startup, that you would have NO idea where to begin, that any of them would be equally as good as the next?

[jchw]

I mean look, some people seem to be extremely productive, and sure, I could say that those people are almost surely more productive than others. It's still genuinely very hard to quantify if those people are actually vastly more productive, or if it just looks like that because they produce more obvious artifacts of their productivity. Hell, what is productivity, is it more productive to fix 1000 bugs or to be the tech lead on a product that reaches 1 million ARR? Does it matter what bugs?

I stand by what I said, whether people like it or not.

Including the part about going off vibes. Please explain how this "you can just kind of tell" mentality is not literally just going off of vibes?

(And I wouldn't choose a cofounder only based on productivity, anyways. I'm not even sure that would be the main criteria.)

[johnfn]

How would you choose a cofounder? I would call whatever metric you use to determine "would that person be a good cofounder" productivity. (OK, sure, let's narrow it down and say that you were tasked with choosing a purely technical cofounder; perhaps in this hypothetical you're helping your non-technical friend find one?) Do you still believe you couldn't do better than chance?

[jchw]

Well, a lot of the factors explicitly have nothing to do with general productivity at all, such as alignment. The goal with regards to selecting for productivity would be "someone who seems productive enough" but getting hung up on exactly how productive feels like a mistake, as aside from being unquantifiable, that isn't going to be the only or probably even main factor that decides the fate of the endeavor. Productivity is not the most challenging problem in software development. In my opinion, as far as factors for success for a technology endeavor goes, even overall technical competence winds up factoring in fairly low at the end of the day. What's important is meeting the threshold you need, not getting as high of a score as possible.

I should clarify that I actually agree with you if what you're saying is that the best measure of productivity we have is literally just going off your gut, but my argument is that this gut feeling is terrible. This is in large part because humans are biased, our gut feelings are swayed by things that simply shouldn't factor in. We tend to have more positive opinions of people that we think are like us and we sometimes wind up having negative opinions of someone based on stupid things like disagreeing with them on something that is ultimately irrelevant to whether or not they are productive.

And to me, the ultimate nail in the coffin is really in the question of what really constitutes productivity. Productivity is supposed to measure the efficiency of producing something, which already has pitfalls in and of itself when dealing with things that do have discrete, measurable indicators of progress, but programming doesn't, it's not even always obvious if progress is forward or backward sometimes. What's most important, performance optimizations, disaster planning, features, robustness, minimizing resource utilization? The best answer you can generally say is "It depends," and moreover, everyone will have a different set of competencies they're best at, so a person doesn't really have some single "productivity value" you could summarize them with. Yet, all of those things are pretty important for any serious technology organization, so you would want people with a variety of different affinities.

At that point, it starts to beg the question of whether or not attempting to directly measure software productivity is a worthwhile endeavor. I'd argue not.

[robertlagrant]

I suppose the question is: can you supply a word you would use when deciding on who to hire for a technical role? Does anyone off the street contribute the same amount of that word, or would you be selective?