Improving Your Iteration Speed

I’ve been reading The Effective Engineer by Edmond Lau and finished a chapter which I found very interesting. The chapter is titled Invest in Iteration Speed and the crux of the content is that effective engineers take the time to reflect on their iteration speed and how to improve it while working on problems or projects.

By iteration speed, we can mean any process which exhibits a cyclical nature in our work and speed at which we complete each cycle. Some processes can contain many steps and can take up more time than we like for each iteration which slows down our progress. Other processes are very streamlined and complete very quickly which allows us to complete each cycle, improve, and repeat at a more rapid pace.

As an example, let’s say that you’re debugging an issue in your code where you receive a request, do some processing with the request’s data, and return a response. But the response your code returns is not what you expect and you need to figure out what’s causing this issue. To debug this issue, you may have the code running locally and you manually send it requests.

You may be tempted to use requests which mirror what you would see in production, but if the request contains a lot of data it can be difficult to parse through everything in the return as you debug. Instead, you can simply choose to send a request containing the smallest amount of data possible so that it’s easier to see what’s being returned. Reducing the amount of data to parse and understand can dramatically improve how quickly you iterate on solving a problem.

Another example could be some new features that you’re writing for a project and you’ve already written some tests to verify the behavior of your code. You may be tempted to code for several hours and have everything written out before running your tests or even any linting programs on your code to check your syntax. This can create issues if you have a bunch of failing tests or lint errors and you now have to overhaul a lot of code.

Instead, you could have a process in which you write a small piece of your planned changes and then run your linting program to check your syntax. If it all looks good, write the next small set of changes and repeat. By the time you’re ready to run your tests, you’ll likely have caught a good number of issues with your changes and fixed them!

In improving my iteration speed, I’ve found one tool to be especially helpful: watchexec. This tool can be used to automatically run other programs or commands once any changes have been made to a file which can greatly speed up your workflow! As an example, here’s how I use watchexec in my work.

At DigitalOcean, I mostly work in Go which is a compiled language. The codebase for my team has a Makefile which specifies commands we can execute to run other programs. If I want to properly format my newly written code, I can run make gofmt and if I want to lint my code I run make analyze. To use these with watchexec, I cd into the root directory of our codebase on the git branch I’m working on and run the following:
watchexec --exts go ‘clear; make gofmt; make analyze’

This sets up watchexec to watch any files that end with the extension .go and if any of the files are changed it will run clear; make gofmt; make analyze which will clear the terminal screen, run my formatting program, and lint my code. With this, I’ll typically work on my code in one terminal tab and once I’ve saved my changes I’ll flip over to a second tab running watchexec which will already have formatted my code and checked my syntax. Pretty neat and efficient!

I can even further and have another terminal tab open to run a separate watchexec program that will rerun my tests after any changes are saved. The command to do this in Go is the following:
watchexec --exts go ‘clear; go test -v -count=1 -run=TestFunctionName ./relative_path_to_test_file

With that setup, I now have my code formatted, linted, and tested automatically with each save made to a file. Now we’re zipping!

There are many other ways to improve your iteration speed and a fantastic way to level up as a software engineer is to figure out how you can improve on it. It’ll vary depending on the work you’re doing and what processes you have to follow for a project or team, but there are always opportunities to improve your effectiveness. A couple of suggestions include:

* Using Docker to run local instances of your programs for testing and debugging
* Having a checklist of all the steps you should complete before submitting a PR for review
* Finding or building tools which save you time over the long run, even if they take some time to get set up -> even better if you can get other teammates to use the tool
* Setting up small experiments to test your program’s performance after a set of changes to verify a performance improvement or spot a regression

Next time you’re about to start a new piece of work and feel the urge to dive right into coding a solution or new feature, I encourage you to instead take a moment and consider what processes you’ll be executing and what your iteration speed will be like. Then contemplate how you can improve that iteration speed so that you can more efficiently complete your work. You may notice a whole bunch of things you can do that’ll make you a more high performing engineer.