Hey Dev community! Maxim here from the Merico team. We spend a ton of time thinking about engineering productivity:
How to measure it? How to define it? How to improve it?
All simple questions with tricky answers. I'd love to hear from you on what you have used in the past that has worked whether tools, metrics, or techniques!
Hope to hear from you, and look forward to the conversation!
Disclosure: On Thursday we are releasing a free version of our analytics product to give developers better insights and data into their own performance and productivity. We are on a mission to help people articulate their accomplishments to become better coders and achieve more in their careers!
Top comments (7)
IMHO Productivity doesn't matter that much.
Productivity is about doing more things in the same amount of time.
Obviously if you are totally unproductive, you need to find the reason why and work on it. For me, finding inspiration by listening to music usually does the trick. But past a certain point, you get diminishing return.
It doesn't matter that much how quickly you are doing tasks that don't move the needle that much.
What matters more than productivity is efficiency.
Efficiency is the art of choosing the right problems to work on.
Recommended readings:
Great points all around, thanks Jean-Michel! Definitely true to say that high-output / low-impact is likely far less valuable than low-output / high-impact! I always love hearing what people enjoy listening to when they code, do you have any favorites?
Thanks for the Edmund Lau recommendation, I'll be giving that a read!
Colombian cumbia is great
music.youtube.com/playlist?list=PL...
productivity is usually measured by "the amount of work gets done in a period of time". However that should not be used as a reward/punish system for people, because if so, people would start finding ways to increase that number or keep it high.
I believe that number should only be a discussion subject.
This is a really interesting point, something this makes me think of is how productivity is also somewhat context dependent on what's going on in the workflow.
Certainly it's a paradox that if you define or measure something incorrectly you can encourage people to pursue things that inappropriately game those measures or goals!
Have you felt like any measures you've seen are particularly problematic? Very curious!
Yes, a lot throughout my career.
An example would be "Velocity" metric in agile software development teams. That number shows on average how much work gets done by that team in a sprint.
It is fine to use that number as a guideline for business estimations, but developers shouldn't care about that number. devs should only care about the product they are building and achieving the sprint goal.
developers should care about other numbers and metrics.
Amount of products and services, which were created or saved in a period of time. Might be easier to measure, when it is translated to $