07 Why are you still stuck in the “pit” despite solving many technical problems? #

Hello, I am Zheng Ye.

In the previous content, I introduced several practices that reflect the principle of “starting with the end in mind,” including how to define the Definition of Done (DoD) to determine if a task is completed, how to determine the acceptance criteria for a requirement, and the Lean Startup concept of verifying if the product features given by the product manager are reasonable.

After understanding these concepts, you might be wondering: why should I care about all these things? I am a programmer, shouldn’t I just focus on writing code quietly? Why should I worry about how well others are doing their jobs? If I take care of so many things, am I still a programmer? Where is my “end” in all of this?

In today’s discussion, we will talk about this question that has confused many people. Because only when we step out of the role of a programmer and look at the bigger picture, our work will become more effective.

“Looking Out for Oneself” is not a Good Thing #

In today’s collaborative world, looking out for oneself may not necessarily be a good practice. Let me tell you a story that happened to me.

Once, my team was developing a data service layer to be used as an infrastructure for our core business systems. Shortly after starting the development, one of my team members approached me and said that he was facing difficulties and was stuck on an important issue - he couldn’t figure out how to allocate IDs between multiple instances.

After hearing this, I was a bit confused. Why was he considering this issue that was unrelated to the functionality? He explained that because our system needed to ensure message continuity, he had designed message IDs so that downstream systems could identify if any messages were lost.

He was right about this, but what puzzled me was why he needed to coordinate between multiple instances. He gave the reason that by doing so, we would be prepared for future scenarios where multiple instances might be involved. However, the fact was that our current requirement was to handle a single-instance scenario.

After understanding the situation, I immediately told him to focus on the first step. I clarified that we should not worry about future scalability at the moment. If there is a real need in the future, we can address it then. He agreed willingly.

The truth is, this colleague is extremely talented in terms of technical abilities. If I hadn’t intervened, he might have come up with a perfect technical solution. However, just as he had worried, it would have taken up a lot of his time. But is that really what we wanted? In terms of our current goals, there was no such need.

We have always emphasized “starting with the end in mind.” The so-called “end” is actually our goal. Although we work together towards a common objective, when it comes to a specific problem, each person may see the goal differently.

The reason I was able to pull my colleague out of his state of confusion was because I saw the need, whereas he saw a technical problem that needed solving. Therefore, we had a fundamental difference in our understanding of the goal.

You might think that the difference between me and my colleague lies in our roles - I have a more important role in the project, and my working hours are longer than my colleague’s. But have you ever thought about where the differences between different roles lie?

Differences in Roles #

As a working professional, everyone has a desire to be recognized and to climb the corporate ladder. If you are given a chance to take one step up the ladder today, such as going from being a generalist on a project to becoming a key player, or from being familiar with project details to being appointed as the project lead, would you be able to handle it?

What do you need to add? In other words, what are the differences between you and the person in the position one level above you?

You might say that they have been in the role longer, or that their main job is to attend meetings. But if that’s the case, does that mean as long as you fulfill these conditions, you can reach their position? Obviously not.

The real difference in the work between different roles lies in the different contexts.

What does this mean? Taking the previous question as an example, if you are a generalist on a project, you can only focus on a specific task, while the key player sees the entire system in their mind. Although the code you write is the same, you see the trees while they see the forest; they are better able to think globally.

Similarly, the work of a project leader includes coordination within the project team, but also involves working across different project teams and considering the interaction between your team and other teams. So, their work context is between different groups, including technical and product aspects.

Moving up to the next level, a department manager needs to coordinate various teams within the department and also consider coordination between departments. And a company executive needs to consider a context that even goes beyond the company itself, and includes the industry as a whole.

You may ask, okay, I understand that there are differences in the context of different roles, but what does that mean for me?

Let’s look at it from a work perspective. Going back to the story I shared earlier, you might have noticed that I didn’t solve the problem by relying on technical ability, but rather by bypassing the problem based on understanding the requirements.

The reason I can do this is because I am working within a larger context. Similar stories have happened countless times in my career, and many problems that frustrate programmers are not really problems when looked at from a different angle.

Technology is a powerful tool, and programmers believe that technology can change the world, but not all problems need to be solved with technology. There is a saying, “If all you have is a hammer, everything looks like a nail.” Spending a lot of effort to solve a problem that may not even be a problem is often a blind spot for many programmers.

The reason it is called a blind spot is because many people simply cannot see it, and the reason they cannot see it is due to a lack of context, in other words, they only see the problem from a programmer’s perspective.

By asking more “why” questions and discussing whether there could be alternative approaches, many confusions can be resolved. And to be able to think about such questions, the premise is to step out of the programmer’s mindset and expand the context of your work.

Although I am not a key player on the project, it doesn’t prevent me from gaining a deeper understanding of the overall system; although I am not a project manager, it doesn’t prevent me from understanding how they manage projects; although I am not a product manager, understanding the design principles of a product can still be helpful to me.

