Perfectionism is a poor developer’s excuse for not getting the work done.

Larry Wall, in the glossary of the first edition of Programming Perl, famously notes:

We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris.

In the second edition of the book the terms are further defined:

Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don’t have to answer so many questions about it. Hence, the first great virtue of a programmer. Also hence, this book. See also impatience and hubris. (p.609)

Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don’t just react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great virtue of a programmer. See also laziness and hubris. (p.608)

Hubris: Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won’t want to say bad things about. Hence, the third great virtue of a programmer. See also laziness and impatience. (p.607)

While Perl is not everyone’s cup of tea, the ideas expressed in the above quote apply to programming in general. Very recently I assigned what I thought was an easy task to a relatively new developer, and gave him explicit guidelines to skip certain “best practices”. The task was performance sensitive, a background process that would receive a huge lump of XML from a webservice (that we didn’t control), transform the data, do a couple of simple checks and then store them in our database. The size of the XML data was huge and we expected it to get gigantic in the very near future, this thing needed to be fast. Really fast.

What he came up with, a week later, can only be described as an over-engineered piece of crap (honest assessment). It worked, flawlessly, for some smallish XML files I’ve given him to test the data transformations on, but when hooked up to the actual webservice it just couldn’t cope, stuff started crashing at random, as they typically do when a background process faces performance issues. When I reviewed his code I found out, to my horror, that he had completely ignored me, the code was full of… design patterns! Poor noob had beautifully scribed an almost academic example of the strategy pattern for what was essentially a smallish switch statement, amongst other things.

Now, don’t get me wrong, he applying patterns wasn’t the root cause of the performance issues we were facing, however he had spent all week trying to write the “best” code possible when he should have quickly hacked the code in a day or two, and then spend the rest of the time stress testing the damn thing and identifying bottlenecks. And now I had to dig through thousands of uneccessary lines of code to even start getting an idea what was going on. No chance of me wasting my time like that, just scrapped the whole thing and wrote it from scratch in a few hours.

I discussed his code with him, and my conclusions are:

• He had just discovered some of the concepts he applied, and was too eager to see them in action, and
• He, unknowingly, wanted to impress (not me, but the team in general).

Enthusiasm is great, rushing to apply concepts you might not yet fully understand in your code is not. Even if you do fully understand them, more often than not you don’t actually need them. One of the guiding principles of Extreme Programming is “You ain’t gonna need it” (YAGNI), and it’s a principle that I always try to pass to newer developers. Ron Jeffries, one of the founders of XP, explains:

Often you will be building some class and you’ll hear yourself saying “We’re going to need…”.

Resist that impulse, every time. Always implement things when you actually need them, never when you just foresee that you need them. Here’s why:

• Your thoughts have gone off track. You’re thinking about what the class might be, rather than what it must be. You were on a mission when you started building that class. Keep on that mission rather than let yourself be distracted for even a moment.
• Your time is precious. Hone your sense of progress to focus on the real task, not just on banging out code.
• You might not need it after all. If that happens, the time you spend implementing the method will be wasted; the time everyone else spends reading it will be wasted; the space it takes up will be wasted.
• You find that you need a getter for some instance variable. Fine, write it. Don’t write the setter because “we’re going to need it”. Don’t write getters for other instance variables because “we’re going to need them”.

The best way to implement code quickly is to implement less of it. The best way to have fewer bugs is to implement less code.

You’re not gonna need it!

Several of my answers on Programmers advocate for best practices, however I hope I haven’t mislead anyone into thinking that applying those best practices is a goal in itself. The goal is to get things done, done is better than perfect. Don’t just blindly follow dogma, without a deep understanding of the concepts and practices, and an itch to scratch you are just setting yourself for a world of trouble.

Keep it simple, stupid!

Further reading:

• Where do you draw the line for your perfectionism?
• The quest for perfection
• Why can’t perfectionists break the habit?
• The Done Manifesto
• Programming, Motherfucker

Write a prototype any way you want. If it’s working – it’s ok, leave it that way. If you want to show the code to anyone else – think what can be done better and refactor.

After some time you’ll write code the right way without even noticing it. Of course “the right way” depends on the company’s policies, language common code onvention, regulations, etc.

If you try to be perfect from the start, you’ll be progressing very slowly. You’ll ask yourself questions like:

• Maybe I could use a design pattern here?
• Are my functions too short or too long? Or maybe they are named the wrong way?
• Some other language specific silly question 🙂

