Talking about Programmers Series: Oh, I am a ghost problem!

Programmers (software development engineers) have many nicknames, such as "programmers", "code farmers", "code workers", "code monkeys", etc., which are all the result of self-deprecation by humorous monkeys. These nicknames point out an indisputable fact: programmers have to write code. However, the issue that is obscured is: the purpose of programmers writing code.

A programmer's job is to solve problems

The purpose of software is to solve problems in life and production, bring convenience to people, and improve productivity and efficiency.

Programmers produce software, so the ultimate goal of programmers is to use software to solve problems in their own and other people's lives. This is the programmer's responsibility, and writing code is just a small step, a very, very small step, in the complex journey of solving problems.

Software development is difficult

Programmers are born to solve problems, but in reality, programmers need to face many problems during their work. Problems make programmers suffer. After one problem is solved, new problems will appear immediately, making programmers continue to fall into endless pain. Software development is actually a process of constantly facing and solving problems. So, from this perspective, software development is full of hardships.

Considering the entire process of software development, there are probably several types of problems:

Product definition problem

Architecture design issues

Deviating from the requirements

Software Bugs

Maintenance Issues

Communication issues

We don’t need to elaborate on the specific issues, as they are not the focus of this article. The focus of this article is how to face the problems. First, we need to look at several realities.

Ostrichosis

[[132728]]

Ostriches bury their heads in the sand when they feel threatened.

OK, that's one way of avoiding the problem.

Many programmers also adopt a similar ostrich strategy to avoid the problems they face and the pain they need to endure. If the problem cannot be solved, they will procrastinate and postpone it, pretending not to see it. Maybe by then a miracle will happen and the problem will disappear.

This is all self-deception. Although the ostrich strategy allows programmers to temporarily avoid pain, they have to endure two other deeper pains: an unpromising delivery period and endless maintenance.

Apply plaster

Another common strategy for dealing with problems is to apply a plaster, which is more common when solving software bugs.

To be honest, the quality of software is closely related to the individual programmer. Those who pursue it will write concise, effective, and logically clear code, which is easier to analyze and solve when problems occur; those who are perfunctory will just make it run casually, and it will be very difficult to deal with bugs, and they can never find them. The best ones can only guess that there is something blocking the road and put a plaster on it. Over time, the code will become extremely ugly, with dog-skin plasters everywhere. If you want to uncover it and see what is inside, you have no idea where to start. It is a dream to say that you can fly through the fog and see the code clearly.

Kidnapping a product manager

Some problems come from the difference between development implementation and product requirement definition. At this time, it depends on the result of communication between development and product: either the product compromises and defines a problem as usage habits or something so that it can be solved later; or it is sent back to development for re-implementation.

I have seen many compromises, some of which were really important. I think in most cases, programmers use their technical advantages to protect their own deviations in understanding, and ultimately kidnap product managers. This is a fact that programmers are unwilling to see and unwilling to admit even if they see it.

Accepting Suffering and Achieving Transcendence

[[132729]]

Fortunately, as long as programmers accept the fact that software development is full of hardships, they can free themselves from the hardships and achieve product and self-transcendence. It is in the process of enduring pain and solving problems that programmers grow and mature in skills, experience and mind. If we are afraid to face problems, afraid to endure pain, and want to escape, then although we can escape the pain temporarily, we will suffer more serious consequences such as user complaints, product failures, company bankruptcy, etc.

If you don't solve the problem, you become the problem. As programmers, this is something we must keep in mind.

Faced with the quagmire of problems, it is impossible to jump over them. Our only choice is to cross them.

The benefits of facing problems head on

Programmers are all adults (are there child laborers?), and should be able to face problems and pain. But the reality is that as adult programmers, they are not necessarily mentally mature, and sometimes they are still like children, unwilling to face and solve problems. This is a problem of ability and a psychological problem, but from the perspective of an observer, it is ultimately a problem of ability.