When you have a comprehensive understanding of the entire software development life cycle, what you see is no longer just a single point, but a trajectory. When discussing problems with others, you will have more confidence. Compared to those who only think from a single perspective, you will have the ability to attack problems from multiple dimensions.

Now you know why your work always seems to have flaws in the eyes of your boss! Yes, the different work context leads to significant differences in the perspectives. Single-dimensional thinking appears to have numerous loopholes in the eyes of multidimensional thinkers.

When you expand the context of your work, your goal is no longer limited to a single point, but you will think from a higher dimension and consider whether there are simpler solutions to solve the problem. Many problems that are difficult to solve at a lower level become non-issues when placed in a larger context.

In my career, I often encounter situations where under a specific product design, I feel that the technical solution is somewhat inelegant, and by simply tweaking the product design, the technical solution can be significantly improved. In such cases, I first ask the product manager if it is possible to make adjustments, as long as it is not a critical area. Product managers usually agree to my requests.

Working in a broader context #

Expanding the context of one’s work allows for not only personal growth but also the opportunity to plan for career development. In this regard, I would like to share with you a case that didn’t go very well, which is my own story.

I used to be a dull programmer, restricting myself within the context of coding in the first few years of my career. I enjoyed the quietness of coding and getting excited for a long time when I figured out how a system works.

My transformation began with an unexpected opportunity. At that time, there was a consulting project, and the colleague in charge of it had some personal matters to attend to, so I was sent as a replacement.

Once I started working on the consulting project, my usual routine was completely disrupted because the problem at hand couldn’t be solved by simply making the code work. It required more importantly, interacting with people.

For a long time, I was in a state of agony. I am grateful that the client didn’t remove me from the project, as it gave me a chance to be “reborn from the ashes.”

To break free from this agonizing state, I had to step out of the code and broaden my thinking. After a period of adjustment, I realized that interacting with people wasn’t as difficult as I had initially thought. I also gained a better understanding of the logic behind how a project operates because, essentially, project operation is all about collaboration among different individuals.

Breaking free from the limitations of solely focusing on technical matters made the world suddenly feel much broader. Subsequently, I had more opportunities to visit client sites and observe how different companies operate. Although I haven’t worked for many companies, I have witnessed how multiple companies function.

Later on, I had the chance to participate in the establishment of a new branch company, which allowed me to think from a company-level perspective. It led me to develop my own independent thinking on employee recruitment and development.

These thoughts ultimately helped me build a great team during my entrepreneurial journey. Furthermore, during the process of entrepreneurship, I had more opportunities to interact with business professionals from other companies, and thus expanded my context to encompass a larger scope, extending my thinking beyond the boundaries of the company.

Looking back at my career, I realized that by not expanding my context, I missed out on many opportunities for professional development. Fortunately, I had the chance to break through and step out, although not as fast as I had hoped, at least I was continuously moving forward instead of staying stagnant. This is why I urge you to constantly expand your work context.

Opportunities always favor those who are prepared, especially in small companies where there are often significant opportunities for rapid development.

I have seen someone go from being a programmer to becoming the head of a company’s China division within a few years, simply because the company was small at first, and he was particularly enthusiastic about many aspects of the company, transcending fixed role thinking. Therefore, when the company continues to grow and needs someone to step up, although no one is completely qualified, it is their enthusiasm that allows them to have a broader perspective and the opportunity to take a front-row position.

Of course, as the company grows larger, such significant leaps are less likely to occur. There is a story circulating about Huawei, where a new employee wrote a lengthy letter to Ren Zhengfei, discussing the company’s development. Ren Zhengfei’s response was: “If this person has a mental illness, I suggest they seek treatment; if not, I suggest they be dismissed.”

Because once the company reaches a large scale, it becomes difficult for you to grasp the bigger context, and you might only find out about many things concerning the company from the news.

In essence, it is possible for someone to see two or three levels above their own work scope. In small companies, there aren’t many levels between the grassroots and the boss, so the leap is obvious. However, as the company grows larger and the levels multiply, it becomes less likely to jump from the bottom to the top, but it is still possible to leap across levels.

Therefore, I hope you can break free from the mindset of just being a programmer, not only to work more efficiently but also to have better opportunities for development.

Summary #

Programmers always like to use technology to solve all problems, but many troubling problems are not actually problems at all. The reason why a simpler solution cannot be found is often because programmers limit themselves in their thinking.

The true difference in different roles lies in the difference in context. A problem that is difficult to solve in one specific context may not even need to be solved in another context. Therefore, no matter how hard one tries to optimize a single point, it is difficult to achieve the best results.

To do a good job, one needs to constantly expand the context of their work, understand the work logic of others, and have a grasp of the entire software development lifecycle.

Expanding one’s context not only helps improve the efficiency of one’s current work, but also benefits one’s career. As you see a broader world, you will also gain more opportunities.

If there is one thing you remember from this content today, please remember: Expand the context of your work and don’t limit yourself to being just a “programmer”.

Lastly, I would like to ask you to share any problems you have solved in your work by expanding your work context. Please feel free to share your thoughts in the comments.

Thank you for reading. If you find this article helpful, please feel free to share it with your friends.