Complete code

Easy way to stop writing a perfect code

Perhaps, the title of this article may be misleading, but the most of those that have been doing the programming and the designing of software products for a long enough will understand, what will be discussed further in this article. In the first place, it is addressed to the independent developers.

Let us ask themselves a few questions. How often do we rewrite the code from a scratch and try to improve it? How often do we change the design of an application during its development? Do we work too long with each method (or function) and try to think through all aspects of its use? Do we think that any programming serves as a lesson and source of experience? Do we try to use something new in the new code in order to develop ourselves? Do we pay more attention to the laconic brevity / beauty of code than the laconic brevity / beauty of applications in general?

If we answered yes on the most of these questions, congratulations - we are suffering from the perfectionism.

How can perfectionism ruin our life?

Let us start with the fact that the ideals do not exist in our world. We have to get used to this idea and try to live with it. There are no resources that will allow to write the perfect application or just the perfect code, whether we like it or not.

I was convinced that it is possible to write the perfect application and bring the developing code to the point where I could look and say "it is great!”, and make the applications without any errors and uncontrollable conditions. Every time I study the problem thoroughly and try to find the most elegant solution.

The problem lay in the fact that some programmers who have had less experience than I usually complete their own and ordered projects. However, I always thought of myself that "they have written the shitting code that glitches and who will pay money for it." But as time passed, these people achieved some kind of success and their projects shaped into something "usable" over time. Their projects became popular and my projects did not.

More precisely, there was not any progress with my projects. Everything I did at some point stopped and seemed insoluble to me. I did not want to solve that situation, I wanted to think everything over, and so I delayed.

Of course, it all went wrong from the start for this reason. I took small orders for small money and tried to complete them well, of course, when I broke all possible and impossible deadlines. One project I kept nearly a year. Seriously, I kept thinking of it a whole year, but I could not finish it.

What do I achieve after 7 years of programming? I considered myself as a professional developer, I knew a lot of things, I could more than others, but ... At the same time, I did not have finished projects, or rather there were only 1% of planned. My work went pretty slowly, I earned less money than I wanted, and inside I felt an internal dissatisfaction.

Actually, the aspiration to an ideal put me in a position when my thoughts were "empty", I spent a lot of time and thoughts and the result was almost zero.

Laziness or not laziness

Is laziness my problem or something else? This is an important question that always has worried me.

The bottom line is that I could delay to start working on the project almost endlessly, but I always understand the task. No matter what I did or wherever I was, I always thought about the projects, but I did not start doing them until I find some sort of idea, a decision with which I could start.

Thereat, all other aspects of my life did not expose to such a manic idealism. Namely, I could clean up the apartment or go to the other end of town to take care of an important matter at any moment as well I could earn some money doing a physical work, but I never lay in bed all day instead of doing the over mentioned work.

I concluded that it cannot be a "normal" laziness. The problem lies somewhere deeper.

Perhaps, the problem itself is based on laziness as on a foundation, because no matter how you convince yourself otherwise the realization usually more stresses the brain than understanding of tasks. Of course, this is fairly only in the framework of the project, and it does not refer to a separate function / method, when it is necessary to consider a specific solution and just put it on the paper.

Finally, it can be summarized that it is not laziness.

I am perfecting myself

This phrase is destructive. If you have an idea or you got the idea from someone else who is waiting for realization of it, but you want to realize it in terms of self-perfection, it is a failure.

This approach is the learning inertia of programming in general. When you do not have much experience in programming each new code is a step in your development. Each new task is an exercise for the brain. If you discover or read something new, you try to use it.

In the beginning it is good, when you just climb the ladder of learning. But at some point you have to say, "Hey, wait a minute. You do not learn anymore, it is already the work. You have to write a code, rather than try to find in this any benefit for yourself”. But many people forget to say it. I also never said that to myself.

If you approach to program a real project as to an exercise, it is bad.
You will perfect yourself anytime and anywhere, but if this will become one of the goals and it will prevail, you will be doomed forever to be engaged in thinking and rewriting the code.

