This article first appeared on the Triplebyte blog and was written by Kattie Thorndyke. Kattie is a professional engineer who worked exclusively in motorsport and automotive engineering utilizing OpenFOAM open source CFD software to optimize full-vehicle aerodynamics.
If you were to ask a fellow programmer or software engineer: “How can I be sure that I’m being productive enough at work each day?”
You’d likely get an answer that’s as annoyingly unhelpful as this: “Well, it depends. It all hinges on what you’re trying to accomplish, how long you have each day to work on it, and what success looks like for that project.”
Don’t worry, I’m not going to leave you hanging. I’m going to give you actual tips, strategies, and examples of metrics that can be used to measure your productivity.
As engineers, we thrive on data. We need to see progress, improvement, and positive outcomes. Our brains are wired a little differently than the rest of the population, but we too fall prey to the anxiety of “not enough” — not enough lines of code, not enough hours of work, not enough to show for our efforts. It’s time to change that by harnessing a some key metrics to put things into perspective.
Cycle times
When you’re working on a sizable project, it’s easy to leave the bulk of the work until you're closer to the deadline. I’ve been known to dawdle at the beginning of a large project only to then panic towards the end when the deadline is closing in. To prevent this, we need to set more reasonable cycle times, or the block of work that requires raw coding or dev work, to get through the workload.
For programmers, this is a common practice within teams that embrace agile methods. Two-week work sprints are often used to break down the project into manageable pieces and set a reasonable goal for the end of each sprint. In this way, we avoid procrastination and have to show progress by the end of the sprint.
If you’re working on a project yourself, you can break your program down into pieces that will logically build on one another, setting yourself a deadline every two weeks. What that management of yourself essentially amounts to is "definition" planning or lead time work. It can be a great idea to invest in this kind kind of work (which can include developing automations) if the result winds up being more efficient cycle times (coding/programming time) to come.
Of course, all of this structure and measurement allows you to document your progress and show your results to any superiors asking where things are at. If you can hit your two-week goals each time, you know you’re being productive enough.
Positive acceleration
Now, improving your work speed is an obvious plus, but in the engineering world, it's important to communicate things (and brag) with the proper metrics and language. Shortening dev work cycles is referred to as positive acceleration. For example, if it took you exactly two weeks to create and test a use case for your program in cycle one and a second attempt took you 1.75 weeks after automating a few features, you're showing improved work speed or clear positive acceleration.
In programming, the options for getting to positive acceleration are endless. You can monitor different aspects of your project that should accelerate over time, such as test case creation, simulation run time, documentation, and debugging. Even a very small positive acceleration is a step in the right direction.
Code efficiency and the metrics specific to your role
Zooming in on the work a bit more, it's true that every programming project, industry, and role will be different. But no matter where you’re working, ramping up your code accuracy and efficiency as high as you can will improve your overall effectiveness. A few main metrics here to keep an eye on are code complexity (how few lines of code can you use to accomplish a task), code coverage (how much of your code can reasonably test and review in a cycle), and code churn (how much of your work gets modified in review).
(Image: Pluralsight)
Beyond these, it is also important to define the metrics specific to your role that you should be monitoring for productivity.
To give you an example from my past work experience as a CFD engineer, I monitored a few key productivity metrics that I knew mattered to my organization. First, I monitored cluster idle time, which is a clear representation of how I was using the compute resources to their fullest potential. Over-provisioning of on-prem or cloud compute resources is a common cost overrun for companies. So, by showing that I was able to feed the cluster and keep it working 98% of the time, including evenings and weekends, I proved that I was productive enough.
I also measured a few metrics specific to the accuracy and efficiency of the code I was using. I measured the residuals of velocity components and turbulence characteristics so I could report on how confident I was in the results. I also measured how long it took simulations to converge and how that related to the accuracy of the results when compared to specific correlation cases. This allowed me to tell the story behind why I chose certain simulation techniques, and how I was able to maximize the number of simulations on the cluster without sacrificing accuracy.
Depending on your project and management team, you’ll adjust the metrics you monitor so you can communicate how productive you’re being. If you’re unsure, have a conversation with your team to confirm that your definitions of productivity match. These metrics aren’t just great data for your next performance review either; it helps to keep you constantly questioning your workflows and processes so that you're pushing the envelope and improving. And that is really the epitome of programming productivity.
Related: What the wrong side of agile looks like – and how you can avoid it
Simple tips to move your metrics in the right direction
Now, addressing the nitty-gritty of tools and procedures to improve the exact metrics you're targeting will certainly vary. But there are some simple things that really make a difference to your overall daily engineering output, and inevitably improve things like cycle times and acceleration. I, myself, have rolled my eyes at these suggestions in the past. That is until I spent time instituting them and realized how crucial they are to my success.
One of the biggest killers of productivity is multitasking, or task-switching. Whichever term you choose, it’s stealing your time. The more you try to do all at once, the less actually gets done over the course of the day. But what does this mean for a programmer?
When you’ve got a specific goal, task, or piece of code you’re working on, you need to have all other distractions strategically turned off. I mean your email, browser, cell phone, and social media must all be out of your sight, with notifications off. I actually tether my phone to the wall in another room. It’s just too tempting to interrupt your workflow when distractions are aplenty.
Next, consider how long it takes you to get down to work when you sit at your desk. Do you spend time trying to remember where you left off the night before? Do you get sidetracked by conversations happening around you? Take some time to be critical of your current work setup, and ask if you can do a few simple things to set yourself up for a productive day, like:
- Set your to-do list for tomorrow when you shut down for the day.
- Write yourself a comment or note to explain what you were coding before you take a break.
- Put in your earplugs or earbuds before you start to work to block out any competing noise.
- Set a Pomodoro timer for 25 minutes of work, and then allow a five-minute break to look at your email, phone, or to go for a coffee break. (Or if you are looking for a time blocking Pomodoro alternative, check out this blog from my colleague.)
I've found that applying these day-to-day strategies in your workflow can help you both hone in on improving the metrics specific to your role and shrinking the general lackadaisical drag that can gum up any meticulous engineering workflow.
Triplebyte helps engineers assess and showcase their technical skills and connects them with great opportunities. You can get started here.
Top comments (0)