Let’s define competence as: problem-solving attitude, skills, experience and the desire for self-learning, all combined together is competence.

Facing problems head-on will improve your abilities. This is the biggest benefit.

Avoiding problems will lead to the loss of opportunities for advancement and hinder self-growth. But we often do this because, on the one hand, we tend to think that what we are doing is not our own, but the company's and the boss's, and we still have a way out; on the other hand, accepting and solving problems will challenge our skills, experience, and cognitive habits, which is heavy and painful. There is a point in human nature that people are afraid of the heavy and take the easy way out. To put it bluntly, they just want to be comfortable at the moment.

Problems in the software development process will not disappear just because programmers avoid them. Problems will always exist, and old problems will breed new problems, leading to more and more problems that exceed the acceptable range of the product, team, and company, and eventually erupt at some point.

I have had this experience many times. My ostrich syndrome made me unconsciously postpone the problem. I always felt that the final delivery deadline was still early. I always held unrealistic fantasies and lied to myself that as time went by, the problem might disappear by itself or some situation would make the problem no longer a problem. But the reality is that the project was constantly delayed, and the test conclusions were always "not up to the release standard". In order to go online, we kept working overtime, which made everyone tired and helpless. The pain during the period was even desperate. We were all overwhelmed by the problems and could not see the day to get out of it. At this time, I really regretted not exposing and solving the problem early, and sometimes I warned myself that the next version and the next product must not be like this. But the fact is that once a vicious cycle is formed, the inertia is very large and it is difficult to break it out. This will make people bored, unbearable, and restless. After trying many times, when I find that I can't change this vicious cycle in the current environment, I tend to change the environment and start again. This is also a common reason for changing jobs.

In order to avoid this situation, the best way is to overcome the desire and habit of taking it easy and escaping, accept the problem, embrace the pain, kill the Buddha when you see the Buddha, kill the ghost when you see the ghost, and solve various problems in the best time. Don't worry that you are not good enough to solve the problem. People's abilities are improved by doing things beyond their abilities. This is also the key to self-cultivation: set goals that are one level higher than your abilities.

Problem Solving Practice

Now that we have relaxed our minds, the next step is to solve the problem. Every programmer encounters different problems, and the specific methods of solving the problems vary greatly, but there are still some guiding principles for reference.

Effective communication

Good communication skills are the most significant and important characteristic of an excellent programmer.

If you can’t communicate effectively with others, it’s hard to create a great product.

Programmers need to communicate with product managers, the market, and customers about requirements, design, and other issues. This is unavoidable. Although some programmers choose software development to avoid dealing with people, the cruel fact is that in today's military environment, "turning a deaf ear to the outside world and burying your head in keyboards" will not produce good things.

Programmers also need to communicate with development colleagues and testers, which is really a lot of communication...

If we can express our ideas accurately and correctly understand the intentions of others, we can avoid many problems in the early stages of the product.

Expose problems early

The earlier the problem is exposed, the better, and the lower the cost of solving it. If a strange problem pops up near delivery, it will crush the poor programmers, who will be more inclined to avoid and cover up the problem. Sometimes, when they are really at their wits' end, they will work together with the testers and product managers to convince themselves to change the nature, scope, and severity of the problem, and then comfort each other, and it will seem that it is not a problem anymore.

From the perspective of the software development process, the following practices will expose problems as early as possible:

Requirements Review

Design Review

Peer code review

Continuous Integration

Iterative testing

Correctly understand the problem

No matter how effectively you communicate, no matter how many measures you take to expose problems as early as possible, unexpected things will still happen. This is the uncertainty of software development, and it is a fact that we must accept. For programmers, we must remember that you are producing code and you are also producing bugs. We must have a correct understanding of this matter. When problems arise, we should not despise them, avoid them, hide them, or be pessimistic. We should face them realistically and solve them realistically.

If we fail to correctly understand the problem, sooner or later, we ourselves will become the problem. At that time, we will be left out and eliminated.