Each new line of code is better than the previous two

For some reason my brain refused to understand the simple fact that rewriting a code will not resolve a problem. Spending a lot of time on four lines of code and trying to find a delicate balance between the nice appearance of code and the logic, it is bad. This is a waste of time.

Of course, if you write some code and you will find the errors, and then you correct it or rewrite again taking into account the imperfections, the code will be better. You can do this, but it should not be a priority.

The problem begins when you are at the stage of "designing" and delete entire folders of code, or even delete the whole project and start it over. It is not effective, because it will look like you throw up sandwiches for as long as it will be buttered in the right way. You cannot get at an early stage the perfect design of application. Just keep that in mind.

Another variation of this problem is a persistent unwillingness to use someone else's code. Especially, if it is too complicated for you, or vice versa.

On the subject was said many words, but here is a conclusion, let us use someone else's code, if it helps the problem. Do not write a code that can be used. Because you cannot always realize this code better, faster, and most importantly, that it will never be the same tested and checked as one that has been published as a library or a separate application.

It is not always true, since there is no perfect code, some libraries may actually be bad and slow, it is not the best approach to implement it. But if your project allows using the other solutions, if they are small enough, and they are implemented by the individual modules, then some imperfections can be tolerated.

By the way, with regard to the third-party libraries, you can sometimes see someone else's code than looks better than yours. You can call it perfect. But in 100% of the cases, if this code has a sufficiently large application, you can be sure that the code was not written like that from the very beginning, and it has been perfected in the experimental use.

Let us do not rewrite the code hundreds of times. People have invented all sorts of different useful things in programming that helps to simplify the correction and editing of working code. Refactoring. Let us use them and TDD, although in the beginning it will be difficult and will seem pointless. Let us get rid of the habit to rewrite the code in the idle application.

Everlasting designing

If you have an idea or a job, you should begin immediately, if you have no other projects. There is no need to nurture the idea until it matures. That is stupidity. You should move from theory to practice no longer than one day.

You should consider only the main points when approaching the designing. In addition, you should know the answers to such questions as: where am I going to write business logic code? What will the structure of the databases be? What libraries should you use for which tasks?

If you start designing with the fact that create a document and describe all the tasks using the text, which you want to implement, and there you try to make schemes along the way thinking through some specific questions on the future code, or you start thinking how to implement those things that are not main to your project, and they are "environment" (example: framework), if all that takes more than two or three days and you have not begun the programming yet - Most likely a development will be delayed forever.

By the way, the creation of such large documents is meaningless at early stages. Seriously, it is a waste of time until you really start to work on problem solving and programming. Of course, you might say that often is used a scope statement. But then you will be wrong. The scope statement is a document, which aims to explain the task so that different people can fully understand and evaluate it, and the client could have imagined what he gets at the end. If you do not have a split personality, and you do not need to explain the problem to your second "ego" - do not start the development with the creation of meaningless notes. This is a waste of time, it is already in your head, and it makes no sense to write anything down. Start writing a code.

If your mind-set is that you think on the problem too thoroughly - try to think less. Do not think, just write the code, you can still understand the problems in the process and have time to solve them faster.

I think that MVC became so popular, because it would say to all programmers, "Stop! Do not think more on the designing simply use it". It remains to believe that MVC is sufficiently "authoritative" for you and one of the problems will disappear. Do the same in terms of the programming patterns.

I do not writing a code, but I write the application

Always remember that the world's population will not care about your code in almost 99% of all cases. You do not sell the users own code, but the result of its implementation (of course, if you are not a developer of software libraries).

Do not try to focus on how good is your code, if it does not affect the actual characteristics of your application. Actual characteristics are the speed of execution and the absence of gross errors. But here is not that simple.

Premature optimization is fatal. You need to think about what spot will be "narrow" in your application, but you do not write every string of code so that it runs faster. It takes too much of your time. It is better to optimize your code, when it will be ready. Optimize your working code.

