27 Expose the Problem Early: Why are You Always Blamed? #

Hello, I’m Zheng Ye.

Today, I am going to discuss something that often frustrates many programmers: why you work so hard but still get blamed. Before discussing this issue, let me tell you a little story.

One day, the programmer Xiao Li received a new task. The system needed to improve its performance. Previously, all orders were stored in the database, but due to many canceled orders, repeatedly accessing the database negatively affected the performance of the actual transaction process. Therefore, the technical leader Lao Zhao decided to cache the orders first.

This involved a technical selection problem, so Lao Zhao found a few middleware tools that could serve as a cache. To provide an explanation to everyone, Lao Zhao decided to have Xiao Li conduct a test on these middleware tools, present the test results, and let everyone evaluate them together. Xiao Li was excited because he enjoyed working on such technical tasks and could play with new things.

Lao Zhao asked him, “How long will it take?”

Xiao Li said, “About a week!”

Lao Zhao agreed, “Just a week then. But I have a requirement: it should not only test the middleware, but also involve the business logic.”

“No problem,” Xiao Li replied readily. Concerned that Xiao Li might do too much, Lao Zhao specifically reminded him to only test the simplest order placement and cancellation scenarios.

When Xiao Li started working on the task, he found that it wasn’t as easy to involve the business logic as he had thought. The original code was highly coupled, so in order to incorporate the new middleware, he had to separate the order placement and cancellation processes. These two operations were spread out in many places and required some adjustments first.

As a result, Xiao Li had to work tirelessly day and night. As he delved deeper into the work, he realized that it was like a bottomless pit because more than half of the time had already passed, and he hadn’t finished adjusting his code.

At this point, Lao Zhao came to ask about his progress, and Xiao Li said with a worried expression, “I probably won’t be able to finish it.” Lao Zhao was greatly shocked, “Isn’t it just testing a few middleware tools?”

Xiao Li also looked aggrieved, “Why do we have to involve the business logic? I’ve been spending all my time adjusting the code so that I can add the middleware calls.”

Lao Zhao was also puzzled, “Why did you do that?”

“Didn’t you say to involve the business logic?”

“I said to involve the business logic! But you could have written a program for order placement and cancellation yourself, just keeping the main process consistent.” Xiao Li felt helpless and silently cursed in his heart, “Why didn’t you say that earlier?”

Yes! Why didn’t you say that earlier? But, I would like to say that it was not Lao Zhao who should have said it, but Xiao Li.

Who knows there is a problem? #

Let’s analyze where the problem lies. In this story, Xiao Li and Lao Zhao also have a “starting with the end in mind” mindset, and they set a goal at the beginning, which is to do a new middleware test with the business.

Xiao Li can be said to be very clear about the goal, but in the process of doing it, Xiao Li discovered a problem. The original code was very complex, and the amount of modification work was large, so the work may not be completed on time.

Up to this point, there is nothing wrong with all the actions. But then, Xiao Li, who found the problem, chose to continue working hard until Lao Zhao came to ask, and reluctantly Xiao Li exposed the problem.

In Lao Zhao’s opinion, this is not a big deal, just adjust the plan. But Xiao Li feels resentful. In his opinion, Lao Zhao obviously has a simple solution, why didn’t he say it earlier, causing him to waste so much time.

But looking back, from Lao Zhao’s perspective, how did he think? “My requirement is to run with the business. The ideal solution is to be with the system. If you can handle it, this is definitely the best; if you can’t, then the next best thing is to write a separate solution. I can accept that too.”

Can you see where the problem lies? There is no problem with Lao Zhao’s choice. The problem lies in the fact that when Xiao Li found that he might not be able to accomplish the task, his choice was to continue working silently instead of exposing the problem and seeking help.

As a programmer, overcoming technical difficulties is an important part of our work, so once we encounter difficulties, we will subconsciously throw ourselves into it. But is this really the best approach? Not all problems are worth solving as technical difficulties.

Encountering problems at work is something that can’t be more normal. Even if we talk about various work principles, it is inevitable to encounter problems at work.

Since it is a problem you encounter, you must be the first person to know when the problem occurs. If you don’t expose the problem, others will not be able to help you even if they want to.

If Lao Zhao didn’t ask, what would be the result? Xiao Li would definitely continue to go on his way. And then, when the time is up, the task is not completed.

More importantly, project plans are usually interconnected. Xiao Li’s failure will affect the subsequent parts of the project, and it is almost inevitable that the entire project will be delayed. This is a situation that many project leaders are most afraid of.

Therefore, although from Xiao Li’s perspective, this is only a matter of personal work habits, in fact, people in critical positions may bring risks to the project. If Xiao Li’s problem is discovered in advance, there will be much more room for adjustment.

The best solution when encountering problems is to expose the problem as soon as possible. In fact, you are not unfamiliar with this principle because you may have used it when writing programs.

