Bad habits that inhibit the progress of programmers, have just started working not long ago, which I realized while accompanying them

Recently, I was assigned to support poor programmers, in the form of a pair of programming.

While doing that work, I found that there are some bad habits that make them difficult to progress and good habits that I will list as below.

The power of habit

Every day, I still ask myself what programming capacity is decided by? Some people learn programming very quickly, but some learn very slowly. Often, people call it "good enlightenment, good enlightenment" and passing.

But I clearly see the determinants of learning fast or slow.

A few years ago at one time, I watched the screen of a colleague sitting next to me and occasionally walked around the office to see other people's screens. There was one thing that really surprised me. The person who "submits" the lesson slowly then the screen often tends to display stack trace (used for web application output).

The co-worker sitting next to me often programmed according to the procedure below. I don't have detailed statistics, but that sort of thing.

• Write code
• Save the code
• Switch screen to browser
• Reload
• Error screen appears
• Switch to the code screen too

Like this, I think productivity will be very bad. In addition, he is writing part of the model (and of course that part is on the controller side).

Immediately, I showed him how to check the syntax and how to test each module. Based on that, I just added to him how to write small test code for the logic part. But it seems like he already knows.

However, because he thought it was troublesome, he ignored it.

I asked why he was bothered, he was a bit embarrassed, explained quite a bit, but the idea was, "You have to show it anyway, so how to show it is the fastest".

This is a habit problem. In that day, my company did not have continous integration process, so almost no one had the habit of writing test for code.

Later, the CI process is applied, writing tests for code becomes mandatory. However, when the show was good, he just wrote it, with an attitude that was not fun to do.

The above process of him, due to running the code after it has been assembled, the screen will show a lot of complicated errors that make the work last longer. He didn't seem to care about it, and he didn't read the error.

He is not familiar with each part, but after transplanting the code will be much more difficult to test.

The process that was born to increase productivity, now due to the habits of workers, results in reduced productivity.

Bad habit

Recently, I have a pair programming with some young engineers. One day I worked with them for a few hours, taking up most of my time at my company.

I will introduce some of their bad habits while working, I discovered and reminded.

Less reading code

Depending on the project, the time to read the code is different, but generally, the time to read the code always accounts for a large proportion. The usual time distribution is 80% of reading, 20% of writing. Reading code is mandatory in order to understand the relevant, understandable parts of the framework.

For engineers whose work is often malfunctioning, not progressing, I find the rate of time they spend reading code is very low.

An example is having a guy who is going to use a function with a framework in it. I told him that the framework is displaying input errors.

However, he did not see my place on the framework after that.

So what does he do?

• Looking intently at your code, absurdly looking for the wrong place.
• Reflect a piece of code online to see if you should copy paste.

It means that whenever the code is not running, he will sit and watch the code he wrote is wrong.

Edit

I show him how to find the wrong paragraph corresponding to the framework. At the same time, I asked him to read how that particular section dealt with and concluded why the code didn't run.

Psychological problems

I asked why he didn't read the code of the framework, he replied, "It looks complicated, and I want to finish it soon." I also acknowledge that the content within the framework is very complicated, and it is true that it is difficult to understand the whole.

However, by studying it, the knowledge of the language and the ability to read the library will increase, the level of self will increase.

I let him experience breaking that psychological barrier, studying how to code will make the problem resolved quickly.

Because of the above, I think the instructor should not say something like "This part doesn't understand well", "Don't read much, just run away" – that's also important .

I always think: how high your maturity limit is, depending on how deep you understand the code.

Do not test complex processing sections separately

I once said in the previous article that breaking down functions is very important. Why must split? "Because it will be easier." However, for non-mature people, it feels like "more miserable".

For example :

A structured function like this means you want to perform partial processing individually. Non-mature people tend to write what they want to handle in the comments above.

But it should be like this:

The parts you want to handle are separated and independent (called a sprout method). Doing so will prevent the original function from being complicated, and help us test each one.

Edit

