Where did these 10 problems in a programmer's career go?

[[135640]]

I decided to take some time to sort through the various problems I've seen in my career as a programmer and see where they went.

Surgeon cutting arrow tail

In the article "No Bug, No Life" on my blog, I listed programmers' attitudes towards bugs. Friends who are interested can jump over and take a look.

Programmers often deal with bugs in this way: spend some time to play with the code, oops, can't find the root cause of the bug; spend some more time to see if you can get some sand to raise the embankment (imagine the formation process of the Yellow River embankment), hey, really good, I really found it, I just need to plug some code here and throw a few judgments there, and the bug seems to be gone... Haha, I'm talented, I got it done, I admire myself so much. To be honest, this strategy is to regard oneself as a surgeon and the software as a person who has been shot by an arrow. Because the surgeon does not understand the difference between internal and external medicine and cannot find a way to remove the arrowhead, he can only comfort the patient by cutting off the tail of the arrow, but he does not know that the arrowhead is still in the flesh. If it rots in the flesh, the patient's pain will only be worse.

I can't control it.

Nowadays, we usually develop software in groups. Sometimes we will find that a piece of code checked into the code base is very bad, such as various conditional branches not covering all aspects and not strict logic, such as variable names are messy and lead to poor readability, such as unreasonable class library design violates the Single Responsibility Principle (SRP)... At this time, most programmers will do: forget it, this code is someone else's, I can't control so much, let's do my own thing first...

Some programmers will feel that there are problems with the software system design during the development process, and they will think that it is the responsibility of the system analyst or architect, because I may not be as good as him or I don’t have a better solution or it is unlikely that I will convince him to adopt my solution, so they give up and move forward with the attitude of “I just need to implement my module”...

Sometimes developers feel that something in the product is unreasonable, and the interaction method does not conform to user habits, but because it is the responsibility of the product manager, they are captured by the idea of ​​"forget it, I am only responsible for implementation"...

Sometimes Ah Yuan felt that the product details display interface given by the UI looked inconsistent in color, but he still gave up communicating and made it anyway...

There are many similar situations...

We must know that there are so many of us busy working, and although everyone does different things and has different responsibilities, we are actually building the same boat. No one's work is unrelated to others, and any mistake in any place may result in the boat we build being unable to launch or sinking in deep water and unable to sail far.

Maybe the problem doesn't occur to the user

Many software will have some difficult bugs during the testing process: there is no pattern, the probability is extremely small. Even the operating system released by a large company like Microsoft has to be patched continuously.

As a programmer, sometimes when we encounter a bug with a very small probability, we will decide to ignore it because it is difficult to reproduce. We will convince ourselves, testers, and product managers that this bug may be caused by extreme or improper operation, and users will never use it that way, so it is very likely that it will not appear in the user's place. Even if it does appear, according to this probability, it will only be encountered by very few users, and we still have many other functions that have not been implemented. We cannot let this small probability bug affect the overall progress. OK, it's done. But there is a sword of Damocles hanging over each of our heads.

You should know that the user environment is more complex than the test environment. A bug that cannot be reproduced in the test environment and has a very low probability may be encountered by a user. For this user, it is a big deal if it happens once. For him, there is no such thing as a few thousandths or ten thousandths. He knows that he has encountered it. If you tell him that this bug is really difficult to reproduce and it is really a low-probability event, no matter how sweet your words are, it will be useless. His pain is real and how can he agree with your explanation? If this user is lost, there will be another "lucky" user. In the end, it will definitely be a spark that ignites a prairie fire. Your product reputation will be rotten, and then your product will most likely die.

When I use my mobile phone, I often encounter problems such as App crashing or App stopping running, which gives me a really bad feeling. You absolutely cannot make me accept that this is a harmless, low-probability event. I absolutely cannot accept it emotionally, you know.

Skip the technical difficulties and don’t affect your progress

One of the characteristics of software development is that you will encounter unknown problems at any time. For example, when developing Internet TV products, you may encounter audio and video desynchronization problems. The specific manifestation is that sometimes a movie will be desynchronized within a few minutes of playing, sometimes it will be desynchronized after playing for more than half an hour, sometimes it will not be desynchronized for more than an hour, sometimes it will be desynchronized on this set-top box, and sometimes it will be desynchronized on that set-top box... What should we do about this?

One approach is to acknowledge that this is a technical problem that cannot be solved in a short period of time. Don't let it affect the progress. Skip it and do other things first, and then take time to solve it later.

This practice is very common, and its consequences are also common: the project progress is still helplessly dragged down by this problem.

Others are like this

Sometimes you will encounter this kind of development team: poor execution, low output rate, uneven busy and idle time. As a socialist youth who originally pursues progress, you often feel that this situation is abnormal at first and want to change it, but after a long time you find that you, an ordinary programmer, can't change anything. If you insist on doing this thing or persuading that person, it will make the relationship stiff. All kinds of worries or practices make you realize that you are not the role that can change the face of the team. What should you do?

The reality is that: forget it, just turn a blind eye and take care of myself. The more unacceptable result is: everyone is just getting by, so I don’t need to work so hard, so I gradually relax and get by.

It is a very sad and helpless fact that we are gradually approaching the lower limit of productivity.

We will catch up later

Most software projects are delayed. Many projects seem to be delayed as they are being worked on. However, many project managers and developers on many teams behave in a fairy-tale style: as long as a certain problem is solved, as long as someone works overtime to catch up, the delivery date will be met in the end...

The result...

What's the point of working without bonuses or salary increases?

Not every software company can make continuous profits, give out huge bonuses, or increase salaries every now and then. The reality is that quite a few companies are struggling to survive, unable to pay out substantial bonuses or increase salaries as promised. How would a programmer think and act when working as a developer in such a company?

The company's performance is not good, what does it have to do with me? If there is no bonus, no salary increase, why should I work so hard? Why should I work as hard as before? Just look at it.

This is the true mentality of some programmers, and I have had it before. You know, when we work in an environment where we can't see the future and there is no financial incentive, it is inevitable that we will become discouraged and indulge ourselves with the flow. But later I realized: you cultivate yourself by working for the company on the platform provided by the company, and you get much more than just a salary. The experience, training, and growth are all yours, and no one can ever take it away from you; time is your own, and you can never get it back if you waste it; no matter when, we are working for our present and future, not for the company or the boss. We are not just a person who gets paid to do things for others. If we stay at this level of consciousness, then we must be killing our own growth opportunities and wasting our precious lives.

And XXX

Due to the limitations of experience, ability and vision, sometimes a problem seems to be beyond the ability of programmers, making us feel that it is useless to spend more energy, so we don’t plan to study it anymore, telling ourselves: Forget it, there is still the technical master Yang Guo, the technical manager Guo Jing, and if it doesn’t work, there is still the technical vice president Feng Qingyang. If it doesn’t work, the company will find a way, anyway, there are people behind us...

Anyway, I had this thought before I was a project manager, and I still had this thought after I became a project manager. I even thought about it when I was a department manager. Even the project director might have had similar thoughts... until I became a technical partner of a company, and there was no one left to pick up the mess I left behind...

Sigh..., what an uncomfortable situation!

What I want to say now is that no matter when, you should regard yourself as the first line of defense and hold your ground. Sometimes one man can block a thousand men, but sometimes one person giving up may cause the whole line to collapse and lose thousands of miles of territory. We must try every means to solve the problem. This problem ends with me. I must burn my boats and leave no way out.

It's not my responsibility anyway.

Inevitably, programmers will encounter project delays. Some people will review the various problems during the project execution, including reflecting on their own shortcomings, sorting out problems in team collaboration, and figuring out whether there are any errors in task scheduling and progress tracking... This is a positive approach, and I think every programmer should do this, but the actual situation is not like this. A considerable number of people will think: I have done what the leader arranged, what can I do, this is everyone else's business, it is likely that the project is not managed well or the requirements keep changing, it has nothing to do with me...

Forget it, change the environment

Programmers change jobs very frequently. Some change once every two years, some once a year, and some even change several times a year. What is the real reason why they work so frequently?

Sometimes it’s because the work is not going well, and I feel that I have a lot of ideas but the leaders don’t pay attention to them; sometimes it’s because I feel that the team atmosphere is not good, I can’t make everyone work with peace of mind, and I can’t maintain a positive attitude, and I can’t grow in both technology and position; sometimes it’s because I feel that the product has no hope and can’t see the future, and the more I work, the more confused I feel; sometimes it’s because the super popular beauties in other companies throw me sour and cool hydrangeas; more often, oh my, that company is really fucking rich; of course, sometimes I just inexplicably feel that I should move to another place...

If money wasn't the reason, you still decided to change your environment. You think this might be better... Is it really so?

If you finally decide to change jobs, it must be that something went wrong that made you unable to tolerate the current situation, but you must ask yourself: Is the problem I am facing now a problem with the company, team, product, or myself? Will similar problems avoid occurring if I change the environment?

In other words, when we decide to change jobs, we need to conduct in-depth analysis and ask ourselves whether it is due to external reasons that we can no longer tolerate the current situation, or whether we feel from the bottom of our hearts that we need to make changes and find new directions. We need to understand our expectations and what we want, so as not to get out of the mud and fall into the pit of fire.

As a programmer, it is inevitable to encounter various problems in the process of development and work. Everyone has his own way of dealing with problems. No matter which way you take, the problem will not disappear automatically. If the measures you take are in line with the mode of "hoping that the problem will disappear on its own", you must pay attention that this is a very low-level and very destructive habit. If we use this mode to "solve" problems many times and over time, we ourselves will gradually become a problem: because we are actually avoiding problems and refusing to grow and mature. We hope to jump to an environment with few problems and work happily, but such an environment is no different from an utopia and a paradise. They only exist in imagination. If our inner self does not change and we cannot cultivate the ability to accept and solve problems, we will be exhausted on the road of searching but will never find such a place. In the end, we will despair and finally choose the seemingly most impossible result of "giving up on ourselves".

Since various problems are inevitable, the only feasible thing is to face them and solve them.

Software development is full of problems and difficulties. Only by accepting this premise and understanding the essence of life and work can our work and life become better.

We often lack patience when facing problems. We want to solve them immediately. If we can’t solve them after trying here and there, we just want to leave them there, step over them or take a detour. We always want to get out of it as quickly as possible and shorten the time we spend with the problem. We are unwilling to spend enough time to deal with this uncomfortable feeling and analyze the problem calmly. Because facing and solving problems directly requires great courage and excellent tolerance to bear the pain that breaks your heart.

However, we have to face it. If we choose to escape, it will only get worse. Problems will follow us wherever we go. To paraphrase a classic line from a Hong Kong gangster movie: "You will pay for what you have done sooner or later." It is the same for us. When we encounter problems, we cannot escape. The more we escape, the more problems we will have. In the end, there will always be a moment when you will have to pay for what you have done.

In this case, why not suffer earlier, solve problems earlier, and rise from the ashes earlier? Let us accept the life mode of "bitter first, sweet later" and face problems calmly. Problems can open our wisdom and inspire our courage. By working hard to solve problems, our thoughts and hearts will continue to grow, and our minds will continue to mature. Our ability to solve problems will continue to improve. We will eventually be tempered into steel by facing problems, achieve ourselves in chaos, and finally achieve a unique self, find our own way to live out our lives, and this is success.