Fail Fast #

There is an important principle in programming called Fail Fast. What does this mean? It means that if you encounter a problem, report it as early as possible.

Let’s take an example. I have created a query service that allows you to retrieve some information based on a month. There are 12 months in a year, and the query parameter ranges from 1 to 12.

Now, where should the parameter validation be done? If we do nothing, the query parameter will pass through the system and reach your database.

If the parameter passed is valid, there won’t be any issues, and the query will return a normal result. However, if the parameter is meaningless, such as passing in “13,” the query will still be sent to the database.

In fact, many careless systems work this way, and once a problem occurs, it is difficult to determine the root cause.

In this extremely simplified example, you can easily see that the problem lies in the input parameter. However, as the system grows in scale and requests come from different sources, all of these requests will eventually converge into the database, making it difficult to identify their origins. This difficulty increases significantly when the system is heavily concurrent, as it becomes challenging to trace the request’s source from the logs.

You might say, “To easily identify the source of the requests, can’t we add a unique request ID to each request?”

You see, this is how systems become more complex. I often make fun of such solutions, joking that they create difficulties even when there are none. Of course, even if we were to add a request ID in the future, the reasons for doing so would not be the same as in the present.

In reality, solving this problem is quite simple. Anyone with some experience would know that parameter validation should be done at the entry point, and any invalid requests should be rejected from proceeding further. This approach, which intercepts foreseeable failures from the outside, is called Fail Fast. It’s not scary to have problems; rather, it’s important to let failures occur as early as possible.

The previous example was straightforward. Let me give you another one. What would you do if an important parameter is missing from the configuration file, such as the maximum database connection count? Many people would choose to provide a default value, but that is not the Fail Fast approach. If it’s an important parameter, it should raise an error when it is missing. That’s what Fail Fast is all about.

In fact, Fail Fast may seem counterintuitive. Many people, in the name of building robust systems, accommodate strange issues instead of exposing them. This may hide bugs in the system.

We all know that using debugging to locate problems is the most time-consuming and laborious approach. So, don’t be afraid to have problems. If there are issues, report them as early as possible.

By the way, in the previous example, transparently passing parameters also has a few additional issues. First, it adds extra pressure to the database. If someone uses meaningless queries as an attack method, it can overwhelm your database. Additionally, there is a security concern. Some SQL attacks exploit this mindless passthrough behavior.

Overcoming Psychological Barriers #

For us, it is easy to accept exposing problems early in the program. However, exposing our own problems at work is a big challenge because we also face a psychological issue: will it make others think we are not capable.

To be honest, this worry is unnecessary because everyone can see clearly whether someone is strong or weak in their abilities. Only when you solve the problem will others think highly of you. Covering up the problem does not improve your image in the eyes of others.

Since it is a problem, it cannot be hidden. Just like the story of Xiao Li at the beginning, even if he tries to hide the problem, it is still impossible in the end. The problem will come out, and at that time, others’ evaluation of him will only be worse.

Instead of exposing problems early, there is a further way of working, which is to make your work transparent and let others understand your work progress and your thoughts as much as possible.

If you can achieve this, when other people encounter things related to your work, they will provide you with information and help you do the work better. Of course, this approach presents a greater psychological challenge than exposing problems early.

From the beginning of this column until now, we have discussed so many principles and practices, but actually, most of them are telling you to do things in advance.

On one hand, this is considering the perspective of software change cost, and on the other hand, it is considering the perspective of interacting with people.

The more you do in advance, the more space and opportunities for adjustment you leave for others. The cost of problems arising at the last moment is too high, too high for people to bear.

Summary Moment #

Today we discussed an important work principle: moving things forward and exposing problems as early as possible. Many of the things we discussed earlier revolve around this principle, such as determining the desired outcome first, conducting simulations beforehand, and so on. The earlier we discover a problem, the lower the cost of solving it, not only in terms of solving the problem itself but also in terms of its impact on the overall team plan.

On one hand, we need to use the “begin with the end in mind” and “task decomposition” approaches to find problems early; on the other hand, during the process of work, if we can’t complete a task within a limited time, we should let others know as soon as possible.

In the context of programming, this principle is reflected in the concept of “Fail Fast”. Many programmers, due to not adhering to this principle, constantly compromise and end up making the program more and more complex, which leads the team into an endless quagmire.

The principle itself is simple, but the real challenge lies in overcoming our own psychological barriers. Many people tend to subconsciously hide problems, but please trust your teammates; everyone is intelligent, and problems cannot be hidden forever.

If there is only one thing you remember from today’s discussion, please remember this: Move things forward and expose problems as early as possible.

Finally, I’d like you to reflect on which mistakes you could have avoided if you had followed this work principle. Feel free to share your thoughts in the comments section.

Thank you for reading, and if you found this article helpful, please consider sharing it with your friends.