Bob tackled a home improvement project last weekend. He wanted to redo his sprinkler system. So, he went to the local home depot and perused the sprinkler section found some things he liked and bought them. But, when he went to install the sprinkler, he realized he didnt have the right tool to cut the poly and went to the store to buy it. Then he installed a few sections, but then he realized there is actually two separate sizes, so he returned to the store to buy new poly. Finally! The sprinklers are installed, time for a test. Bob tests the sprinklers but needs to tune them and realizes he does not have the right tool, so he returns to the store once again.

Charlie decides he is going to tackle a home improvement project this weekend. He wants to redo his sprinkler system. He knows that he needs to replace 5 sprinklers and they are attached to two different size feeds. He goes to the store and buys everything he needs and completes his project. But, like Bob he forgot about the tool to tune the sprinklers and needs to return.

While this could provide a lesson on being proactive versus being reactive, or how much to plan, I want this to be a lesson in round trip time. Turns out round trips really matters. The sprinkler project itself only took a few hours itself, what took a lot of time was getting to the store. If the store is 15 minutes away and you make 4 trips, that is 2 hours spent going to the store (plus more in the store)!. If the store is an hour away, it is even worse! The overhead here really matters.

When I was at my first coding job it took about an hour to compile and test the codebase. Let me tell you what, it teaches you to write and debug your code really quickly. You simply do not have the time to retry it over and over. The same applies everywhere though, how long does it take you to test your code? One thing I focus on above all else is making sure my team can quickly and easily test their code. Why? Because that is something that everyone is doing multiple times per day. If I can save a team of 10 engineers, 2 minutes per iteration of testing, and we assume there are 10 iterations per day - I just saved ~16hrs of time that week. That is half an engineer!

This concept applies to so many more things though. You should build batch APIs. Why? Round trip time. Lets take a fairly simple API with fairly normal behavior. GetBeer. The network takes ~5ms, overhead of the call (auth/validation/throttling) takes another 5ms, calling your database takes 20ms, and your processing takes another 20ms - for a total time of 50ms. Fairly standard non-optimized API. But, what about a BatchGetBeer for 10 items? The network still takes ~5ms, the overhead still takes ~5ms, turns out your database supports batch so it still takes 20ms, but your processing increases 10x to 200ms - for a total time of 230ms. On a per-item basis, that is almost twice as fast (23ms versus 50ms). Your customer is happy because they get data faster and you are happy because you spend less on compute - that is a win win.

You are trying to propose a design. There are a bunch of people who are going to review, but you didn’t provide context into why you wrote the design. So, all of those people get you to provide context in the meeting but then you don’t get to your design, so you schedule another review. Then all of those people look at the requirements, but you glossed over requirements so the reviewers do not know what you are trying to build. So, you schedule another review. And the process repeats a few times. Has this happened to you? Have yous seen this happen to others? Once again, round trip time matters. Make those early reviews fast by having a small review with a small group of people. You will get meaningful feedback and it only costs a few hours (1hr per 2-3 reviewers) of reviewers time, as opposed to a lot of time (1hr per 10+ reviewers). You could be better and reduce the number of round trips, but sometimes that is not possible - so make each trip cost as little as possible.

Round trip time matters. This applies in almost every scenario that you will be a part of, but I provided the top three that I see good engineers frequently miss. When you can, eliminate round trips because they are expensive. When you need multiple round trips, that is okay, but make each one cheap. 1 round trip that costs 10X is fine, 10 round trips that cost 1X is fine, 10 round trips that cost 10X is not fine.