How to Write Software Fast

There is a noticeable difference between the speed of the most productive software engineers I’ve worked with and the slowest. What do they do that others don’t? Is it possible to learn how to be faster?

Speed is easy to dismiss as unimportant for knowledge work (thinking is often the limiting factor), but that we can’t go faster or trying to wouldn’t be valuable.

Reduce friction to thinking

Software engineering is often a ‘shots on goal’ endeavor—the more attempts you can make in the same amount of time, the more progress you will make.

It should be easy to write some code and run it. How much friction exists in your setup that makes it difficult to run code? Tiny pieces of automation and muscle memory play a factor (e.g. checkout branch, open a file, execute just the code you are working on, stubbing out data, etc.).

Reps not years of experience

Solving problems quickly benefits from having seen and solved many problems, but don’t conflate ‘seen many things’ as ‘number of years of experience’. You’ve probably worked with people that have decades of experience that are below average in productivity.

The way to get experience is to build many things. I don’t know of any shortcuts to learning by doing other than to have side projects and really try to build them out.

Be decisive

When faced with a new problem, you can cut down on time by doing a quick breadth-first search (what solutions are available) then being decisive about a path to go down. So much time is lost by not being decisive.

Execute quickly and leverage your tools

Here’s where being in the top percentile of proficiency in your local development environment and programming language pays off. Code is very easy to change and you don’t need to be perfect until you hit production. Being really fast at expressing the solution will help you iterate through each sub problem quickly. The ability to think through code looks effortless from the outside because the distance between what’s in your head and what gets implemented is so small.

A good heuristic for when you’ve reached this kind of proficiency is when others comment about feeling nauseous watching you code.

See also: