Fast programming techniques: Stop thinking.

When talking to developers about the complexity of the code, most of them often just want to write the simplest code. However, with the pressure of the deadline and the surrounding issues always make them unable to spend much time and energy to complete their code for neat and clean.

In fact, putting pressure on developers will cause them to write more complex code. Instead of saying in the beginning, "This deadline will prevent me from writing clean, clean lines," they might say, "I'm not fast enough to write it neatly and neatly." Because of this simply, the more your programming skill increases, the less the deadline will affect the quality of the code.

It sounds ideal, but how can a programmer code faster? Is this a skill they are natural in? Absolutely not? Actually, it's not a miracle or a bliss or anything. In fact, there is only one very simple rule, if the developers obey, the problem will be solved thoroughly.

Every time you find yourself having to stop to think, something may be wrong.

Perhaps this sounds a bit "weird" but it appears to be quite effective. Think of the time when you sit in front of your editor, but the code is not very fast, is it because your "trigger" is a bit slow? I don't think that's the problem. The problem is, the pauses for thinking are the main obstacle to making you slow down. And what do programmers usually do in those stops? Maybe they're thinking about issues, tools to use, email, and lots of other things.

Thinking is not really something serious, but it is a sign that there are some other problems going on. That may be one of the following:

Understand yet!


One of the reasons programmers are encumbered is because they do not fully understand some of the words or symbols in programming.

This has just happened to me recently. It took me several hours a day to just "swim" in pretty simple things, which should have been done long ago. I have to stop quite a few times to think. And finally I realized that I didn't understand one of the main input variables of the main feature. I know the name of this type but never read about its definition, so I didn't really understand the variable. After rummaging around and finding out about my vulnerabilities, things have become more and more obvious, my processing speed has increased "more" than many times.

This can happen in any situation. Many people have jumped into programming without really understanding what the symbols (,), [,], {,}, +, *, and% really mean, how they work. When you really understand it, you don't have to stop to think. That's why I wrote the book "The Singular Secret of the Rockstar Programmer", which will help you gain deeper insights to avoid common mistakes.

So when you find yourself having to stop to think, don't try to solve the problem by looking at things that you don't really understand. Find knowledge that will help you understand their nature first. It can even help you answer questions like "Can users read these texts?". Although you don't have a User Experience team (but you can at least guess what the answer is. Don't just sit there and think, do something!).

Outline the problem!


Sometimes, programmers have to stop to think because they have so many concepts and knowledge in their heads that they cannot coherently link them. In that case, you can write or sketch ideas out like a true mindmap, generally anything that you can see visually. You can only understand it most thoroughly and thoroughly by observing it from the outside.

Just do it already!

Occasionally, the problem is that you don't know where to start. The simplest solution is to start writing any code you can write down. Then select a part of the problem that you can understand best. Then write down the solutions for it or you can write a feature or a certain class doesn't matter.


Sometimes, the simplest part of the code that you can start is the "core" of the application. For example, if I start writing an app for Youtube, I can start writing a video player application, for example. Think of it as a "warm-up" article that can help you advance further in writing products, and don't be too important that it's just a small part of the product. A video player application without a UI is still an available product (play video for example), even if it is not yet complete.

If you are not sure how you can start writing the main code (core), you can start with the code you are most sure about. Basically, I think that it is easier to solve the problem in small pieces rather than trying to solve the whole pile at the same time. Occasionally, the problem will be "accidentally" solved when you are dealing with one step at a time, and it will lead to many other problems that are also removed. In general, the part that doesn't need to think too much is to finish it first.


One of the special methods to help you understand the problem is to skip a few steps in sequence of development. For example, if you want to write an entire "Bicycle" Object, for example, but don't want to write the "Wheel", "steering wheel" or "framework" object, you'll have to think a lot about classes that don't exist yet. that. On the other hand, if you write "Wheel" class without a "bike" class, you will have to think a lot about how to use the "wheel" class for "Bicycle" class.


The right solution to this problem is to make enough that the "bike" class can reach the point where you start needing "wheels". And writing enough so that the "wheel" class can immediately satisfy the needs of the "bike" class. When returning to the "bike" class, and do it until you need another piece. Just like what I mentioned before, find the parts you can solve without thinking ahead, and solve it immediately. Don't jump back and forth the steps in the system development process and expect you to be able to code effectively.

Body condition.

I didn't joke, if I didn't eat enough, I would lose my concentration because I was hungry. Thoughts will focus on stomachs rather than code. This will also happen when you are sleep deprived or ill. In general, all physical problems of the body are related.


When the programmer is distracted by external factors, such as noise, people coming in, closing sounds, loud voices, etc. it can be one of the main problems that distract you. The answer is simply to give you an environment where you don't lose focus, at least work with colleagues who keep quiet.

Ignore yourself

There are times when programmers or sit and think about their decisions. The solution is the same as the "thorough understanding" I mentioned above, find a way to thoroughly understand the issues before working on the code. If you feel uncertain about yourself, list things that you don't understand and then gradually research them. Because in programming, learning is always ongoing. At first, it was a bit slow, but you will gradually get to know it better and the code will be greatly improved.

The wrong concepts

Many people say that thinking is of smart people, they often slow down to think carefully and make decisions. This is a wrong concept. If thinking turns you into a genius, then perhaps all was Einstein. Truly intelligent people are people who learn, observe, decide, and act. They gain knowledge and use that knowledge to solve the problems ahead. If you're really smart, use your intelligence to act, don't use it just to "think !?"



All of the above mentioned are the secrets to becoming a "speedy programmer". If you have to read emails and meet all day, no programming work is done, that's another matter. Some problems have the same perspective, but it's not really the same.

There are some other solutions you can try, believe me … And maybe the company still does not fully understand your role, it is because they pushed you too many emails and meetings do not need set. And perhaps also, you have not really understood your company, do not know how to have less meetings, to receive fewer emails. Even, some difficulties can be solved by using the methods I mentioned here for a group of people in the company rather than just for a few people.

ITZone via codesimplicity

Share the news now