This article was written during abnormal circumstances, with much of the planet under lockdown due to the COVID-19 pandemic. Parents with children at home have far less time, and pretty much everyone is feeling stressed and distracted.
Under more normal circumstances there are only so many hours in the day to do your job; now it’s even worse. And yet work needs to get done: code needs to get written, features need to be shipped, bugs need to be fixed.
Faced with an ever growing list of tasks, how do you get everything done?
The short answer is, you can’t.You will never get everything done.
What you can do, though, is choose the right work, the most valuable work, the most useful work, the work with most leverage. Choose the right work and you can gets orders of magnitude improvement in your output.
Let’s see how.
Your output as a programmer is based both on your productivity and on how much time you work:
Output = Productivity × Time Worked
The first thing to notice is that there is a hard limit on how much increasing your working hours can help. After all, there are only 168 hours in a week.
If you never slept, ate, or did anything but work—and this will literally kill you—you can work 4.2× as much as a 40-hour workweek, and that’s it. And even with smaller increases in work hours, the gains quickly decline. As you work more hours you’ll become fatigued and make more mistakes; beyond a certain point those extra work hours will decrease your productivity, canceling out any gains.
Since increasing working hours isn’t really an option, the key to increasing your output is increasing your productivity. Productivity is the output you produce in each fixed unit of time, for example:
Productivity = Output per week
If you’re going to improve your productivity, you need to understand how to measure output.
The obvious measure is how much code you write: the more code, the better. This measure is obvious, popular, and completely wrong.
All other things being equal, is it better to implement the same feature with 10 lines of code, or 10,000 lines of code? If we measure output by code produced, the latter solution is better, but in most cases a 10 line solution is preferable to 10,000 lines. More code means higher maintenance costs, not to mention more opportunities for defects.
Your job as a programmer is not writing code, your job is solving problems: software is a tool, a means to an end. Software becomes valuable because of the problems it solves.
As a rough measure, your output as a programmer can be measured by the problems you solve: the more significant the problems you can solve, the better.
If you work for a business, significance eventually translates directly or indirectly into monetary terms: money made or money saved. In other areas you can come up with domain-specific concrete measures of usefulness: number of people served, carbon emissions reduced, number of scientists using your software, and so on.
Note: If the problems you solve produce negative value you will become anti-productive: the better you are at your job, the more damage you will cause.
If making money hurts people or the environment, your work may be productive for your employer but anti-productive for society as a whole. So make sure you’re carefully considering the ethical consequences of your actions as a worker.
Given the above, here’s how you can increase your productivity:
- Find the most significant problem you can work on.
- Come up with the most efficient solution to that problem.
- Implement the solution with minimum wasted time.
Let’s go through these steps one by one, and see why they’re key to productivity.
Let’s consider our formula for productivity again:
Productivity = Significant problems solved / Week
There are many problems you could be working on, so first you have to choose one. If you could solve either of these problems, should you be working on:
- Implementing a particular missing feature; this will increase revenue by $50,000.
- Fixing a bug that was decreasing customer retention; this will increase revenue by $1,000,000.
All other things being equal, the second problem is obviously the one you should be focusing on. Even if it takes 10× as long to solve and implement that bug fix, it should still be the highest priority:
Productivity of #1 = $50,000 / 1 Week = $50,000 / Week Productivity of #2 = $1,000,000 / 10 Weeks = $100,000 / Week
Here’s the issue: in order to fix that expensive bug and improve customer retention, you need to know the problem exists. If no one ever notices that customers are leaving, if no one ever finds that bug, if no one realizes the connection between the two—then that problem will never be solved.
And that’s why finding problems is the first and most valuable step in increasing productivity.
Once you’ve identified the most significant problem—or once your manager assigns you a problem they identified—you need to come up with a solution.
Which solution do you think is better?
- Takes 1000 lines of code and 4 weeks to implement.
- Takes 100 lines of code and 3 days to implement.
All other things being equal, the second solution is obviously better.But again, you need to find that solution.
If you only ever find that first solution, then no matter how efficiently you implement it, no matter how focused you are, no matter how much you manage to speed things up—you’re still implementing a much less efficient solution.
And that’s why identifying better solution is the second most valuable step in increasing productivity.
Once you’ve identified a problem and chosen the solution, there is only so much leverage you have to improve productivity. You obviously want to avoid getting stuck and spinning your wheels, because wasted time reduces your productivity.
But given a particular solution, there’s only so much waste you can reduce, only so fast you can go:
Wasted time → $50,000 / 2 weeks = $25,000 / week No waste → $50,000 / 1 week = $50,000 / week
Efficient implementation is the last and least valuable way of increasing productivity.
While you get the most increased productivity from identifying problems and the least from efficient implementation, your career as a programmer progresses in the opposite direction:
- Junior engineers implement solutions.
- Senior engineers find solutions and implement them.
- Principal or staff engineers identify problems, find solutions, and implement them.
So becoming more productive isn’t just about helping your employer’s bottom line, it’s also about learning the skills that will give you more pay and more influence.
Critically, technological skills are necessary but not sufficient:
- Your testing skills don’t matter if you can’t convince your manager of the value of testing.
- Your software architecture skills don’t matter if no one has ever heard of your product.
Elsewhere I've written many articles on improving your skills.
And this article is actually an excerpt from a book I've written, The Secret Skills of Productive Programmers, covering the non-technical skills you need to get better at identifying problems, solving problems, and implementing them on schedule.