Becoming an Brilliant Programmer (02): The Purpose of Management
This article was translated by ChatGPT automatically, with minor manual corrections.
If you need to view other articles in the series, please use the tag to jump to the article directory page: #becoming-an-brilliant-programmer.
Thanks to MD-20880 for pushing for an update, let's continue writing this series this time.
I've actually been writing this article for several months, but when work is required, my energy is really consumed significantly. This means that every time I have the chance to continue writing, it has been a week or two since the last session. Even though I have a rough outline ready, I still need to spend a lot of time re-reading what I wrote previously to connect with my past self.
After much reflection, considering that I haven't been able to update a single article for several months, I've decided to break this article into several shorter ones. This way, on one hand, I will have more stock on hand, and on the other hand, I can divide the content into chapters for easier recall of what was previously written.
In the first article, let's discuss why I chose "management" as the theme for these articles.
Why Talk About Management
In a series with a theme of "programmers," it's quite peculiar to discuss "management" in the second article. But I believe that for an outstanding programmer, management is a topic that cannot be avoided throughout their career.
As a candid person, I must also admit that talking about management so early has some selfish motives. Some readers who have read recent articles may have noticed that I recently switched jobs, moving from a forcibly assumed management role to a position more akin to an IC (Individual Contributor).
Unexpectedly, even in a seemingly non-management role, my previous management experience has been incredibly helpful; on the other hand, since I'm no longer engaged in hands-on management work, I'm actually concerned that I will gradually forget these experiences in a few years.
So I wish to share my experience as soon as possible, which can also serve as an outline for myself to refer to in the future.
The Inevitable Management
Most "ordinary" programmers follow a career path towards management, leading teams of dozens, hundreds, or even thousands of people, which is also the most conventional way to avoid the 35-year-old crisis. Although I didn't choose this path, I don't think it's a bad choice but rather a more suitable option for many people.
Some programmers may choose the IC route. IC stands for Individual Contributor, typically found in larger companies, where there are always a few ICs in related groups. Simply put, an IC is someone with strong technical abilities who can independently handle large projects but does not manage personnel directly.
Choosing the IC route doesn't mean complete isolation from management. Indeed, ICs usually enjoy greater freedom within the company, and their work is more technology-oriented. However, an IC who only knows how to write code is not likely to be the best IC.
In fact, most software projects ultimately serve product goals. This is why the previous article described the software industry as teetering yet still stable: as long as the main product goals are achieved, any lousy code is tolerable (until the moment the product goals can't be met, which is when the lousy code collapses). So, when someone has no understanding of how the organization operates, it's hard for them to participate effectively in the team's work. At the same time, the best way to understand the product is through those who are already familiar with it. An isolated IC might complete a decent project individually but definitely can't solve problems beyond personal resource limits.
Furthermore, if I not only aim to be an IC but also wish to be an independent programmer developing my software, can I escape the management ordeal and develop freely?
In reality, I think any independent programmer needs to understand management better than a company-employed one. First, being an independent programmer means you have to handle work that might normally involve cooperation among a dozen positions in a company, making interaction with people unavoidable. Second, even limited to software, anyone who has independently developed a software project can feel that it's easier for one person to produce unmaintainable code. If you want to avoid this, then you must first learn to manage yourself, which is actually a more advanced task than managing a small team in a company.
Of course, perhaps every programmer has heard of some "ancient demigod" myths, where they single-handedly developed an entire set of software, accomplishing what a whole team could not.
Indeed, such programmers exist. But we must also admit that such people are extremely rare, and the software they write typically has various "flaws" from a general perspective—precisely because they could decide too many aspects during development, these software pieces are more artistic works of these masters than mere tools.
Since the audience of this series is ordinary programmers like me or even beginners, there is no need to reference these masters. I believe that when they were my age, or even younger, they didn't need superficial advice like mine. Let's lower our stance and cautiously examine what we truly need from a more worldly perspective.
What Management Brings
By now, perhaps you agree that management skills are essential for programmers, or you still don't.
No worries, we can consider it from another angle: what exactly does management bring to software development?
In fact, this question was partially answered in the previous article:
The good news is that programmers (and all related professions, which I won't list here) have learned to isolate cognitive costs through abstraction.
Speaking of management, most programmers, including myself, immediately think of being the boss and leading a team. But why do we need "teams," and where do they come from?
When the scale of software grows to a certain extent, it will surpass an individual's development and maintenance capability limits. This might be because there are too many functions to complete all in time or because the development duration is prolonged, causing some early code and design to be forgotten. Ultimately, it's a matter of time.
Humans constantly battle time throughout their lives, but in the end, they lose to time with lingering regret.
The way to solve these issues, as mentioned in the previous article, is reasonable abstraction. But after we devise abstract designs, another issue emerges, as highlighted in the previous article:
On one hand, clearly knowing that further abstraction would lead to decreasing understanding of other abstraction layers by programmers, but on the other hand, expecting them to understand more of other abstraction layers—this is the software industry's dilemma today.
Precisely, it's about "understanding." After abstracting the system, we convert the problem from understanding the entire system to understanding the abstractions. This reduces the cost of "understanding" itself but introduces additional costs of "how to understand."
In the end, management is essentially about maintaining "how to understand the abstractions." Ensuring that everyone accurately understands the abstractions they most need to comprehend can make the system run more efficiently and smoothly.
Preview of the Next Article
In the next article, I will introduce two management models summarized from years of personal experience and their similarities and differences.
However, I recently went through an interview, but the final publication was completely off-topic and unrelated to what I intended to express. This makes me want to sort out my interview answers and publish them. Before updating the next article in this series, I might insert one or several articles summarizing the interview content.
Or, since the National Day holiday is coming up, I will be traveling around the Qinghai-Tibet Loop with some friends (Exun: 6), so the next update might be a travel diary instead?