As for mistakes, you have to accept the fact that they always will be. Errors are found in the programs that have been developed and supported for years and sometimes decades. Errors will pop up where you were not expecting them. With experience comes an understanding of what places would be problematic and solutions will emerge automatically. There is no need to try everything thoroughly examined to exclude all mistakes. Remember that to correct an error in 90% is easier than to prevent it and to make the necessary checks. It is better to correct errors in the testing phase, than spend the time to fix bugs in the code that you have not written yet.

Let us try always to think in the framework of whole application and do not concentrate on a separate part. Consider only that what will be a part of your future application. Do not try to think through all the code. Do not try to bring it to perfection. It would be better if you make an application, which will perform the tasks, but it would not have the best code, than you have nothing, but unfinished code that you will work on for months.

Do projects, rather than writing a code. Point your meticulousness in the right direction and try to figure out how you can make something better. Try to think of what someone might need, but which does not exist yet. Maybe you will come up with the idea of a new project that will change the world, but you cannot realize it, because you will not be able to finish the code, or even start!

There are no ideals, let us do GEA!

Since the ideal is unattainable, then you try to bring an application to the minimum acceptable level. When the application actually works, because it is really important and the code is only a tool.

As long as you strive to do something very well, you will always be outrun on the turn by those who are doing just well enough that you can use it. You will be surprised, but most of the software that you use every day is not ideal, even if it works very well. Some programs can be written very "bad", according to your standards, but they work and you use them.

If your desire for the ideal due to the fact that you are looking for some kind of recognition or you want to convince yourself that you are a good programmer, I can assure you that you will get more confidence from the responses about your completed application, than the strings of code, which even colleagues will not care about.

You try as quickly as possible to make an application to work to fulfill its purpose. After that, you begin to correct errors. Make the code readable and write comments, documentation, but do not do the opposite, because it increases the development time.

This article does not include 10-step process to defeat perfectionism, because they do not exist. Therefore, this article just tells you to program! This is the only solution.

If you suffer from perfectionism more than 5 years, then your code that you write without thinking will be good enough at the first time. Good enough to make the application.

If you delayed or pondered some ideas, but you have not begun to implement them yet or you got stuck at some point, because you cannot figure out how to do it perfectly, you just sit down and write a code. Because someday will come a time when it is too late to start writing a code.

Post scriptum:
This article primarily is addressed to those who engaged in the development and programming without well-planned management. If you have a boss who just tells you what to do and what not to do, you may never run into the problems that are described above.

However, the reality is that those who suffer from perfectionism, it is very difficult to work under someone else's control; it is difficult to do a simple coding, because the desire to do everything perfectly will always outweigh. The perfectionism will appear itself in some tasks, even if you are not the only developer in the team.

“Translated from another resource, thx jlbyrey”
Sparks 8 december 2011, 16:21
Vote for this post
Bring it to the Main Page


0 mistiq December 9, 2011, 1:47
Specify the author, and resource.
0 Sparks December 9, 2011, 3:03
Thank you, I've done this.

Leave a Reply

Avaible tags
  • <b>...</b>highlighting important text on the page in bold
  • <i>..</i>highlighting important text on the page in italic
  • <u>...</u>allocated with tag <u> text shownas underlined
  • <s>...</s>allocated with tag <s> text shown as strikethrough
  • <sup>...</sup>, <sub>...</sub>text in the tag <sup> appears as a superscript, <sub> - subscript
  • <blockquote>...</blockquote>For  highlight citation, use the tag <blockquote>
  • <code lang="lang">...</code>highlighting the program code (supported by bash, cpp, cs, css, xml, html, java, javascript, lisp, lua, php, perl, python, ruby, sql, scala, text)
  • <a href="http://...">...</a>link, specify the desired Internet address in the href attribute
  • <img src="http://..." alt="text" />specify the full path of image in the src attribute