Discussion on: Perfectionism as a Programmer

It's a great question, and a topic that I've dealt with a lot myself.

First of all, yes, there are definitely benefits to striving for perfection in software development. I've seen and written a lot of good and bad code; the difference is often noticable right from the start, and as time goes on the gap between excellent and mediocre code, or rather between devs who care to keep their code at high quality and those who don't, grows exponentially.

However, and this is a big however - perfectionism brings with it many troubles, in many things in life but even more so in web development.
As @ben said, it's more about balance than striving for perfection or continuously cutting edges.

Here are two bits of wisdom that I've picked up from others regarding this topic:

Your code will never be perfect

It's a harsh truth, but a truth nonetheless, and personally it took my quite a while to accept this.
If you're writing a single function or practicing a small task, you could reach, after enough refinements, a point where you would consider your creation "perfect".
However, doing this for all code in an actual project would be impossible, as every small refinement typically requires an ever increasing set of additional changes. That's not to say you shouldn't refactor code once changes are due (it's very important!), but overdoing it will hurt you. I haven't found a good rule of thumb as of yet for where this balance lies, and I think it's mostly acquired through experience.

Instead of specific micro-refinements, I've found that practicing the standard ways to write clean and good code in a particular language and in general will allow you to write great code quickly and naturally, after enough practice. A good example is learning to use higher-order array functions in JavaScript effectively.

And the second, related insight:

Software development is a process

That is to say, you can't really ever "complete" a software development project up to perfection, unless it's really small or it's scope is defined down to the smallest details. There will always be room for further refinements and new features, because writing software is not a finite set of tasks - but rather a virtually infinite process. It sounds like a weird way to reason about it, but actually I've found it to be the best way to reach other valuable insights:

For example, because it's all an "infinite process" and not a finite amount of tasks, you can't really create a perfect frontend before turning to work on the backend - it would take an "infinite amount" of time to refine it to perfection. Instead, it would be better to work in stages: create the core of the frontend and the backend, then work on another set of features for both, then work on smaller improvements, etc.
At some point you'll run out of time or will want to move to a different project - and working in stages as I've mentioned is the best way to use your time on a given project most efficiently (at least from my experience).

If you look back on the previous two paragraphs, you'll see that using the "process" mindset, I was able to give a solid, fundamental motivation for a common practice that people use to increase productivity (I am by no means the first to suggest the methodology, of course). That is the main benefit of the mindset I suggested above - many other common best practices follow easily from it.

These are my bits of wisdom. Others may have different or additional ideas to suggest - and I'd love to head them!