When to be good is bad

I would like to start with a story:

The ceramic teacher announced on the opening day that he would divide the class into two groups. “Those who sit on the left,” he said: “they will be judged only by the amount of work done, those who are on the right, only by its quality.” His technique was simple, on the last day he will bring scales and weigh the work of the “quantity” group: 50 pounds of pots is “5”, forty pounds of pots is “4” and so on. Those who are rated for "quality", however, must make one, albeit a perfect, pot in order to get a "5". The turnaround time came, and a curious fact came to light: the works of better quality were made in a group, evaluated by quantity. It seems that while the “number” group stubbornly stamped their work and learned from their mistakes, the “quality” group theorized about the ideal and, in the end, could only show its efforts and grand theories about the ideal, as well as a bunch of useless clay

This story is from the book Art & Fear .
')
I admit, I have not read it yet, but I stumbled upon this story once, and it struck me.

The better you try to do, the worse it turns out

Software development is a difficult profession. It is fairly easy to learn how to program, but it can take many years of training and practice to learn, to really build complete software systems.

One thing I noticed is that software developers tend to be very productive.

I remember the days when I had a floppy disk with different programs I was working on. Then it seemed that I began to understand software development better, in fact, I began to become less productive.

Why did it happen so?

I have several theories, but the main thing is that when we do not know what we are doing, we are just trying to complete the task.

Remember you were a kid? Most likely you drew a lot. And surely these drawings will not be so good, if you judge them by your current standards, you could even call them terrible.

Why did you stop drawing so much now? (Maybe you are not, but most have stopped.) It is better to put the question like this: “why did you draw so much then?”

There are many answers, but I think most of us will decide that one of the reasons is that children simply learn and learn, and they are not constrained by any restrictions.

At some point, we are getting older, and we understand what art is and how it should look. We might even learn how to draw correctly. In the end, we have an idea of ​​what is a good picture, which leads to the fact that it is very difficult to take this pencil in hand.

So what happened?

I know that I went through a phase in the development in which I wasn’t close as productive as I could have been.

I spent a lot of time “admiring the task,” and even more so “turning the simple into the difficult.”

As software developers, we tend to put restrictions on ourselves and look for the perfect solution to a problem.

So far I have not gone too far: I do not advise in any way to write a govnokod and distribute it. Do not do this!

I propose only to try to search for the optimal solution by 90 percent, knowing that it will be possible to return to the problem again, if you really need to find a better solution, do so instead of spending time on solving the optimal solution for 95 percent or more.

I wrote earlier that this is the most difficult thing I have struggled with , and I think this is relevant for many developers.

The problem is that when we start as developers, we don’t know the “right ways” and are less limited in our actions. We just go ahead and do it.

When we start learning to do “rightly,” we are often stifled by this knowledge and the limitations associated with it. This makes us less productive and forces us to invent redundant solutions for problems.

So, I guess that amateurs are better than professionals?

Not in all senses, but perhaps they are better at something. Maybe in that produce more.

In my understanding, the decision is to stop being afraid and drop the restrictions, but temper oneself with the knowledge and wisdom of experience.

I applied it myself, and in the last few years my productivity has increased incredibly.

Here are some practical tips that have increased my productivity as a developer.

• Attach yourself before looking around. I stopped reading so much theory on technology before diving into it. I began to apply it and then refine my knowledge, instead of first reading and then doing.
  
• Stop worrying about how . Often, when I consider a certain direction of work or a new project, I first of all consider ways to accomplish it. This is a motivation murder and a waste of time. How it is not so important that when is much more important. How makes us delve into the details. I began to believe in myself and in what I find out how, when needed.
  
• Do not be afraid to do carelessly for the first time. Many times I wanted to start with a clean solution. Often it’s just a waste of time, because you don’t know enough about the problem to develop a correct solution until you start to solve it.
  
• Do not be afraid to rewrite the code. This is close to my past statement, but I highlighted it because this is important in and of itself. Rewriting something is not as bad and difficult as it seems. If you are not afraid to completely rewrite some of your code, you are more likely to solve the problem in an almost optimal way that will help you to move forward and not get stuck.
  
• Acknowledge that there is no perfect solution, there are only solutions optimized by one or several parameters. Some solutions have fewer compromises than others, but all solutions have compromises that cannot be avoided, no matter how hard you try.
  
• Don't be afraid to fail, but because you tried your best, and not because you gave up. It is better to try to take up a large business twenty times and achieve success for the twentieth time than to solve small problems that you can solve the first time. You can reach exactly the heights you are ready to fall from. The main thing in failure is that if you fall, you can always get up.
  

The moral of the story ...

Sometimes being good is bad because it interferes and paralyzes us. I found that a lot more things are done by performers, not by thinkers.

Do not let your knowledge of the "craft" of software development be a hindrance to your productivity, or you will be forced to observe how those with less skills and knowledge constantly surpass you while you angrily and sharply criticize them from the outside.