The worst bug I ever had to fix involved two machines in different buildings. I would make a change on one machine, and then have to walk 15 minutes t

Why engineering teams should measure feedback time

submited by

Style Pass

2021-07-22 12:00:08

The worst bug I ever had to fix involved two machines in different buildings. I would make a change on one machine, and then have to walk 15 minutes to the other building to see if it had worked. This was one of those bugs where you don't know what's wrong exactly so you keep testing hypotheses until you find a clue. I tested somewhere between 20 and 30 before I figured it out. I walked a lot that day.

What made this the worst bug ever wasn't the bug itself - it was the feedback time. The time between me writing code, and being able to test it. Programmers intuitively know that feedback time is important and we tend to optimise for it. We love keyboard shortcuts, use browser developer tools, and we built HMR.

Programming involves a lot of trial and error. You start with a rough solution, write the code for it, compile/build/deploy it, test it, and then adjust the code again until it works. The time you spend waiting between writing and testing code doesn't just slow you down because it takes time, it also breaks flow and tempts you to context switch if it's long enough. These all have a huge impact on productivity. Think about how much faster you can iterate on the front-end of a website using your browser's developer tools, versus working on a back-end that you have to compile each time you make a change.