Adding the Stopwatch to Level Up as a Software Engineer

So, you've followed part one, and written down your personal software process. You understand how you personally create software.

You've implemented part two, and been tracking the defects in your personal software process. You’ve been making changes, seeing how that impacts the defect rate, and the experience of making software.

Now you're ready for part three. Adding the stopwatch.

We’re going to load up our favorite time tracking software, and combine the new time data with the defect tracking sheet you’ve been using from part two.

We’re going to time how long it takes you to review a piece of code, noting how many defects you find along the way. Or if you’re writing code, time it. See how long it takes you to implement it. Then when you submit it for code review, tie back how many comments you received asking for changes or clarification. After you deploy it, note any bugs that cropped up as a result of that code.

This will give you an understanding of how long each step of each task takes, and be able to tie defects back to each phase. By doing this you’ll have a more complete understanding of the tradeoffs you’re making when experimenting with changes to your process.

Why?

Because when you combine the written process, with a defect tracking sheet, with the time spent on each phase, you can start really cooking.

You can see your process's state at the time the defect was injected, and do a few thought exercises. You can compare if you attempted that same phase today with the changes you've made to your personal engineering process would that defect still have been injected?

You can analyze since making a change, what impact does that have on the amount of time you spend at each phase?

You can look at your process and weigh out if the additional 20 minutes added to your code phase by using TDD pays dividends by reducing the time and number of cycles you spend in code review by multiple hours. Or that less defects are injected downstream since adopting it.

Or maybe you learn that you can spend an extra 3 hours in the design phase, but that the changes you are experimenting with, while more rigorous, don't reduce the amount of defects injected, or the amount of time that you have to spend addressing those defects.

The stopwatch adds the critical element.

The software you use doesn't matter so much as the fact that you use it consistently, and that it reduces friction for you.

If it ties directly into your IDE all the better, although I haven't found a particular tool that does that in a way that I like, because my process also means spending a fair amount of time in GitHub reviewing potential designs and doing code review.

So what does it look like in practice?

Getting started

I use the free app Toggl Track, because it has great support across desktop and mobile. You could use any time tracking software you'd like.

As I start a piece of work I start the time tracker, indicating what issue I'm working on and what phase it's in. Then when I complete the phase, I stop the timer. If I'm interrupted I currently stop it as well, and start a new timer for the new activity that has interrupted me. That way if I need to fix a defect from a previous phase I can track the time and number of cycles related to it.

Other tools give me the ability to track total wall clock time elapsed since starting the phase, and I'm interested in using this to understand the time actively undertaking the work.

I take the total time elapsed and note it on a time tracking sheet that I use with the defect tracking sheet.

Using the data to guide and evaluate changes

Now that I've got the time for each phase tied back to a given piece of work, and a defect tracking sheet, I can use the two together to truly better understand how the changes that I'm making to my process impact my productivity.

Am I making worthwhile trades that reduce defect rate, and active as well as total clock time elapsed to deliver a given piece of code?

I've got one more piece that I recommend folks use to improve their process coming in part 4, "Live streaming" your software development process. It's one last tool I currently recommend to help individuals inspect and improve their process, but going to the place (and time) the work is being done to observe it.

If you've added the stopwatch, tell me what you think. What’s working about it? What’s not? What are you doing differently? Let me know on Twitter, @brit_broderick.