This is a re-blog from giolodi.com. Checkout the original for more links and posts.
Productivity is often thought of as "getting things done."
This definition is intuitive to grasp and makes it easy to measure productivity.
But in the context of software development, and knowledge work at large, "getting things done" is a hopelessly short-sighted way to define productivity.
A machine cranking widgets is as productive as the number of widgets it cranks.
The widgets are all the same, so the more the machine can crank in a given time, the more productive it is.
However, the tasks on a software developer's plate are not all equal.
Someone could spend a whole day relentlessly ticking off tasks on their to-do list, but if those tasks are useless, the day will not have a productive one.
Productive software developers don't merely get things done. They get impactful things done.
Productivity is tied to impact.
It is a measure of results, not raw output.
So, stop counting how many tickets you moved into the done column of your Jira board.
Impactful work is work that generates positive change in the business.
Yes, the business.
As important as self-determination is, as crucial as it is to exert mastery and to find work that is inherently satisfying, we need to come to terms with the fact that productivity in the workplace depends on the effect we have on the bottom line.
If software development is your hobby, then a productive session might just be one where you have fun, even if all you do is tinker with your .vimrc.
But if software development is your job, then you need to ask yourself whether you produced something valuable, and, as Derek Sivers put it, "money is a neutral indicator of value."
Using impact as a lens to understand productivity, it becomes clear that cleaning up your inbox is not as productive as reviewing a colleague's pull request to unblock them.
Likewise, fixing a bug that trims the last word in the last cell of your settings screen is not as important as fixing a bug that prevents users from signing up to your service.
Impact, value delivered, is the true measure of a software developer's productivity.
But impact doesn't exist in isolation.
There is another crucial dimension of productivity, one that is too often left out of the conversation: time horizon.
Some activities might not seem productive in the context of a particular day, but do contribute to mid-to-long term productivity.
Resting is the perfect example of how factoring in the time horizon changes the definition of productive activity.
If you limit your view to impact over a given day, then the more work you can fit into it, the better.
However, as anyone who went through burnout will tell you, overworking is not sustainable.
Unless there's a fire to put out, there's no point "killing it" today if the result is you'll be out of commission for the rest of the week.
An ongoing incident that is losing you money and customers grants burning the midnight oil, all the rest can wait till tomorrow.
(If you are in your twenties and think this example doesn't make any sense, trust this 33-year-old grump—Wait until you cross the 30-threshold, then you'll know what I'm talking about.)
Getting plenty of rest in your day is productive because it ensures you can keep working without catastrophic burnout.
Other activities that are productive in the long run include: reading to learn something new, paying off technical debt, and taking a few minutes at the end of the day to reflect on what went well and what you could have done better.
Once you move beyond the myopic measure of raw output, productivity becomes too nuanced to fit a scorecard.
Productivity is a function of impact over a medium-to-long time horizon, but that is hard to quantify without hindsight.
To be a productive developer, the best you can do is to choose tasks to work on by factoring in business objectives, time horizon, and opportunity cost.
If that sounds hard, it's because it is.
And ambiguous, too.
You won't get it right all the time, but that's not the point.
What matters is being intentional, thinking impact over the long-term, and error-correcting as you go.
This was a re-blog from giolodi.com. Checkout the original for more links and posts.
Enjoyed this post? Get new ones in your inbox 👉📬
Cover image is a remix of the author of this picture by Amr Taha.
Top comments (0)