How I build software quickly

Summary

How I build software quicklyby Evan Hahn, updated Jul 9, 2025 (originally posted Jul 8, 2025)Software is built under time and quality constraints. We want to write good code and have it done quickly.If you go too fast, your work is buggy and hard to maintain. If you go too slowly, nothing gets shipped. I have not mastered this tension, but I’ll share a few lessons I’ve learned.This post focuses on being a developer on a small team, maintaining software over multiple years. It doesn’t focus on creating quick prototypes. And this is only based on my own experience!“How good should this be?”Early in my career, I wanted all my code to be perfect: every function well-tested, every identifier elegantly named, every abstraction easily understood. And absolutely no bugs!But I learned a lesson that now seems obvious in hindsight: there isn’t one “right way” to build software.For example, if you’re making a game for a 24-hour game jam, you probably don’t want to prioritize clean code. That would be a waste of time! Who really cares if your code is elegant and bug-free?On the other hand, if you’re building a pacemaker device, a mistake could really hurt someone. Your work should be much better! I wouldn’t want to risk my life with someone’s spaghetti code!Most of my work has been somewhere in the middle. Some employers have aggressive deadlines where some bugs are acceptable, while other projects demand a higher quality bar with more relaxed schedules. Sussing this out has helped me determine where to invest my time. What is my team’s idea of “good enough”? What bugs are acceptable, if any? Where can I do a less-than-perfect job if it means getting things done sooner?In general, my personal rule of thumb is to aim for an 8 out of 10 score, delivered on time. The code is good and does its job. It has minor issues but nothing major. And it’s done on time! (To be clear, I aim for this. I don’t always hit it!) But again, it depends on the project—sometimes I want a perfect score e...