# How to code 10x faster than an average programmer By [Optimized by Otto](https://paragraph.com/@otto) · 2023-01-29 --- ![](https://storage.googleapis.com/papyrus_images/1f448aaeb828d368e8f3fb5ece675ed4.jpg) What is the key to being an efficient programmer? Well, the answer is surprisingly simple. Having a setup where you can write and test your code over and over in an uninterrupted flow will dramatically increase your productivity. The cost of doing _just one more tweak_ to make the code perfect should be as close to zero as possible. The developer should not feel any drain when doing _just one more test_ to ensure everything is absolutely correct. The experience should be fast and frictionless. Instant run, change, re-run cycle --------------------------------- I always try to set up my development environment in a way that I can write **code in one window, and _immediately_ see the result in another**. It does not matter if I am doing front-end or back-end development – I insist on having the code in one window and the result update in another window as soon as I press _Ctrl+S_ or switch focus between windows. ![Atom/Pulsar autosave and Entr in action](https://substack-post-media.s3.amazonaws.com/public/images/d2a25f44-a618-4e9d-920f-368b9a5e6250_1200x615.gif "Atom/Pulsar autosave and Entr in action") I achieve this with a combination of two great developer tools: * The Atom [Pulsar code editor](https://optimizedbyotto.com/post/pulsar-best-text-file-and-code-editor/) with [autosave](https://github.com/atom/autosave) to automatically save code files. * The [Entr command-line tool](https://eradman.com/entrproject/) to restart programs automatically when files change. The basic usage of Entr is to list all files in your coding project with [find](https://manpages.debian.org/unstable/findutils/find.1.en.html) and pipe the list to [entr](https://manpages.debian.org/unstable/entr/entr.1.en.html) telling it what command to run when any of the files are updated: shell Copy `find * | entr python3 demo.py` `find * | entr python3 demo.py` If you are working on a long-running process which does not exit on every run, such as a server app, you might want to use the `-r` and `-z` parameters to make Entr restart the program: shell Copy `find * | entr -rz node server.js` `find * | entr -rz node server.js` Occasionally the workflow might need two commands, such as in this example compiling and running a demo program in C. That can be achieved with the `-s` parameter along with the commands as one quoted string: shell Copy `find * | entr -s "gcc demo.c -o demo; ./demo"` `find * | entr -s "gcc demo.c -o demo; ./demo"` ![Atom/Pulsar autosave and Entr in action with GCC compilation and execution](https://substack-post-media.s3.amazonaws.com/public/images/ca0dabda-c4da-4808-ad6a-118c076ad411_1200x615.gif "Atom/Pulsar autosave and Entr in action with GCC compilation and execution") But what if the full development cycle includes uploading the files to a remote server? No problem, Entr and Rsync can handle that as well, and with the addition of ts you will also see the timestamps of when Rsync last ran. shell Copy `find * | entr rsync -avz --delete-after * example.com:/path-to-target-dir/ | ts` `find * | entr rsync -avz --delete-after * example.com:/path-to-target-dir/ | ts` Browser window auto-reload -------------------------- The same principle applies to all development workflows, not just command-line stuff. For example this very blog is written in Markdown and is converted to static HTML pages with [Hugo](https://gohugo.io/), which has a built-in command `hugo server` that serves the pages locally and automatically reloads pages thanks to [livereload.js](https://www.npmjs.com/package/livereload-js). ![Atom/Pulsar autosave and Entr in action with GCC compilation and execution](https://substack-post-media.s3.amazonaws.com/public/images/026d6bf9-0eb2-408b-8558-3b0d6dbc4a81_1200x615.gif "Atom/Pulsar autosave and Entr in action with GCC compilation and execution") Real-time feedback from code editor ----------------------------------- While optimizing the _code-change-compile-run cycle_ is the key to productivity, additional gains can also be achieved when the code editor gives real-time visual clues of what is going on and what might be an issue. The screenshot below shows how the [GCC linter in Atom Pulsar](https://github.com/AtomLinter/linter-gcc) adds a red dot to the line with an issue, and underlines the exact section on the line. A popup shows in-context information when the cursor is in the problematic function call. In the same screenshot, note also how nicely Atom Pulsar shows (with a yellow hint) the filename that has uncommitted changes, and inside the file we can see the lines that have changed. The dark grey communicates that a file is excluded from git tracking with `.gitignore` (in this case the _demo_ binary, as we only want to have source code in git). ![Atom/Pulsar git and linter integrations in action](https://substack-post-media.s3.amazonaws.com/public/images/fa298369-b22d-4c0c-9561-cfdaef92505e_894x558.png "Atom/Pulsar git and linter integrations in action") In Atom [Pulsar](https://optimizedbyotto.com/post/pulsar-best-text-file-and-code-editor/) I have linters for all the programming languages I use, and also [Shellcheck](https://www.shellcheck.net/) for bash scripts and [yamllint](https://yamllint.readthedocs.io/) for configuration files. What sets some programmers apart -------------------------------- During my career in software engineering, I’ve noticed that some coders simply have an instinct for what is _too slow_. While most people keep on grinding on the path they set on when trying to solve a problem, the more passionate programmers feel frustrated if their progress is too slow. An effective programmer will switch to optimize the speed of their progress – and only once they are happy with their velocity they will switch back to solve the original problem. This means they are eventually much faster at it and all future similar problems. Smart programmers have a great sense of when it is appropriate to stop the process, improve tooling, and then have the process run much faster. Next time you catch yourself wasting time on doing something repetitive and slow, stop and ask yourself why you are doing it. A good programmer will always raise the bar for what they consider acceptable development velocity. --- *Originally published on [Optimized by Otto](https://paragraph.com/@otto/how-to-code-10x-faster-than-an-average-programmer)*