The secret of fast programming: do not hesitate

Programming fast is easy! So says Google’s software engineer who signs all posts on his blog as concise “Max.” Max also works as chief architect, community manager and release manager for the Bugzilla Project . We at Alconost were impressed and translated his advice on how to learn how to program with cosmic speed.

When discussing the complexity of the code with developers, they often say that they want to write simple code, but because of the pressure of deadlines and deeper reasons, they do not have enough time or knowledge to complete the task and optimize the solution to the maximum simplicity.

They, of course, are right in that in the conditions of short deadlines developers, as a rule, will write the difficult code. However, deadlines should not lead to complexity. Instead of the phrase “This deadline prevented me from writing a simple code,” you can say the equivalent: “I don't program quickly enough to write simply.” That is, the faster you are as a programmer, the less deadlines have an impact on the quality of your code.
')
Now let's figure out how to actually become faster? Maybe this innate magic skill? Do you need to be “smarter” than others to be quick?

No, it is not magic at all and not an innate gift. In fact, there is only one simple rule, reckoning with which, in due course you will completely solve the problem:

Whenever you notice that you are stomping on the place in thoughts, know that something has gone wrong .

This may sound incredible, but it works exceptionally well. Think about it: when you sit in front of your editor, but the work is not fast, is it because you have a low dial speed? I doubt: “recruiting too much” is a rare problem of programmer performance. A pause when you do not type is what slows down everything. And what do developers usually do in such pauses? Trying to stop thinking - maybe about the problem, about the tools, about the message in the mail, but about anything. But whenever that happens, it means a problem. Reflections in themselves are not a problem, but a sign of some other problem. Probably, instead of walking in a circle in your thoughts, you should pay attention to one of these:

Understanding

The most common cause of unproductive thinking by a developer is an incomplete understanding of a word or symbol.

It happened to me just the other day. It took me hours to write what was supposed to be a really simple service. I tried very hard to stop thinking about it, trying to figure out how things should work. As a result, I realized that I did not understand one of the input variables in the main function. I knew the name of its type, but I never took an interest in its definition — that is, I did not really understand what this variable (word or symbol) meant. As soon as I looked through the code and documentation for this type, an understanding came, and I wrote this service as a demon (the pun is partly non-random).

There are countless options. Many people use the programming language, not understanding what (,), [,], {,}, +, * and% mean in this language. Some developers do not understand how the computer actually works. Remember my “ The Only Secret of a Rock Star Programmer ”? That's where the essence is! After all, if you truly understand, you do not need to stop unnecessary reflections. It also prompted me to write a book : an understanding of the fact that there are unshakable laws for creating software can get rid of many episodes of “struggle with reflections”.

So, if you find yourself in a mental impasse, do not try to solve the problem in your head - look for what you don’t understand, outside of yourself. Then take and look at something that will help your understanding. This even applies to questions like “Will a user ever read this text?” You may not have a Department of User Experience Studies to give a real answer to this question, but you can at least draw something, show others, listen to their opinions. Do not try to just sit and think - do something. Only action leads to understanding.

Drawing

It happens that a developer’s thought stops because he doesn’t manage to simultaneously hold in his head all the ideas in the work - a lot of things connected in a complex way that need to be understood. In this case, it is almost always more effective to write or sketch something than to think about it. You need to look at it from the outside in any way you like, perceive it outside your head. This is one of the options for understanding, but important enough to make it a separate item.

Getting started

Sometimes the problem is that "there is no idea what kind of code you need to start writing." The simplest solution is to start writing any code you know that you can write right now. Choose a part of the problem that you fully understand and write a solution for it, even if it is just one function or not the most important class.

Often, the easiest piece of code to start is the “core” of the application. For example, if I were to write a YouTube application, I would start with a video player. Think of it as a continuous delivery exercise: write the code that really creates the product first — no matter how stupid or insignificant it can be. A video player without a user interface is already a product that performs a useful task (video playback), even if it is not yet full .

If you are not sure how to write even such basic code, just start with a code that you are sure of. Usually, as soon as a part of the problem is solved, it becomes much easier to solve the problem entirely. Sometimes the problem is revealed in stages: you solve one part, which makes the solution of the next part obvious, and so on. Start with any part whose creation does not require much deliberation, and simply write it.

Skip steps

Another specific problem of understanding is skipping a step in the correct development sequence. For example, our Bicycle object depends on the objects of the Wheel, Pedal and Rama. If you try to write the whole Bicycle object without writing the Wheels, Pedals and Rama objects, you will have to think a lot about these non-existent classes. On the other hand, if you write the Wheel class, while the Bicycle class does not exist at all, you have to think a lot about how the Wheel class will be used by the Bicycle class.

The right decision here is to implement a sufficient part of the Bicycle class to get to the step where you will need the Wheels. Then write a sufficient part of the Wheels class to satisfy the actual need for the Bicycle class. After that, go back to the class Bicycle and work on it until the next need for some of the basic elements. Just as in the “Beginning” paragraph: find the part of the problem that you can solve without thinking, and solve it immediately.

Do not skip steps when developing your system - and this will allow you to be productive.

Physical problems

If I do not eat enough, I start to get distracted and think, because I'm hungry. It’s not necessary to think about my stomach, but they wouldn’t have arisen at all if I were full - I would be focused. The same is true for sleep, disease, and any other bodily problems. They are not as common as those listed above, so the first thing is to always look for what you don’t understand well enough. But if you are sure that you understand everything , the reason for stopping the thought may be problems on the physical level.

Distractions

When a developer is distracted by something external, such as noise, it may take him some time to think about what he has worked on in his decision. The answer here is relatively simple: before you start working out, make sure that your environment will not disturb you or distracting factors will not interrupt you. One needs to close the door to your office, others need to put on headphones, someone needs to set Do Not Disturb: do as you need. You may need the help of your manager or staff to create a truly development-friendly environment.

Diffidence

Sometimes the developer sits and reflects because he feels insecurity in himself and his decisions. The output here is similar to that described in the “Understanding” paragraph: if you are not sure about something, find out more about this until you have enough confidence to write code. If you are not confident in yourself as a programmer in general, you may need to learn a lot more - like the basics outlined in " Why programmers suck ." Understand each question until you get a real understanding, then go on to the next one, and so on. Programming always involves learning in the process, but as your knowledge increases, you will become faster and faster, and you will have to think less and less.

False submissions

Many were told what to think is the lot of smart people, and they don’t think to make intelligent decisions. But this is not true. If thinking in itself could make you a genius, there would be only Einsteins around. Really smart people learn, observe, make decisions and act. They acquire knowledge and then use it to solve problems. If you want to be really smart, use your intellect for activities in the physical world - do not close yourself with it for great thoughts in your head.

Inaction

All of the above is the key to how to be a fast programmer when you sit and write code . If you read mail all day and go to meetings, and you have no time to program - this is another problem. Some of its aspects are similar (as if the organization had to “not think”), but this is not the same.

However, you can try several approaches by analogy. There is a possibility that the organization does not fully understand you or your role and therefore sends you so many letters and invites you to so many meetings. Maybe you don’t understand something about the organization, for example, how to attend less meetings and receive less mail :) Maybe you will be able to resolve some organizational difficulties by adapting the solutions from this post to teams instead of individuals.

How do you approach this?


About the translator
The article is translated in Alconost.

Alconost is engaged in the localization of applications, games and websites in 60 languages. Language translators, linguistic testing, cloud platform with API, continuous localization, 24/7 project managers, any formats of string resources.

We also make advertising and training videos - for websites selling, image, advertising, training, teasers, expliners, trailers for Google Play and the App Store.

Read more: alconost.com