Programming cognition: think more, code more, test more

Every programmer has his or her own unique way of programming. In his career as a programmer, Ben Teese, the author of the original article, gained some insights into the coding process: think more, code more, and test more. The process of building software is a continuous learning process, and a good strategy follows plan-execution-reflection.

In my career as a programmer, I came across the following program coding process; during this period, I was also exposed to many other theories and ideas, but I still think this is the most suitable for me.

The general pattern is like this:

a: Think a bit

b: Code a bit

c: Test a bit

Come again Go to Step 1

Step 1: Think more

How many friends think that the rhythm of the crackling keyboard represents the level of program productivity? If you think so too, I hope you can put it aside and think about it calmly when you encounter a problem.

If you feel like you don’t know where to start when you’re thinking about it, you might as well ask yourself: What exactly do you want to do? Once we have calmed down, the answer to this question may lead us to orient ourselves or reconsider our approach to the problem.

Next, I would suggest thinking about this question: Have you complicated a simple problem? Trying to solve a problem in the simplest way is what every programmer should strive for. But when we have enough knowledge, is it overkill to use such a simple method to solve the problem? If we think about it this way, perhaps what we will encounter in the end is a pile of increasingly complex problems. Try to change your thinking. What is the worst result of using simple methods to solve the problem? Is it worse than not being able to solve the problem? It’s important to learn to get beyond the point of no return.

Therefore, when you encounter problems, you might as well ask yourself the above questions. And when I reach a bottleneck and a dilemma, I will consider moving to the next step.

Step 2: Do more

How many friends think that the rhythm of the crackling keyboard represents the level of program productivity? If you think the same way, I hope you can put it aside and think about it calmly when you encounter a problem.

If you feel like you don’t know where to start when you’re thinking about it, you might as well ask yourself: What exactly do you want to do? Once we have calmed down, the answer to this question may lead us to orient ourselves or reconsider our approach to the problem.

Next, I would suggest thinking about this question: Have you complicated a simple problem? Trying to use the simplest solution to a problem is what every programmer should strive for. But when we have enough knowledge, is it overkill to use such a simple method to solve the problem? If we think about it this way, perhaps what we will encounter in the end is a pile of increasingly complex problems. Try to change your thinking. What is the worst result of using simple methods to solve the problem? Is it worse than not being able to solve the problem? It’s important to learn to get beyond the point of no return.

Therefore, when you encounter problems, you might as well ask yourself the above questions. And when I reach a bottleneck and a dilemma, I will consider moving to the next step.

Step Three: Test More

To be honest, this step is not only not as interesting as coding, but also very annoying.

However, for projects that do not have a testing link, I suggest that they be carried out in personal open source projects; because if it is released without testing, not many people will dare to use it.

Besides the annoyance, testing may also be the most complicated part of the coding process. Unlike programming where what you see is what you get, finding the optimal testing solution can take twice as much effort. Testing is characterized by uncertainty.

Some friends adopt a test-driven development method. My opinion is: This is good, but please stick to it. For me, I would also use this approach if it was a highly algorithmically focused project.

Step 4: Do it again

Solving the problem is often not achieved overnight, and the cycle and feedback after it is crucial. The process of building software is a continuous learning process, constantly learning to strengthen technology and problem-solving capabilities. A good strategy is to follow a plan->do->reflect process.

Summary

The above are some of my personal insights on the coding process. Today, with the introduction of more and more convenient development tools, the above four-step process has become smoother. So please give it a try.