It takes time (lines of code) to become proficient in any discipline. To be proficient in programming you have to solve problems. Writing 100 CRUD applications will teach you less than a few different complex applications.

Don’t forget that getting things done on time is more important than getting things done properly but late, or not accomplishing them at all but having all the code perfectly polished but unfinished.

Constantly improving the quality of the code you write is simply a given. You need to do it.

But keep it in context – you learn and apply new things in order to get a return on your investment, which may be raw productivity, reliability, future maintainability, or ANY other criteria you feel carries weight.

When I hear the word perfectionist, I generally think of someone whos main motivation is be perfect, not productive. Don’t be that person. You want utility from increasing your production. Let your efforts be driven by tangible and realistic payoff. Don’t get caught up in the “everything is worth learning” trap.

I’m still a newbie, but I’ll give my 2 cents:

I’m the kind of programmer that is perfectionist. I sometimes struggle days to find an elegant answer, and sometimes I don’t even find it. But that is because learning that kind of stuff is my focus. If it yours too, you may consider being a little perfectionist (but see below).

If your focus is completing something and then never use it again, don’t try to be fancy. Writing fancy code will help you if you need to use that code again. If you don’t, just get it to work.

Now, some tips I can give you:

-If you write the same functionality a lot of times, consider refactoring that functionality in a well structured, library for your own use. That way you can learn how to mantain something and will never need to rewrite that again.

-Be pragmatic to your objective. You want to learn? Good, write fancy code. You want to ship and mantain? Find a midterm.

-Have ONE focus at a time. Don’t try to learn, ship and teach, for instance, at the same time. One can do only one thing at a time.

-If you got the time, read a lot. Sometimes that help you have an insight in some particular problem.

Hope I helped in something 🙂

If we made a pattern out of this problem of learning to code, it would be affected by many forces including:

• Practice makes permanent.
• To do is to understand.
• People have uni-tasking brains.

You do not want to do something in the wrong way repeatedly, because that will become your habit for the future. However, you do want to do something and if perfectionism leaves you paralyzed, you may want to risk some mistakes.

There are probably some parallels to the way kids are being taught to write these days. They are encouraged to write, ignoring spelling but putting great emphasis on letting their creativity flow. I cringe when I see this kind of work product on elementary school bulletin boards, but I think that the method has merit if there is a follow up step (probably the same day or at least week), where with a dictionary or advice from a teacher, they look up spelling and perhaps drill on a rule like i after e except after C so they have a way to avoid typing “recieved”.

Because programming is so complex, new programmers have a hard time keeping all the rules for programming in their heads at the same time. There is not much to be done about it except perhaps better tools and better tutorials. Balanced and great training is a complex undertaking. Just as someone doing weight training or other kinds of sport training would not think of training for strength of one body part alone or training for strength only without some work on flexibility, speed, endurance, or balance.

Your training should include short programs, medium programs, long programs, programs where you retype someone else’s program (kinematic learning), something where you start with some code and change it to do something new, or a program where you create code from a word problem (this happens a lot in teaching math). Something where you see things represented as text and as figures, something that focuses on a few statements, somethings with a broad mix of statement types. You should see something that does all the work directly and something that does almost all the work through APIs.

Enemy

Perfectionism is everyone’s enemy, by definition. It’s (according to Wikipedia)

a personality disposition characterized by an individual striving for
flawlessness and setting excessively high performance standards

Nearly every decision you make is a tradeoff.

• Execution time vs development time: “do I write this in C or Ruby?”
• Simplicity vs flexibility: “Do I write a query for MySQL, or an abstract querying tool that can support multiple databases?”
• Ease of creation vs ease of maintenance: “Do I write a throwaway script with no comments or a well-documented library?”
• All of the above vs. finishing the task quickly

If your standards are too high in one area, you’re probably neglecting another.

If you write a fast, readable, flexible, easy-to-maintain, well-documented, well-tested piece of code, but it takes you 3 times longer than it should based on the importance of the task, that’s not perfect, is it?

Think about this: temporary fixes / lines-of-code lasts often longer than expected if not forever …

The most important thing is to really grok the fundamental design principles like KISS, DRY, SRP, LSP. You need to get the ability to see where these rules are broken, and why it matters. Once you can really recognize “rule violations”, it’s okay to write sloppy code in certain situations (e.g. throw away code for migrations), because then you know the pitfalls, and how to clean up the mess when you must.