I am probably not the only one that feel that way. But I have what I tend to call "The syndrome of the perfect programmer" which many might say is the same as being perfectionist but in this case it's in the domain of programming. However, the domain of programming is a bit problematic for such a syndrome.

Have you ever felt that when you are programming you're not confident or never confident enought that your code is clean and good code that follows most of the best practices ? There so many rules to follow that I feel like being overwhelmed somehow. Not that I don't like to follow the rules of course I am a programmer and I love programming, I see this as an art and I must follow the rules. But I love it too, I mean I want and I love to follow the rules in order to have a good feeling of what im doing is going the right way.. but I only wish I could have everything a bit more in "control" regarding best practices and good code.

Maybe it's a lack of organization? Maybe it's a lack of experience? Maybe a lack of practice? Maybe it's a lack of something else someone could point out? Is there any way to get rid of that syndrome somehow ?

  • 1
    This question can only be answered knowing a bit more about your personal background, although that might quickly make it too localized. The Tao Of Programming might be a good place for you to start.
    – back2dos
    Commented Jun 26, 2012 at 13:03
  • I doesn't agree there.. i believe everyone whatever the background can feel this way maybe at some different degrees but still.
    – Rushino
    Commented Jun 26, 2012 at 13:12
  • 2
    While everyone can experience the same symptoms, the cause varies a lot in fact, and thus does the "cure".
    – back2dos
    Commented Jun 26, 2012 at 13:20
  • There is no perfect programmer. You may find experienced and detail oriented one which has momentum and desire in improving his/her skills. - you may call them "go Getters"...
    – Yusubov
    Commented Jun 26, 2012 at 13:37
  • "I must follow the rules"... and there's your problem. "Best practices" arent rules, they're suggestions based on collective experience. If you are treating them as unbreakable rules, I can see the root of your stress. Commented Jun 26, 2012 at 21:04

8 Answers 8


Prioritize. First things first. Focus on what matters.

Your priorities may vary, but in general you should care about:

  • Correct code
  • Maintainable code
  • Clean code
  • Simple, elegant code
  • Efficient code

Maybe in that order. However, the first point is the most important. Without it, code is useless. What do you do with a program which doesn't work correctly?

Make it work, everything else is near irrelevant for solving the problems you need to solve. Of course, I too suffer from this. What I've learned that helps is to just focus on solutions which work. That is enough. That is 99 % of the job.

You might want to think about something like good code. What is it? What kind of people write it? How to write good code? It's very simple. Write code that works. Working code is good code. Everything else comes later.

Of course, when writing code in professional, team environment, obvious, readable code and maintainable code become increasingly important. However, still the first task is to make it work, and focus on that. Only then you can start refining and refactoring for better - if needed.

It is often quite obvious that code correctness is very important - yet we all fail to embrace it's importance when writing code. We cut corners, we use premature optimization, we try to write elegant code even before we have working code written. It's the human nature to strive for perfection from the very beginning, but programming and software development are iterative processes, and priorities exist. Thus, again, make it work, worry about everything else later. Understand the importance of correct code and strive for it.

While there are tons and tons of so-called good practices, I think common sense is the most important, think about why the practices are considered good, when and where to apply them. Don't strive to meet every single bit of the good practices though. There is no replacement or substitute for personal experience. You can't avoid common pitfalls - no matter how many books you read, seminars you attend or whatnot. What matters is learning by doing, doing things correctly and having fun - whenever it's possible.

  • 9
    The best optimization is the one that bring your program from non working state to working state.
    – deadalnix
    Commented Jun 26, 2012 at 13:05
  • 1
    @deadalnix Perfect advice! It's so simple, so obvious, yet so true in all code.
    – zxcdw
    Commented Jun 26, 2012 at 13:08
  • 7
    +1. I'd consider putting maintainable above correct. After all one quality of maintainable code is that making it correct is a matter of reasonable effort ;)
    – back2dos
    Commented Jun 26, 2012 at 13:21
  • 1
    EFficient should be above everything but correct if you are talking about database code and way above elegant. Good sql code (good for the datbase that is not the developer)is rarely elegant. There are known inefficient ways to do things and they are not less maintainable or harder to understand once you start using them on a regular basis.
    – HLGEM
    Commented Jun 26, 2012 at 13:27
  • 2
    @HLGEM Indeed, in specific fields the priorities might be completely reversed. For example at times I write and reverse-engineer assembly code which has been written under extreme size and speed constraints(demoscene products). In such situations, even program correctness might be questioned - many malfunctioning pieces of code have turned out to work extremely well(beautiful visual and audio artifacts based on incorrect code, for example).
    – zxcdw
    Commented Jun 26, 2012 at 13:38

