No spam, no B.S.
Unsubscribe if you’re not happy.
As a software developer, what does productivity mean to you? How do you measure it?
Do you measure it?
There are a lot of misconceptions around how to track your effectiveness in order to find opportunities for improvements—and plenty of software developers who resent the idea of turning in timesheets to their supervisor each week.
But managing time is a critical activity for improving productivity as a software developer.
Allow me to explain.
Whether you’re a freelancer or in-house software developer, there’s no resource you own that’s more valuable than time.
While your expertise might be packaged with a title that derives from “software developer”, billed by hour, project, or straight salary, the price you charge for your work should be a function of the time and effort you have to invest to successfully complete project responsibilities (not to mention all the time that you’ve invested up until this point honing your craft!).
It’s important to understand that your time spent on a given project goes further than promised deliverables. Oftentimes, it also involves revisions, or at minimum, time spent going back and forth with a client/your boss. A failure to account for these additional project time sucks can lead to undervaluing the true cost of a project—or under delivering when you’ve promised results within a specific time frame.
It gets even more complicated when trying to measure productivity using metrics that don’t really tell the whole story. The knowledge economy is defined in terms of inputs that are completely different than the ease of straightforward process found during the Industrial Revolution, where most people worked in factory jobs.
Most software developers use some type of standard for measuring productivity that’s inevitably flawed, such as:
It doesn’t have to be as blunt as turning in a report to your boss under the guise of “Here’s how many hours I worked this week.” It’s also not as complicated as tracking function points or bugs and defects.
Put simply, it allows you to understand exactly where your time goes every day.
The major issue with time tracking for software developers?
Schedules suck. Based on their existing work processes, it’s hard to see them as necessary and as a result, schedules tend to seem unrealistic.
The problems begin when managers introduce time tracking as an absolute requirement without helping their team understand the implications of doing so, and how time tracking can help improve productivity in a big way.
The resulting backlash from managers who push time tracking forward, without buy-in from their team, can be discouraging enough to kill the initiative on arrival. After all, why go to all the trouble of working on a schedule if it’s not going being implemented by a group of willing individuals?
With this in mind, it helps to have a system for time tracking that integrates with a scheduling system that already functions within the accepted software developer mindset. Evidence-based scheduling is the ideal solution, breaking up to-dos into micro tasks that can be measured in hours (with nothing longer than 16 hours).
Joel Spolsky, Co-Founder of Trello and CEO of Stack Overflow invented the concept of evidence-based scheduling. The approach is rooted in two core concepts:
Evidence-based scheduling is also empowering: it relies on the developer to set their own schedule, in order to improve accuracy.
Part of finding success with evidence-based scheduling is labeling tasks and projects with just enough detail and with just enough time allotted to each task.
Assigning yourself a task to work on a feature with a due date that’s weeks away, tentatively named, “Mobile app bug fix” (with no additional detail), is a recipe for disaster. That’s why giving yourself a 16 hour maximum leaves little time for messing around or getting too caught up in your thoughts.
Good time-tracking practices go hand-in-hand with solid project management skills—you’ll need both to find productivity success. Working on one helps you develop the other: it’s a self-perpetuating system.
As a best practice, when tracking time, each task should contain a simple descriptor. Assuming your project is well-managed, Simple Programmer recommends dividing tasks into four major categories: Features, Bugs, Chores, and Meetings.
As mentioned earlier, simplicity is key—you don’t want to get bogged down in the details to the point that the prospect of getting started seems overwhelming. Instead, focus on providing detail to the point that it gives an understandable, at-a-glance context to what you’ll be spending your time on.
Here are a few examples of how to label tasks with just the right amount of necessary detail:
Following the ideas set forth in the concept of evidence-based scheduling, you want tasks that are broken down into small components. Scheduling tasks that take anywhere from a few hours to an upper limit of sixteen hours is the ideal range.
For many software developers, the practice of tracking time can still seem like your boss taking on the role of “Big Brother” ala 1984. But weaving time tracking into your process can actually benefit you in a number of ways.
Here are a few ways that time tracking can benefit individual software developers working in a organization:
The more you get into the habit of tracking your time, the more actionable data you’ll have access to, to improve your processes over the long-term.
Whether you’re a freelancer or software developer in-house, this data can be used to estimate similar projects requiring a quote for turnaround time in the future.
Take this a step further to increase your productivity.
Joel Spolsky recommends tracking the accuracy of your time estimates for given tasks. Try to think of a project as not being truly complete until you’ve gone back in to compare your initial estimate with the actual results—including any meetings and bug fixes you might not have thought to account for in your initial estimate.
Though no two projects, regardless how similar, are exactly the same, keeping yourself honest by tracking accuracy is a great way to forecast trends.
As most programmers are notorious underestimators, you can use this data to bill clients at a higher rate—or even just buy yourself more time to complete tasks without pushing yourself too far. Having to constantly work overtime due to your own issues with time estimates is not a recipe for success: it’s a sure-fire road to burnout.
Spolsky’s accuracy estimation process is simple and straightforward: divide your estimated time for a project by the true amount of time necessary to build a feature. Plot each estimate as a single data point to determine your personal estimate accuracy. If you can be consistent, you’ll have enough data to see trends in just a few weeks—then you can make changes as necessary to improve your productivity (and save your sanity!)
From a project management perspective, being able to see how team member’s estimates match up with reality is invaluable for building an accurate development timeline for any given project (with direct impacts on being able to definitively say when a product will be released). It doesn’t even necessarily matter if these individuals become more exact when it comes to estimating the time they’ll take on various projects over time, so long as they continue to follow a trend with underestimating.
Effective time management means finding more time in the day for the things you love to do both while at work and outside of it. It can also result in increased fulfillment in both aspects of your life: it’s always a good feeling to find new opportunities for effectiveness and productivity.
In the workplace, time management has earned its place as an important tenet of project management and can help employees to develop skills like goal setting, prioritization, and planning.
With only 24 hours in a day, many of those hours already tied up in sleeping and other non-negotiables, it’s easy to understand time as a finite and special resource. By being purposeful with where and how you spend the limited time life affords you, you’ll find more time for the things that matter most.