Those antipatterns of programmers

Where there is chicken soup, there is anti-chicken soup, and where there is pattern, there is anti-pattern.

Today, we’ll talk about anti-patterns in programmer behavior, covering all aspects of programmer’s daily work and learning.

These anti-behavior patterns are not specific to any particular individual. Don’t be upset if you fall into this trap, because it’s perfectly normal, and I’ve done a lot of anti-patterns myself

Debug with a few lines of code changed

For all programmers, there is a psychological reason for this behavior: engineers like to see what happens when they make a change. It’s a temptation.

In addition, this practice is more common for novices.

Newbies are unsure of every line of code they type, so rely on intensive debugging to verify step by step. The same is true when a veteran uses a new technology for the first time in a project.

But it has to be said that this approach is inefficient.

First, for larger projects, manual debugging takes time.
What’s more, it’s easy to break your train of thought and even miss some critical flow by constantly interrupting your coding work for debugging.

A better way is to think about the key logic of a complete function or module before you start coding, then type all the code in one go and debug all the cases at once. If you have an automated test +Daily Build system, take full advantage of it.

Of course, sometimes it is inevitable to encounter uncertain technical points, at this time, if possible, the better way is to build a separate lightweight, easy to debug and verify the project, to systematically explore the fuzzy technical points again.

Learn new projects by setting numerous breakpoints

One of the first things a new programmer should do at a new company may be to learn and familiarize himself with the new project. So we often see something like this:

For small projects, there is nothing wrong with setting a lot of breakpoints to understand the flow of the program. However, for complex large-scale projects, it is easy to get caught up in details, resulting in the consequences of “seeing the wood for the trees and not seeing the mountain tai”.

Also, in projects that make heavy use of asynchrony and multithreading, there is often a difference between breakpoint debugging and actual execution. Especially for a new company, this may lead to his partial understanding of the project code, or even misunderstanding.

On an individual level, it’s also easy to get into the habit of “you can’t read code without debugging.” This is a less beneficial form of dependence. Remember, there are very few opportunities for us to debug ourselves compared to the code we are going to read.

My point is that breakpoint debugging is a great tool, but be wary of its drawbacks if it is the primary way for newcomers to learn new projects.

Rely only on Baidu to search for technical problems

There has been too much discussion about whether programmers should use Google or Baidu. I don’t think I need to emphasize the difference in search technology here.

Generally speaking, even if you can’t use Google due to circumstances, using the English version of Bing.com is a better choice than Baidu.

But the point that needs to be explained here is that the search technology problem is not to say that baidu will certainly not get good results. In fact, when you want to search for a fixed usage of the relevant code reference, Baidu is very quickly to meet your requirements. It’s important to remember, however, that you don’t just use the code you find, but that you use it at the level of specs and API references (see my other article, “Technology Authenticity and The Way to go” for the concept of specs).

Inadvertently use the translation plugin

Does your browser pop up a “translate toolbar” like this when you visit an English website?

This is an embodiment of modern browser intelligence. However, for programmers to read technical articles, the original English document is more accurate.

So, if your browser has such a translation toolbar, find a way to remove it or close it.

Reading English technical documents, in fact, the English foundation is not too high. English technical documents, the vocabulary involved is very limited, and the general sentence pattern is relatively simple. The reason why some people feel difficult, a lot of times is a lack of patience or psychological fear.

For everyone in our team, I tell him this: the ability to read Technical documents in English is a must; Otherwise, you’re going to have a hard time breaking through the technology.

Implement the simple ones first, and we’ll talk about the rest later

We tend to act based on what we are good at. When there are complex and unconventional parts of a project, many people choose to do the easy parts first and the complex parts last.

“Last minute” means to wait until later in the project to think about it. This is actually avoiding and shelving conflicts.

From another level, this is also an instinct of people to seek benefits and avoid harm. An ostrich mentality.

By then, the project deadline may be approaching, and people may not have the patience to come up with a solution, resorting to compromises such as lowering product requirements.

In the worst case, it’s possible to end up overthrowing the entire design because key details aren’t clearly discussed at the beginning.

So, at the beginning of the project, it is a priority to discuss the seemingly complex technical aspects of the product that may be out of control. In fact, the ability to consider the most complex and changeable things clearly at the beginning reflects a team’s comprehensive level.

You can’t see the source code for dependent projects in the IDE

I’ve already touched on this issue in another article, “The Authenticity and The Wild Way of Technology.” So let me expand on that a little bit.

We all need to read good open source, whether for self-improvement or for work. In fact, reading open source code is not necessarily a complete open source project to read from cover to cover. Should start from the daily work needs SDK source code, every little makes a mickle.

Every programmer, no matter what language he or she writes in, generally relies on a language’s SDK, which is usually open source. For example, the Java JDK, the C++ STL, and the Android SDK. Be sure to set up your development environment so that clicking on a called method can jump to the source code implementation. Only in this way, you can use the normal development time, at any time to click over to read the source code.

