Let me share my personal experience. At my first company right after graduation, I was actually doing infrastructure middleware development. But during that work, I realized I didn’t enjoy the feeling of being so far removed from real business. So when I later changed jobs, I deliberately chose a business-oriented department. Today, I want to explain why I made this choice.

Why I Don’t Do Infrastructure Development

First, I want to address a common misconception: that infrastructure development makes it easier to learn and grow faster. I believe this is nothing more than wishful thinking by business developers. Infrastructure development isn’t as conducive to learning as people think, and business development isn’t as detrimental to learning as people think — I’ll elaborate on the reasons below. The reason many people hold this belief is largely because infrastructure development positions typically have higher hiring standards, so these individuals naturally have better learning ability and motivation.

In reality, the daily work of infrastructure development isn’t that different from business development — both involve working on requirements. The only difference is that business requirements come from product managers, while infrastructure requirements come from other developers, or from the infrastructure developer’s own thinking and ideas. This brings me to my first reason for not wanting to do infrastructure development: the source of requirements is unscientific. If you only do infrastructure development and are detached from actual business scenarios, your understanding of technology is likely to be biased, and things you want to build may just be self-indulgent exercises with no practical application value. Even when collecting requirements from business developers, there are similar issues — their suggestions may reflect only shallow, unconsidered thoughts. Moreover, business developers may not accurately understand what infrastructure components should actually handle; they may not distinguish between what should be solved by infrastructure and what they should handle themselves.

This brings me to my second reason for not wanting to do infrastructure development: unclear boundaries of responsibility. This is closely tied to the capability of the business teams you work with. Sometimes, when something on your end isn’t done well, the business team finds a way to work around it. Other times, even when something has nothing to do with you, you’re forced to deal with some upper-layer logic.

As you can see, both issues above are extremely dependent on colleagues’ abilities. So if you insist on doing infrastructure development, you must go to a company with strong technical talent — this directly affects your work happiness. The company choice also impacts another aspect: the nature of the work. Simply put, it’s a difference between building wheels versus improving open-source tools — these two types of work are worlds apart. Building wheels requires deep familiarity with various fundamental knowledge and can indeed promote growth — this is the origin of the idea that “infrastructure development helps you grow.” But this kind of work only exists at a handful of big companies. The vast majority of infrastructure work — improving open-source tools — is no different from business development. You only need to learn the ins and outs of the open-source tools to complete most of the work, with neither depth nor breadth. This is why I said earlier that infrastructure development doesn’t help with learning.

So, to do infrastructure development, company selection is crucial — it must be large AND technically strong; both conditions are essential. You might ask: why not just go to such a company? That’s fair, but it brings its own problem — my third reason for not wanting to do infrastructure development: the career choice is extremely narrow. In China, there are only two companies doing Java infrastructure well, and everyone knows what their corporate cultures are like. So if you don’t want to go to those companies, does that mean you can’t do it at all? Even if you’re willing, the massive supply-demand imbalance would lead to insane involution, similar to algorithm positions. Do you have enough confidence to win that game? In contrast, for business development, big tech experience is just a necessary learning experience and a highlight on your resume. Once you’re familiar with the entire standardized workflow at a big company, you can freely choose wherever you want to go.

The Value of Business Development

I’ve talked too much about infrastructure development above. Let me now get to the main topic: the value of business development. In my view, business development has improved my capabilities primarily in three areas: accumulation of business knowledge, expansion of technical breadth, and improvement of comprehensive abilities.

First, business knowledge — business knowledge is essentially an understanding of the real world. For me personally, learning about how different industries operate in my spare time is first and foremost an interesting thing to do. Second, continuously learning industry knowledge across different domains has noticeably improved my cognitive abilities. Can this ability be monetized? Of course. For example, when investing in stocks, the accumulation from work has given me the ability to analyze a company’s business model — I can clearly understand what makes a good company and a good stock at a deeper level than most people. Of course, I’m getting ahead of myself here — take it as food for thought. The key is to follow your interest and see if you’re willing to learn about things beyond technology.

Next, technical breadth. The biggest difference between business development and infrastructure development is that infrastructure development demands more depth, while business development demands more breadth. Business development requires familiarity with a wide variety of frameworks and middleware — not just surface-level knowledge, but enough depth to understand what problems they solve, what problems they introduce, and which scenarios they’re suited for. You need to comprehensively understand complex business scenarios and complex systems, and be able to quickly locate problems when they occur. Beyond knowledge accumulation, this also requires experience gained from real-world scenarios.

Then there’s the improvement of comprehensive abilities. Compared to infrastructure development, business development exercises a person’s general foundational capabilities more — communication, problem analysis and problem solving, and the ability to weigh trade-offs. These abilities are related to technology, but not so closely. To be extreme, even if you change careers in the future, these universal capabilities will be very helpful. I often think about what the difference is between learning to use an open-source tool and playing Honor of Kings. As a beginner, following an example to build a demo is like encountering a game for the first time and just playing around. As you get more familiar, some people become emotionless tool-switching machines, while others gradually explore the underlying implementation. Just like in gaming — some people play thousands of matches without ever understanding the difference between Lightning Dagger and Infinity Edge, while others explore the numerical mechanics of damage. So I think we shouldn’t view programmers as some uniquely special profession — it’s fundamentally no different from other professions. Most professions are just solving problems in different ways: lawyers rely on law, fund managers rely on understanding markets and fundamentals, and programmers rely on code. What we continuously develop through work is our problem-solving ability, and no one requires the solution to be limited to technology alone.

In business development, we must continuously accumulate capabilities in these three areas, so that we can build momentum over time and confidently face the midlife crisis. Of course, I’m not writing this to say that business development is inherently better — I mainly want to help everyone clearly analyze the differences between business development and infrastructure development, so you can make a rational choice.

If you have any thoughts, feel free to reach out and discuss with me.

Source: https://lichuanyang.top/en/posts/40071/