Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Productivity isn't about going faster

humanpro.co

Post reply on HN
Print view View original

31–40 of 42 posts

Re: Productivity isn't about going faster

#31

Post by ozim »

simonw wrote: post #8
gkcalat wrote: post #3

Curious how companies measure developers productivity in the era of vide engineering... Token usage? Lines of code? Features shipped? Bug fixed? Code health? Maybe we should use amount of code read or PRs reviewed? Or another metric that would correlate with the amount of person's accountability?

Measuring developer productivity has been an unsolved problem for decades already, vibe engineering just makes that unsolved problem feel even harder.

Measuring “single developer productivity” is unsolved problem. It also is not a problem unless you are pointy haired boss and want to plan bonuses based on that or fire people based on that.

You definitely can measure team output over time and have some idea. Compare team to what they did in last 6 months and you have your measure for having idea how much can be achieved next month. But you cannot not plan like what can be achieved in longer period just next sprint or two.

This said you cannot compare teams like that.

Re: Productivity isn't about going faster

#32

Post by [deleted] »

irjustin wrote: post #24

I have so many thoughts on the 5 or 6 things this article touched on and they're all jumbled together into this cat poster of an article. Productivity, prioritization, efficiency, control, purpose, happiness... I'll just rant about one: Control. > you can’t decide to kick the ball, nor score a goal, or much less win the game; you can only decide to move your leg. If you couldn't control how you win the game, why the…

[deleted]

Re: Productivity isn't about going faster

#33

Post by tonyedgecombe »

chii wrote: post #17
simonw wrote: post #8

Earlier quoted context omitted.

Measuring developer productivity has been an unsolved problem for decades already, vibe engineering just makes that unsolved problem feel even harder.

proxies like customer/revenue growth, complaints/satisfaction and such works imho.

How can you assign revenue growth to a particular feature?

Even if the customer tells you they bought your product because you added widget x you can't really be sure.

So much of this stuff is emotional rather than rational.

Re: Productivity isn't about going faster

#34

Post by jimbob45 »

ninjahawk1 wrote: post #20

I’ve been thinking about this more and more lately. What can I really do that matters? Make money? It’s gone eventually. Be remembered? I’ll eventually be forgotten. Be REALLY remembered? I’ll be forgotten in a few thousand years. Become immortal? All entropy in the universe eventually dissipates. What I can do though, is have a good time with the people I love.

Work hard so that the next generation is better off than you were, cascading down for generations to come.

I’ve heard it said that the meaning of life is to plant trees for shade that you will never personally be able to enjoy.

Re: Productivity isn't about going faster

#36

Post by ozim »

chii wrote: post #17
simonw wrote: post #8

Earlier quoted context omitted.

Measuring developer productivity has been an unsolved problem for decades already, vibe engineering just makes that unsolved problem feel even harder.

proxies like customer/revenue growth, complaints/satisfaction and such works imho.

Missing part of discussion is “what for?”.

To make personnel decisions who to fire or give bonuses it doesn’t work. Just as lines of code don’t. If any of those indicators is lacking you have to dig deeper.

What lazy managers want is a single number they don’t have to dig into to make decisions. Lines of code, story points, bug counts.

To plan work for next sprint having last 6 months of stats gives quite good idea what can be achieved. But story points or stats are not useful for telling if specific features will be developed in specific timeframe.

Re: Productivity isn't about going faster

#37

Post by eviks »

Cute, but make up your own term instead of polluting the existing one.

> For instance, would you really want to speed up time spent with your loved ones?

First of, do you really think about productivity when doing the positive thing you imply here? But also, for some less pleasant activities with your loved ones - yes, of course you want to speed it up to have more time for something better!

Re: Productivity isn't about going faster

#38

Post by pjmalandrino »

gkcalat wrote: post #3

Curious how companies measure developers productivity in the era of vide engineering... Token usage? Lines of code? Features shipped? Bug fixed? Code health? Maybe we should use amount of code read or PRs reviewed? Or another metric that would correlate with the amount of person's accountability?

defenetly a big strugglez.. we are working with researchers on that actually..

I think a descent answer is a cross-factor one.

We have agile teams, that have a velocity measured in story points. This gives a first good idea but it is not the all truth. It is a very relative measurment.

but if you add informations about pure productions : Number of PR's Number of commits in PR's Number of code lines Number of comments on PR's

Then you got something more interesting.

Also, we are looking for a way to add quality indicators to understand if it is just rush, or full vibe coded code that will make project los t in few months ..

But I agree with other comments saying that it is a struggle, and AI coding just make more painful ..

Re: Productivity isn't about going faster

#39

Post by roncesvalles »

gkcalat wrote: post #3

Curious how companies measure developers productivity in the era of vide engineering... Token usage? Lines of code? Features shipped? Bug fixed? Code health? Maybe we should use amount of code read or PRs reviewed? Or another metric that would correlate with the amount of person's accountability?

My company (primarily a software company with 100k+ employees) went back to measuring lines of code.

Managers have a literal orgwide leaderboard now of how many LOCs were committed by each IC. As expected, right after they started doing this, there were a lot of frivolous refactoring projects where people moved code from one repo to another repo or consolidated stuff into a common repo, just to boost their LOCs.

Re: Productivity isn't about going faster

#40

Post by roncesvalles »

l5870uoo9y wrote: post #10

> It's about spending your time where it truly matters. I think the author conflates productivity with meaningfulness.

Productivity isn't about doing things faster as a lot of people erroneously believe (that's efficiency). Productivity isn't just efficiency * time_spent_working either.

Productivity is about how quickly you're progressing towards your high-level objective. Having a knack (or methodology) for knowing what to do is way more important than doing things fast.

Post reply on HN