I let them familiarize themselves with the process that before I touched the original function, separate what I need to process into separate functions, then write and test the previous ones. They then saw the results of how quickly the resolution of the error arises. At the same time, I help them realize what the input output is, how I affect other parts.

Psychological problems

The cause of feeling that dividing many functions is suffering is from thinking "want to finish soon". They thought, "If there is an error later, just see where the error is and then fix it." So they found that dividing a lot of functions is very "complicated problem", just "if the time is over, do it".

However, if you combine all of them into one function and run, then understanding the code will be very difficult and the vicious cycle "run and error" will last, the error is still very heavy. So it is taking time.

Just as in Geometry to solve our problem or we need to draw a side line. It's important to learn how that road is.

Do not check your own workflow

As the first part I said, habits are power. We need to have a working process as quickly as possible, aiming at automation.

From the pair programming day, I realized a boy who was sitting and staring at the code after writing. I asked what I was doing, and he said, "I'm checking." He really is checking each line of code one by one, see if I wrote something wrong.

I told him to check the syntax first, then he asked, "What does the check syntax mean?". After I showed him how to do it, he then kept asking me "Is this the right sentence?", "Is this okay?".

I answered that I checked myself first, he didn't understand what I meant.

I realized that in addition to the process of checking my code after it was built and running really well, they didn't have any more processes when working. Unit tests are things that are born to see if each part works correctly. If while doing unprepared, not the person who has the habit of doing test (first test), then later being unit test will be very tiring.

Edit

The code is used to check the syntax for leaving the editor alone and using it frequently. If necessary, whenever the save code is automatically run to test.

Since he uses the editor as vim, he needs to install the plugin like quickrun or syntastic.

https://github.com/thinca/vim-quickrun

https://github.com/scrooloose/syntastic

Classes and functions, too, are fine, but need to create an environment to test them one by one. If the test is delicious, save it to a test file.

That's the process I want him to take. Before asking "Is this okay", please do all the above.

Once you get used to it, you should create a CI environment based on how to use debug or fswatch. When saving code, run that CI to test the best.

Psychological problems

The above environmental problem seems to be related to knowledge, not psychological. However, after analyzing, I found it related to the perception of two common concepts when programming is "standard code" and "error code without knowing why".

The fact is, there is not only one "standard code".

However, people who copy paste often tend to think: copy paste can not run, it is probably because I manipulated wrong somewhere, copy paste is missing somewhere and often have a habit of looking for the ones there.

For that reason, their code after writing is no different than an alien code, and they will have to find the wrong error in the pile of codes. The part that they write themselves is also based on the copy paste, which will later become something that they cannot explain themselves.

Their psychology is to always think that reading and checking line by line is less productive than copying a whole lot.

Do not read the error message, do not read the log

The error message of the programming language, or the error message of the library, has the task of showing the wrong place that people can understand, written by humans. However, slow-growing programmers often don't read those. They are only aware that an error has occurred.

If the code is on IDE, you can click to jump right to the error command. But if you do it on vim or Web browser, then reading the log message, and jump to the error statement is the programmer's task.

Do not read, do not jump to the error command so the error screen is often switched off in a split second. While pair programming is with some people, they switch the screen so fast that I even think they're testing the eye's reaction to moving objects.

As a result, they sat staring at the code they just wrote, looking for any typos and font errors by looking back at the method name.

The problem is that the error message just now does not say that the method name has an error, or does not exist.

Once you don't read the error message, the scope of the error can be infinite. However, they only think that they "write something wrong".

Edit

Of course, read the error message and find out the meaning of each message.

In addition, I helped them explain the connection between error messages and the environment. Also, guide them to create small code snippets to reproduce the errors (snippet) that can be used for later and plan for similar cases to happen.

Psychological problems

There was a young man who said, "I'm afraid of English, it looks like code." However, the grammar of error messages only stops at level Two students, but I know he understands well.

It must also be acknowledged the fact that to understand the errors related to programming languages ​​and frameworks, it is necessary to understand their specialized structure and words. This is difficult.

But that does not mean that the language or framework is "unfriendly" but because the error message itself is not born just to show errors related to the programmer's code.