Sometimes I find engineers with a fancy IDE and great keyboard shortcuts, but it’s hard to understand why you can’t click on the source code. Programming in this situation makes me feel blindfolded.

Of course, some programmers are working with a closed source system, such as iOS programmers, and this approach may not be appropriate. Closed source SDKS, however, tend to comment in more detail, at least through the IDE, which reads the comments carefully for each call. Also, the Swift SDK for iOS is now open source.

The habit of clicking on the source code of a dependent project in the IDE applies not only to reading the open source code, but also to calling interfaces provided by other teams within a large company. Deepening your understanding of the systems around you and expanding your knowledge boundaries is always a great way to stand out from the crowd within any company or organization.

I’m too lazy to read previous code because it sucks

When we have a little bit of work experience, we always complain about the bad code left behind in the project, and there is always an impulse to overturn the rewrite.

Often times, people new to a project get the wrong impression of the quality of the code that has been written before. However, it is important to know that previous code authors may have had more information than we currently see, and that they have probably already considered what we are and what we are not considering.

What’s more, coding is like writing. Take folding Beijing, which recently won a Hugo Award, for example. Some people think it is a progress of Chinese science fiction, while others think it is not a mature work. As a sci-fi fan, I also criticized it in my moments. While everyone is entitled to his or her own opinion on an original work, we should understand that there will always be controversy.

Therefore, the first thing to do is to be in awe of what has been left behind, so that it is possible to understand it.

Even if the previous code is really bad, we should read it thoroughly before refactoring to make sure we don’t lose logic when we update the code structure.

You know, reading other people’s code is a higher ability.

Ask the Leader if you have any questions

Asking questions is often considered a virtue.

There is one condition, however, that can be considered lazy or out of touch.

Suppose your Leader gives you the task of researching a new technology and applying it to the project. Pretty soon, you hit an insurmountable obstacle. Then you go to the Leader for advice.

As a result, your Leader learns about your problem and asks you questions such as, “What if it were used differently?” “Or,” This concept in the document seems to be related to another question. What does it mean?” “Or,” How did the problem arise? Do you understand the underlying principles?”

If your answer is “I don’t know, I haven’t had a chance to read it yet”, I’m afraid your Leader will mentally put the “not thinking” on your head.

It’s kind of like a trap in here. If you can answer all the questions your Leader asks you, you probably have solved the original problem.

Therefore, before taking your problem to your Leader, make sure that you have fully explored all possibilities and preferably have some solutions in mind. You just need your Leader to help you make some trade-offs on which one to choose.

It’s easy to say it’s impossible

Product students often ask programmers to confirm the feasibility of some ideas, like the following dialogue:

Product student: Is it possible to change the data of this place into the display form like XX software? Programmer: No way. Our server-side data storage format is not designed that way at all. Product student: Can the interaction here be changed? Let the user more convenient operation. Programmer: No. The control we’re using is written dead here. Product s: Can’t this control be changed? Programmer: can’t change, this is a system default control……

As a technician, when asked about feasibility, you should think carefully, do some research if necessary, and then give an answer. Giving impossible answers easily can limit the way you think about product development.

In fact, many of the impossibilities are partial judgments that are limited to existing implementations. A lot of the impossible can be made possible by jumping out of existing logic.

You know, many great products have been created by pushing the boundaries of the impossible. In the process of transformation from impossible to possible, the old technology system is abandoned, new development methods are introduced, the original limitations are broken through, and the technology itself is bound to experience a baptism of rebirth.

Staring at QQ seconds back to the message

As you work for a company for a while, the more things you are responsible for, the more things that are related to you. Therefore, people in the company often ask you for help on QQ, or ask you questions.

Every day from the beginning of work, your QQ icon flashing. You just finished processing, is ready to code to achieve a section of the algorithm, QQ icon lit up again.

Your colleagues praise you for being so quick to respond to messages. But your core development tasks keep getting delayed.

There is a time management issue involved.

This problem is particularly acute for some front-line technical managers. One day they communicate and coordinate, one day they are invited to a seminar, and the next day they come to discuss technical issues. It was five or six o ‘clock in the afternoon. Finally, it’s quieter, but you’re exhausted. You’re like a spent force, and you can’t really think deeply anymore. As a result, the work planned to be completed during the day can only be taken home at night to burn the midnight oil.

To be honest, the problem is rather tricky. If you can switch your attention quickly between different tasks, I can only say that you are really good! This will allow you to quickly return to your original focus after an interruption.

For ordinary people, however, finely slicing time, like the Pomodoro Technique, might have some effect. That is, if you can actually stick with it and stay focused when you need to.

Nowadays, we all know that concentration is a valuable quality when we bring up a child, which may be directly related to his or her future achievements. Unfortunately, more and more adults are losing this quality.

Some time ago, I installed the Mac version of wechat. The result is a flood of messages that can be a poison to concentration.

Finally, painful uninstall.

(after)