Possible Duplicate:
Where do you draw the line for your perfectionism?

I see that the development community is very focused on doing things the right way and personally I would like to do the same too, however, is it a good or bad idea for a newbie to focus on design principles, design patterns, and commenting code when getting started, or is it better to let creativity run wild and potentially write sloppy code. Where should a newbie draw the line?

  • I also have a more personal and subjective question pertaining to this. I'm in graduate school for computer science, however, I still feel like a newbie and have done little development. Is it a good or bad idea to post code under my real name since employers may eventually see it, or should I continue to post code as my alias until I am comfortable with my skills? I'm not sure if it's better to have a history of a lot of code or to only show good code once I have some.
    – Akromyk
    Commented Oct 20, 2012 at 21:55
  • 3
    I have been working as a programmer for over ten years (and playing with da kodez for much longer), and I'm still learning. You will never reach a point that the code you write can't be improved in some way.
    – user
    Commented Oct 20, 2012 at 21:59
  • Commenting your code as a best practice is often a junior mistake, comment's aren't bad per se so much as most agree good commenting is hard and amount of comments as good is a very controversial topic. Don't assume more comments = better and read steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html Commented Oct 21, 2012 at 2:44
  • Design principles, design patterns, commenting code, etc. mean no perfectionism. They are just the tools of the trade. Commented Oct 21, 2012 at 5:05

8 Answers 8


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:

  • 1
    But see also the "spike" (extremeprogramming.org/rules/spike.html), a programming written possibly not to best practices, which purpose is to learn more about the problem or solution domain, and which is not intended to be kept. Commented Oct 21, 2012 at 11:09
  • +1 hesitantly, you are spot on throughout this but I have seen practically identical spiels come as explanations of pure unreadable unmaintainable abominations which performed for garbage because "premature optimization is the root of all evil". It's interesting how dangerous good advice is in the wrong hands, but your answer is good advice all the same Commented Oct 21, 2012 at 18:21

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.

  • No, getting things done on time without it being done properly is the PROBLEM. If something needs to take longer to be done properly, then you need to plan for it. Commented Oct 26, 2012 at 7:49
  • 1
    It's only valid in a perfect world, where no deadlines with fines are present. Try to convince your supervisor that your company has to lose a lot of money because you don't like how some things are implemented. There's time to fix things later (if not, then THERE's the issue), but having them on time is usually the most important thing. Commented Oct 26, 2012 at 11:21

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.



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 ...

  • Couldn't agree more :) Commented Oct 21, 2012 at 9:18

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.