On May 10, 1869, Leland Stanford (founder of Stanford University) hammered a ceremonial, golden spike to complete the First Transcontinental Railroad in the United States, connecting together the Central Pacific Railroad from the west and the Union Pacific Railroad from the east. Each hammer stroke was transmitted around the nation by telegraph operators as a real-time click, in what might have been the world’s first mass-media event. When the final stroke had fallen, telegraph operators kicked off nationwide celebrations with a simple message: “DONE”. ¹

The long-awaited railroad completely changed the landscape of travel in the United States. Prior to its completion, travelers only had two options to go from coast to coast, and both could take more than four months. ^{2 3} They could travel by wagon and brave the wilderness, the elements, and treacherous mountain crossings, or they could hook around South America by ship, at a time when scurvy – a painful and often deadly disease, now known to be caused by vitamin C deficiency, that inflicted those at sea – was still not quite understood. ⁴ With the railroad’s completion, travel time from San Francisco and New York dropped down to a mere week. ⁵

The First Transcontinental Railroad not only saved coast-to-coast travelers four months of travel time, but it also opened up radical new ways of thinking about travel. What once was a one-way journey across the United States – as few could afford the time, the cost, and the risk of a four-month journey more than once in a lifetime – now became a cheaper and faster trip that passengers could take more than once. It became possible for Americans to visit friends and family around the country, for farmers and merchants to expand their businesses and sell to national markets, and for more settlers to move west because more supplies could be transported.

A similar lifestyle transformation repeated in the 1950s, when the advent of passenger airlines reduced cross-country travel to under ten hours and again completely revolutionized how we perceived travel. ⁶ Faster transportation didn’t just save weeks of travel time; it also opened the doors for new reasons to travel. Families became more geographically distributed knowing that family members could fly back multiple times a year. Jet-setters flew cross-country or to other continents for parties and meetups over the weekend and would return the following week. Businesses started developing more nationwide relationships and would fly out representatives to meet their clients.

What’s notable about both of these time-saving technologies is that their adoption didn’t merely shave time off from trips that people already intended to take. The time savings also compounded from all the new trips that people started taking given that travel was easier and so much faster.

Time-saving tools create new workflows

In engineering organizations, infrastructure teams (and sometimes product teams) spend resources on building better tools that save engineers time. When doing the cost-benefit analyses for these projects and determining whether they’re worth the effort, there’s sometimes a misconception that the value of a tool rests purely in how much time it saves from existing activities. The line of reasoning goes like this: something that reduces the time it takes to complete an activity that you do 3 times a day from 20 minutes to 10 minutes would save you half an hour per day.

While this may seem like a reasonable estimate, this analysis ignores two aspects:

1. When a tool gets faster, you end up using it more often in existing workflows.

2. Faster tools enable new workflows, sometimes unexpected ones, that previously weren’t possible.

These two effects compound the time savings of those tools. We can see this happen in a few different areas:

• Compilation times. When I first started at Google back in 2006, compiling C++ code for the Google Webserver could take upwards of 20 minutes or more, even with distributed compilation. ⁷ When code takes that long to compile, you consciously don’t compile very often and probably not more than a few times a day. You batch together larger chunks of code for the compiler to check so that you can fix more errors per development cycle. Since 2006, Google has made significant inroads into reducing compilation times for large programs, including some open source software that shortens compilation phases by 3-5x. ^{7 8}

  When compile times drop from 20 minutes to say 2 minutes, you save much more than just 18 minutes per previous compile. You also spend less time visually inspecting code for mistakes and errors and rely more heavily on the compiler to do it. Faster compile times facilitate new workflows around iterative development, as it’s conceptually simpler to iteratively reason about, write, and test smaller chunks of code. When compile times are fast enough, incremental compilation ⁹, where saving a file notifies a background task to automatically start recompiling code, lets you see compiler warnings and errors as you edit files and makes programming significantly more interactive than before.

• Search speed. Google reported that 500 milliseconds of additional latency in search results reduced the number of searches that people do by 20%. ^{10 11} Yahoo and Amazon similarly found that additional latency cost them traffic and sales. ^{12 13} These macroscopic experiments confirm that when search is faster, people search more. Conversely, when search is slow, like when you’re trying to search on your smartphone in an area with weak cell phone coverage, you’re much more hesitant to look up some piece of information.

  Faster search not only saves you time, but it also introduces new ways for you to interact with a search engine, compounding the time-saving benefits. Google Instant, for instance, saves users 2-5 seconds per search and also changes a user’s search paradigm, as Google explains:

  “The most obvious change is that you get to the right content much faster than before because you don’t have to finish typing your full search term… Another shift is that seeing results as you type helps you formulate a better search term by providing instant feedback. You can now adapt your search on the fly.” ¹⁴

• Deployment speed. Quora is the first place I’ve worked at that uses continuous deployment, where every code commit that passes a set of automated tests goes immediately into production. The team I worked with at Google released code weekly with a multi-day push process, and at Ooyala, we released code at most a few times a week, with the testing cycle for each release taking about a day. While somewhat nerve-racking initially, continuous deployment provides yet another example of how the time saved from the tool goes beyond the time saved during deployment (even though the ~10 minute push cycle is orders of magnitude faster than the push cycle at my previous companies).

  Continuous deployment completely changes engineering workflows. It lets you incrementally tweak code to validate different theories (for example, by changing a block of code in production that’s most likely the source of a performance bottleneck or of a bug and checking data right afterwards) instead of pre-planning a wide range of possibilities for the week’s deployment. It increases the likelihood that you will tackle data migrations that have to safely happen over multiple pushes because they don’t necessarily need to be multi-week endeavors ¹⁵. It also incentivizes you to fix more bugs because the fixes could go to production and be validated within minutes instead of days. As a result, there are days when the small team at Quora might deploy code 40 to 50 times. ¹⁶

Protect your most valuable resource – time

When mentoring younger software engineers, I often advise them to invest time in learning skills and tools that help to increase their iteration speed. In our rush to get things done, long-term investments that save time and improve our workflows sometimes get de-prioritized because they initially detract from our productivity. And yet, these investments often pay for themselves multiple times over. If the tools are ones that other engineers can use, like faster compilers and continuous deployment, their benefits even scale multiplicably with the size of the team.

Time is your most limited and critical resource, so it pays to be aware of tools and investments that save you time. To help inspire some ideas, here are a few more examples of tools that compound their time savings once you learn them:

• automation. A rule of thumb that I use is that once I’ve manually done a task three or more times, it’s time to start considering whether it might be worthwhile to automate it.

• text editor macros. In the Emacs text editor, for example, you can record a sequence of keystrokes and then replay them an arbitrary number of times. With practice, macros can make manual or programmatically tricky tasks nearly trivial.

• UNIX one-liners. Being able to manipulate and process data with basic UNIX tools instead of having to write a program can reduce the time to complete a task from minutes down to seconds. ¹⁷

• virtual assistants. Learning how and what to delegate to virtual assistants is hard, but entrepreneurs and engineers have found success in delegating customer support, email, research, phone calls, scheduling, and more.

• keyboard shortcuts. Each new keyboard shortcut might only save a second per operation, but mastery of multiple shortcuts compound together to save seconds or even minutes for complex operations.

• scripting languages. A little knowledge of Python, Ruby, or some other scripting language works wonders in comparison to compiled languages like C++ or Java when you do need to get something quick and dirty done.

Reflect on your daily workflows. What are some other areas where learning or building a tool might have time savings that can compound?

Thanks to Chen Xiao for reading a draft of this.