So we need to follow both the framework, the programming language, and the code. So we can hook up the error message and the problem we need to solve together.

In order to be able to do so on your own, everyday you need to create a habit of learning those things for yourself. If not, no matter how long, the error message will always be "codes" only.

Do not know how to deepen the problem

An error has occurred, meaning that we can find clues to solving the problem by looking at the error code.

There was an error there, which means that at least the code was running until then.

Moreover, the cause of the error is probably because of what we have entered.

For example, by using printf to debug, we can know what to enter into the module, how to change it to generate an error. Through that, we will understand the generalization of the problem, then try to run the program's steps sequentially to show the specific part of the error.

However, people who do not know how to dig up the problem often for the program running psychologically will run well and check code with the mentality that "it should have run well". They often do not care about the order of the steps of the program, their way of doing things is like searching in the cloud.

In some cases, they will be "silly" for not misunderstanding from where. They do not have a tactic to find the wrong place and will quickly fall into a state that people still call "spinning."

Edit

After the error, before they did anything I asked them to answer this question before "What should we do now?". Specifically, I want them to point out the method of finding the wrong place. I help them build that method by asking questions like "Which part does the code run well to?". After finding a clue, I asked, "What does this information mean?", "Is it necessary to change the method?".

I want them to be aware that they need to dig deep into a decent goal, not in the cloud.

Psychological problems

For a program, error occurrence is a testament to "near completion". Why? Because it often shows us something that we didn't care about, just told us the hypothesis we created was wrong, and showed us the next action we have to do is fix it. We have orientation.

However, for progamers who are not good at deepening the problem, they tend to be "blank" because they always think "It should be good, isn't it?". And then they thought, "I'm wrong, it's all wrong."

It can be said that they never test those that will probably fail, while the highest value of the test is after failing, it will give us some useful information.

I told them to run the test, they often said "The error is sure" and did not do it. When reluctant to do it, the program did not run, they said, "Yes, see?".

The fact that the error in the real environment is not allowed, but in the test environment, no one will complain at all, even useful.

I think they need to experience it for themselves and explain it.

Good habits

Based on the bad habits mentioned above, we can know what good habits are.

• Invest time to read the code and understand the code.
• There is always a tendency to use knowledge to simplify immediate problems
• Not afraid of bugs, always use test code to find information and clues
• Always act with a clear purpose to gradually solve the problem

In addition, there are some habits that I think are as good as:

• Improving tools and automating process chemistry
• Boy scout policy
• Learn some languages
• Learn knowledge in a holistic way

Improving tools and automating processes

Good habits are often supported by good tools. For example, every time I learn a new language, I search for the formatter code of that language.

In addition, I have my coding style – I don't want to press too many keys, so I choose the IDE to automatically enter space for me.

Boy scout policy

There is an organization called boy scout that has the motto: to pick up all the trash on the passages. Also, programmers need to have the motto to fix the error of the code related to the part we do. Of course not reading carefully will not fix it, but even if it is not corrected, reading the code is helpful.

Doing so will naturally become more and more understanding of the code, and the overall code will be better.

Learn some languages

Sometimes problems in this language can be explained while learning another language. And sometimes, a concept that sounds strange is actually just bringing in another language.

Therefore, learning multiple languages ​​will help us develop programming more quickly.

Learn knowledge in a holistic way

As the previous article I wrote, knowledge of the background, the history of language, and some of the three exercises we read somewhere will make the quality of our code increase.

If every day we do not gnaw a little knowledge, no way to understand our own syntax, sample, then knowledge will no longer be knowledge but only stop at the tip because we do not know how to apply them to those other case. Just like that, we'll just run after the tips to solve the problem.

Epilogue

The capacity created by a set of habits so improving habits will increase our ability. That was my thought.

Followed by psychological barriers, improving habits is often not easy. Done, it's not immediately right to reach the superman level.

But never think you're useless. What most influences your end result is whether you think: the way to learn new things is the way to happiness, or not.

ITZone via Viblo.