Tightening the Feedback Loop

A typical programmer’s workflow looks like this:

1. Edit code.
2. Compile code (if you’re using a compiled language like Rust or C++).
3. Run code / tests.

Step 3 helps you find errors during the development process, and it’s useful to run it often. However, it can be quite distracting to leave your editor, run some commands in a terminal (or your IDE), and then return to the editor again.

Here are some tips on how to automate steps 2 and 3:

Use an editor plugin

Regardless of what editor you’re using (Vim / Emacs / VSCode etc.), there probably exists a plugin for the language that you’re using. These can often give you feedback directly next to the source file that you’re editing, whether it be syntax errors or style violations.

Editors like Vim also provide hooks that are triggered when a file is saved, which allows running arbitrary commands at the end of a save.

Use a test runner

Test runners (like Jest, for example) can re-run tests automatically when a source file changes. This can be quite nifty when you’re debugging a broken test. All you need to do is edit the code and you get instant feedback on whether it fixed the test or not.

Use entr

Entr provides a general mechanism to run a command (or multiple commands) when the contents of certain watched files change. This can be used to create tiny REPL-like environments for any language / editor combination.

For example, if you are editing some Rust code, you can leave the following command running in a terminal:

ls *.rs | entr -c -s 'rustc *.rs -o out && ./out'

and it will show you any compilation errors instantly when you save a file. If the files compile correctly, it will show you the output.