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:

  • When to Write a Brief

    Sometimes you should try to build the thing instead of writing about the thing. While I’m a staunch believer that writing is a super power (especially for remote teams), it can make small problems seem bigger than they actually are. Knowing when to reach for a brief can be difficult to pin down.

  • Moving Quickly Lowers Activation Energy

    Speed matters because it lowers the activation energy needed to start a task. If tasks feel quick, the perceived cost of doing it is lower and you are more likely to do it. Conversely, if tasks feel like a slog, you are much less likely to do it because the perceived cost will feel higher.

  • Speed X AI (Literature Notes)

    I read Speed x AI from Nfx. It says that founders need to move much faster or those leveraging generative AI will leave you in the dust.