cover
Why write this article?
I find that many programmers don’t want to be a programmer all their lives. My programmer friend also told me that when he saw a programmer in his 40s coming to the company, he felt anxious, because he didn’t want to sit in front of a computer and write code when he was in his 40s. After listening to, I don’t know how to answer?
This kind of thinking creates a resistance that prevents us from becoming better programmers. Of course, the idea may be that it’s no longer tempting to be a good programmer. So, if it’s not tempting, why are you still programming in pain?
I’m not writing this article to encourage you to change careers, but to say that programming is more than just programming.
No matter what industry is engaged in, no matter what major is learned, in fact, they are interlinked. Programming, for example, should not only look at the programming itself, but also see how to improve our cognition in the programming process. Or how can programming improve our cognition?
According to Munger’s grille theory, I think it’s called transboundary learning. That is to say, different academic majors have their own ideas. Mastering these ideas and integrating them into our thinking grid can help us analyze problems in multiple dimensions and make more rational decisions.
Now that I have nearly three years of programming experience (no more, no less), I would like to share with you some of the mental improvements that programming has brought to me: Here I have three sections, which are as follows:
- Programming process
- Program coding process
- Program test procedure
Programming process
There may be no design process at the beginning of the programming process. But it becomes clear that without good design, the program will be difficult to maintain in the future. You don’t even have to wait until the maintenance phase to find all kinds of accidental problems in the testing process. The root cause of accidental problems is not accidental, but caused by procedural flow disorder. The fundamental reason for thinking about this problem lies in a mode of thinking: a characteristic of a program is to specify that an input must have a corresponding output. The program is pure. So a bad output must come from a bad input. And the program is executed one after another, so the wrong output must be the result of something wrong with the process. This way of thinking helps us test our programs.
That’s one way of looking at the world:
If we want to solve the problem, we need to find the root cause of the problem.
Just as we analyze source code for the same purpose, “know the is and know the why”, believe that everything works properly has its internal principles.
The contingency problem may be due to:
- It may not actually work
- The boundary condition you rely on May be just an accident, and it may behave differently in different situations
- Maybe you don’t even know why it works…
The way to solve the contingency problem is to design the program well before coding. The main design includes:
- Program structure design
This kind of design can enhance our abstract thinking. This kind of structural design is often referred to as modularization, componentization and other architecture-related content. It requires us to take a complex thing and break it down into concrete, implementable chunks. It’s also a mindset: break a complex problem down into solvable problems. This mindset can be applied to other areas as well.
How does it work?
When you encounter a difficult problem, try to break it down to the point where it can be done, and then solve it one by one. Modular and componentized architectures are designed to understand lotus root. The purpose of decoupling lotus root is to facilitate management. This mode of thinking can be applied to management, which is what we often see. From state management to corporate management.
- Program flow design
Simply put, how to make the program run normally and controllable.
The first is how to ensure normal, such as: handling synchronous asynchrony problem method. Let the process be normal, the correct output that is not accidental.
Controllable, adding and changing requirements in the future can also ensure the normal process. There are various design patterns involved here, as well as some programming languages (one of the things that I think improves efficiency in many programming languages is that they are designed to make programs more controllable, for example: In functional programming, functions, as first-class citizens, can be passed like ordinary variables, saving us the trouble of designing something complicated, because every extra line of code we write may create another bug.)
Application in other fields:
For example: factory assembly line design, all kinds of procedures for handling. Normal is similar to the assembly line can run normally; Control is like adding one link or removing one link in the middle of an assembly line without interfering with the others.
Program coding process
With the design process, the coding process should be done according to the design contract. Of course, design is not guaranteed to be perfect, so in the process of coding if there is a problem with the design or the design process did not think of the scene, should update the design (the design will often appear imperfect design problems at the beginning of the design).
In the process, you can sharpen your mind. In other fields, too, such careful thinking reduces the chance of mistakes.
The testing process
We programmers know that no matter how elegantly written or streamlined the code is, it needs to be tested. After testing, we get a bunch of bugs, which often gives us more reflection. Where does the confidence before testing come from? Or, I knew there would be so many bugs, because I’m a bad writer. And then you have to solve it one by one, BUT it’s not that easy. In the process of solving a bug, you find that if you don’t solve a problem correctly, that solution will create a new problem. Or it may be that the problem is not defined correctly. So, the definition of a problem determines the solution to the problem, and the solution determines the source of new problems. So “we need to anticipate the consequences of the implementation of the plan.” But even if we anticipate the consequences, other problems may arise later. But even if you can never be sure that you have found the right definition of the problem, never stop looking for it
Is this also a kind of attitude of life? Back to the beginning, why don’t you want to be a programmer all your life? What is the nature of the problem? Is it because programmers are tired? Or do you think being a programmer all your life is unpromising and the salary is too low? Or do you feel like you should be doing something big and that being a programmer is too small? The essence of the problem is the difference between ideal and reality. How to solve the problem depends on how you define the problem.
I think programming can really improve us programmers, and how much you can improve it depends on how much you care about it. Incorporating programming thinking into our own thought grid will help in any future industry, so it’s all about treating your code well. Ha ha ~