Every passionate programmer cares, first and foremost, about her code. Code is our canvas. Although no user will ever look at our code, the passionate programmer labors over every line. Even when we know, full well, we’re building a small app for a small audience, a lot of us still care that our applications will perform under the biggest of stages. We care about how our code might perform under the most severe of conditions. We make attempts to reduce excess calls to the server, to the service, and to the database.

And yet, to survive in this industry, we better not be perfectionists. There is no such thing as a perfect piece of software, especially web-based software. Our products live through our users. They morph as our user base grows. Features beget new features. Bugs beget new bugs. Trying to be perfect can become exhausting.

The approach a developer took the first day she wrote her first line of code is likely completely different from the approach she’s taking today. Software changes over time. We build, tweak, iterate, and occasionally have to rewrite. So, we’d better be OK with that.

In development, there are often trade-offs between performance and coding simplicity or between perfect architecture and maintainability. There is no silver bullet to determine which way is necessarily the right way.

A great software developer is obsessive-compulsive yet accepts imperfection all the time. Trying to write “perfect code” is crippling. The quicker we can accept imperfection, the more motivated we’ll be to keep moving forward with our work, and the more work we’ll actually get done.