The simplest way to avoid this problem is to only change what hurts. Do not polish code that is correct, readable and maintainable, even if you think that some changes might make it even better. But once you are e.g. trying to change something and stuble over a variable of which the purpose is unclear, or a function that is just too long to comprehend, fix it. Not sooner.

That doesn't mean that you shouldn't strive for good, clean code in the first place, of course you should, but you should consider your first attempt "good enough" unless proven otherwise.

  • +1 i like the part.. "your first attempt "good enough" unless proven otherwise."
    – Rushino
    Commented Jun 26, 2012 at 13:46
  • Seconded and upvoted. Definitely golden advice!
    – zxcdw
    Commented Jun 26, 2012 at 14:33

I think the best antidote to this is to remind yourself that all those best practices and code cleanliness rules don't exist for their own sake, nor does the code itself.

In the end, what matters more than anything else is that the software works and can be used. And that won't happen if you don't finish it.

I don't like the comparison of coding to art, but in this regard it works: artists (especially authors) also often want to keep working on a piece because there's always something that's not perfect. But what value is there in perfection when it delays publication indefinitely and thus prevents anyone from appreciating the work?


The most important thing to realize is your code is always going to change, and there is always room for improvement. No code is ever perfect. More often than not, a class library you work on today will be very different six months down the road. You learn some new technique, or find a pattern that really works for you. As long as the code is easily maintainable and readable then you should be good. Ideally you would have unit tests to make it easier to refactor later down the road.

It is easy to get caught up in making the code look perfect and follow every standard you can think of. It happens to all of us. Looking at code I have written a couple of weeks ago causes me to think about making changes. Add a property here, refactor the method there. And it seems to happen at the end of the project. But if you get too wrapped up in that you could end up making a showstopping bug. I've done that a couple of times early in my career. A couple of 3 AM bug fixing sessions cured me of that problem.


Do it other way around.

Instead of "what can be done better?" seek for "what pisses me off?" till nothing does.

  • 4
    "A book is finished not when nothing more can be added, but when nothing can be removed from it." - Code Complete
    – Jonathan
    Commented Jun 26, 2012 at 14:01
  • It's actually a paraphrase from Saint-Exupéry, funny how he may hold less credibility then Code Complete here.
    – scrwtp
    Commented Jun 27, 2012 at 0:46

As a programmer, your job is to produce code. The purpose of best practices is to increase your production rate by making things easier to understand/do/remember. If adhering to these practices is getting in the way of actually getting things done, you're doing something wrong. Simply try to produce code as fast as you can, and your practices should evolve to let you do just that.

  • I disagree. As a programmer, your job is to solve problems. Too many programmers look at a problem and say "I can code a solution to that", and don't look around for solutions that already exist. The best solution is the one you don't have to write. That said, as a programmer who must code the solution, your job is to meet the requirements. Best practices exist to make sure that the code that meets the requirements can be easily changed when the requirements change (not if, but when).
    – KeithS
    Commented Jul 2, 2012 at 15:01

Make it work, make it clean, make it SOLID, make it performant.

The first three are an adage I espouse whenever anyone is wondering how to write SOLID code on a timeline. When you first write a line of code, it simply has to work, so do what you have to do and don't get fancy. The first time you revisit a line of code, it's no longer a one-off and you should clean up the code, making it readable and thus more maintainable. The third time your cursor goes in that line, it's probably kind of a big deal now, and you should refactor it to adhere to the SOLID methodology, abstracting dependencies, implementing patterns, and generally making the code easier to plug in or be plugged into for future enhancement.

Elegance in code is to be achieved where the programmer notices an opportunity, and is generally a function of simplifying, cleaning and generally improving the readability and maintainability of code while following the previous steps. It is not something to be maximized.

Performant code is almost always the least concern in memory-managed languages (Java, the .NET family, most functional languages, etc). In these environments, the goal is to write correct code ("correct" here defined as producing the expected result in all expected cases, and being understandable and well-structured, and thus maintainable), and performance is secondary (usually it will proceed to some degree from correct code). In all cases, an algorithm is performant when it's "good enough". Remember, "premature optimization is the root of all evil"; making optimizations that you don't know you will need does little more than waste time, obfuscate code, and generally prevent progress. It has to work first, then once it works, you run it and see how fast it runs. If it's not fast enough (as defined by some benchmark that is a published requirement), you improve it until it is, and then you stop.


You really need to be pragmatic about programming. Yes, we all like to do things right, but you get paid for delivering working software, not for polishing it for the rest of your life.

The approach to take is to "get it done" in your professional life. Deliver and move on. Save your perfectionism for personal projects.

  • I understand but we can't consider this "black or white" i believe.
    – Rushino
    Commented Jun 26, 2012 at 15:46

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