Perfectionism in Programming- Root cause for all my procrastination!

A close friend of mine once told me, I am more of a perfectionist. Probably that's where this thought process of perfectionism came up. Trying to do something perfect is normal, it is also beneficial. But perfectionism can lead to procrastination. The burden of responsibility for the quality of implementation is so pressing that it is easier to postpone the performance altogether.

I always wanted to be best at the things I do, or things I decide to put my efforts on. It can be requiring myself to be the best at the sport I play or winning a simple game of Monopoly. Sometimes winning a point is not enough. I could have won a point or may be it was just lucky the opponent made a mistake. But this small yet insightful comment from my friend made me realize that I do have a similar mindset for most of the things in life including programming. And lets not forget about this article, it needs to be best as well, as my practice I always 'try' to get things right the first time. Needless to say this blog has been a long time in the making.

While I was learning to code, perfectionism did take different forms. It can be over planning, sometimes it can also be over preparing. Well all of us know that the best way (or the only way) to learn a new programming language or framework is to just go ahead and use it. We can absorb lots of theoretical knowledge, but it will fade away quickly if we don’t use it in real projects.

On the other hand, we can't just do any projects without any prior knowledge of the language. So what do we do? we start a course of course!?

And after the course and that certificate successfully shared across our LinkedIn network we do feel happy and energized - we did learn a lot. And it's time we start using it.

But...

We rarely feel prepared. One course does not appear to be sufficient to comprehend such complex concepts. So we begin a new course. And the next one.

Always preparing and never starting has been happening a lot to me, I kind of found myself spending two months on four courses about RTOS frame work which I have never used. Obviously, I forgot everything and the framework itself faded away now. But this kind of over preparing is common for people who code I guess.

But we’ll never be completely prepared. As with everything in life, you have to start before you’re ready. That’s the only way to go. Fear of failure kills our dreams much more often than doing imperfect things ( philosopher in me :) )

Now let's get into the voices I fight inside my head on everyday basis,

int Calculator (int x, int y, int Operation){


if(Operation==1){
? ? // adding two numbers
? ? ? ? return x + y;}
? ? // subtracting two numbers
else if (Operation==2){
? ? ? ? return x - y;}
else if (Operation==3){
? ? ? ? return x * y;}
}        

I would see many imperfections in this code and would feel the urge to ‘fix’ all the code’s imperfections. Inconsistent spaces, braces, new lines and capitalization. I think the problem starts when I see a piece of code, I almost look at it as a painting.

I would shuffle around my code to make it symmetrical, balanced and simplistic just to ensure the code looks its best.

For me, the code must paint the perfect picture when other people eventually read it. So for me the day would end more peacefully when I re-write the above simple code in following way:

/* Function to add, subtract or multiply two numbers
*? Input:
*? ? ? ?x - Number one
*? ? ? ?y - Number two
*? ? ? ?operation - 1 for addition,?
*? ? ? ? ? ? ? ? ? ?2 for subtracting,
*? ? ? ? ? ? ? ? ? ?3 for multiplication
*/? ? ? ?
int calculate (int x, int y, int operation)
{
? ? if(operation == 1)? ? ? ? ? // Adding two numbers
? ? {
? ? ? ? return x + y;
? ? }
? ? else if (operation == 2)? ? // Subtracting two numbers
? ? {
? ? ? ? return x - y;
? ? }
? ? else if (operation == 3)? ? // Multiplying two numbers
? ? {
? ? ? ? return x * y;
? ? }
? ? else? ? ? ? ? ? ? ? ? ? ? ? // Handle error case
? ? {
? ? ? ? printf("\n\r [Error] Operation not supported.");
? ? ? ? return 0;
? ? }
}        

This is of course a really small and isolated example since the code does the same thing and performs no different in both the scenarios. Some of you might might even have a different perspective on how ‘perfect’ code looks like.?

Maybe some people didn’t even see a difference in the two pieces of code. This can be frustrating when you work in a project with many different programmers that all have their own coding style. Perfectionists could feel other programmers were lazy and didn’t do a good enough job. This obviously does not have to be the case.

So first lemme argue for myself and the perfectionist voice inside my head here...

It actually becomes more evident when reviewing code or when your code is being reviewed. Naming is of course very personal and is very much up to debate. I often feel that the naming of variables and methods and the layout of the code always has room for improvement. However, I feel that a piece of code can be improved significantly by making the code look more ‘elegant’, which will make the code more readable. I believe readability is important because code is more often read than written.?

Removing those trailing white-spaces and adding blank lines to separate logical blocks of code are those small extra efforts which will make it easier to understand for the reviewer and the programmers that will inevitably read the code later.

And come on this actually translates your programming into writing high-quality code. Not just writing code that works, but code that is maintainable and follows best practices. See spending a couple of hours outside work hours to apply the finishing touches to a solution actually gives you that 'Chef's kiss' moment looking at your code. (Maybe failing a couple of deadlines will teach you that this is a myth in programming).

By continuously perfecting the solution, the solution will never be done. And there is always be something to improve. There comes a point where the programmer should move on to the next feature, or to be realistic move on to that one escalation you have been keeping in backlog and investing time on the code which already works.?

So where do you draw the line here??

I actually asked a colleague of mine, and his answer needs to be quoted here!

"The amount of time you spend on writing a perfect code is directly proportional to the salary you get paid for" - I mean end of the day this is exactly the ultimate benchmark of code quality.

Yeah people will argue on the ethics and values of the above statement, but lets be honest here. I mean we developers work on the one realistic motto - "if it works don't touch it". So I can go ahead and end my article saying, there is nothing to deal with. While being perfectionistic might at times be a burden because of the constant self analyzing, its a true gift. It allows you to be sure that you won’t get stuck in one place in your life.

But this is coming from a recovering perfectionist, perfectionism is not a character flaw - it's a habit. We pick it up because we have been taught it's a virtue, but look at it. It has less to do with excellence and more to do with insecurity.

So there is a fine line between perfection and obsessive-compulsive disorder and it is important to understand where the line is. Large and complex software systems are never really "done", so it is important to respect the business’s definition (what you are paid for) of "done” and move on.

By all means, I?don’t?want you to ship crappy code. But I do want you to remember that you have a choice – and more often than not, settling for?good enough?is a valid choice to make in a tech world that values shipping above all else.