Productivity isn't about going faster
humanpro.co
Productivity isn't about going faster
1–10 of 42 posts
Re: Productivity isn't about going faster
#2This is way vague to not be AI slop
Re: Productivity isn't about going faster
#3Curious 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?
Re: Productivity isn't about going faster
#4But KPI is.
Re: Productivity isn't about going faster
#5Companies will tell you that it allows them to examine many directions faster, and in a sense they are right.
Not doing something is much faster than doing it fast. Sit on your ideas, think them trough, dismiss early, or choose to move to implementations.
Re: Productivity isn't about going faster
#6Curious 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?
Does it matter? The ultimate way to measure productivity is $$$.. companies that generate more $$$ with the same number of "people" are more "productive". Drilling that number down to orgs/teams/ICs is a political endeavor, which means how you do that depends on the result you're looking to generate.
Re: Productivity isn't about going faster
#7Any claim about "productivity is due to X" that doesn't define a timescale is either flawed or misleading. In fact all measures of anything need to be done across some meaningfully defined time scale to have any relevance.
Re: Productivity isn't about going faster
#8Curious 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.
Re: Productivity isn't about going faster
#9Curious 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?
Does it matter? The ultimate way to measure productivity is $$$.. companies that generate more $$$ with the same number of "people" are more "productive". Drilling that number down to orgs/teams/ICs is a political endeavor, which means how you do that depends on the result you're looking to generate.
Even if the ultimate measure is dollars most employers will attempt to predict which metrics of employment best correllate with dollars so they can predict how many people to hire
Re: Productivity isn't about going faster
#10> It's about spending your time where it truly matters.
I think the author conflates productivity with meaningfulness.