编程 14 年：好代码稀少，复杂度才是真正的敌人

Many years ago, when I was a senior majoring in computer science, I spent my days browsing job postings online, hoping to land a suitable programming internship.

Besides internship listings, I would occasionally click into posts for "senior engineer" roles. Looking back now, technical buzzwords aside, what stuck with me most was the line that often sat at the top: "This position requires 5+ years of experience."

As a rookie who had never worked a single day, those year requirements looked absurdly long to me. Still, beyond the envy, I would sometimes daydream: "A programmer with five years of experience—how impressive must they be? Is writing code as easy for them as eating?"

Time flies—more than a decade has slipped by. Looking back now, I've become a proud working stiff with 14 years of experience. After stumbling through the software industry all these years, I've found that many things are quite different from what I imagined as a senior. For example:

As experience grows, programming doesn't get much easier—"as easy as eating" only happens in dreams.

Writing code for many "big projects" is not only boring but dangerous, far less fun than solving an algorithm problem on LeetCode.

Thinking only from a technical angle won't make you a good programmer; some things matter far more than technology.

There are many more reflections like these. I've collected eight of them into this article. If any of them resonate with you, I'll be very happy.

1. Writing code is easy, but writing good code is hard

Programming used to be a highly gated skill. In the past, the most common way for an ordinary person to learn programming was through textbooks and books. But most programming books are dense and obscure, unfriendly to beginners. As a result, many gave up early, before ever tasting the joy of programming.

But today, learning to program is getting easier and easier. Instead of grinding through books, learners now have many new paths: watching tutorial videos, taking interactive courses on Codecademy, or even learning by playing games on CodeCombat. Everyone can find a way that suits them.

"Mom, I'm really not playing games—I'm learning to program! Look at the right side of the screen!"

What's more, programming languages are becoming easier to use. Classic C and Java are no longer the first choice for most beginners; many simpler, more approachable dynamically typed languages are now popular, and the IDEs and tools around them keep improving. These factors further lower the barrier to learning.

In short, programming has long shed its mystique. It has gone from a secret art mastered by a select few to an ordinary craft anyone can learn.

But a lower barrier and friendlier languages don't mean everyone can write good code. If you've already worked and been part of some projects, I'd love to ask you: "How is the code quality in the projects you touch daily? More good code, or more bad?"

I don't know how you'd answer. Let me share mine first.

Good code is still rare

In 2010, I moved to a large internet company headquartered in Wudaokou, Beijing.

Before joining, I'd only worked at small companies of about ten people, so I had high expectations for everything at the new company, especially software quality. Back then, I was thinking something like: "This is a 'big' project powering a product with tens of millions of users. Its code quality must be a qualitative leap over what I've seen before!"

After a week there, I realized how wrong I was. The code quality of that so-called "big" project was far from my expectations. Opening the IDE, I saw hundreds-line functions and mysterious numeric literals everywhere; shipping even a tiny requirement was agonizingly hard.

Later, after working at more companies and seeing more software projects, I arrived at a conclusion: no matter how big the company or how impressive the project, running into good code at work is still a low-probability event.

What makes code good?

So what counts as good code? On this, Martin Fowler has a much-quoted line:

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

I think it can serve as the starting point for judging good code: good code is readable, easy to read, and easy to understand. The first principle of writing good code is to put the human reader first.

Beyond readability, there are many other dimensions for judging code:

Fits the language: Does it use the idioms the language recommends? Are language features and syntactic sugar used in just the right amount?

Easy to change: Does the design account for future requirement changes, and is the code easy to modify when those changes come?

Sensible API design: Is the API reasonable and easy to use? A good API is convenient in simple scenarios and can extend with needs in advanced ones.

Adequate performance: Does the code meet current business needs while leaving room for future improvement?

Avoids over-design: Does the code suffer from over-engineering or premature optimization?

…

In short, for programmers at any level, good code isn't something you get easily. Writing it requires weighing many dimensions, designing carefully, and polishing continuously.

That said, if you want to master the craft of coding as quickly as possible, is there a shortcut?

The shortcut to writing good code

In many ways, I think programming and writing are very similar. Both use text and symbols to express ideas, just in slightly different ways.

Speaking of writing, let me ask a question about writers: "Have you ever heard of a writer who doesn't read? Have you ever heard a writer say they never read others' work, only their own?" I'd guess the answer is no.

If you dig into it, you'll find that the daily life of many professional writers is a loop of reading and writing. They spend hours each day reading all kinds of text, then writing.

Programmers are also "people of text," yet they rarely value reading. But to improve your programming skills quickly, reading is an indispensable part. Beyond the projects you touch daily, we should read classic software projects more, learning API design, module architecture, and coding techniques from them.

Beyond code and technical docs, it's best to regularly read computer science books and keep the habit of reading. Here, I think Jeff Atwood's article from 15 years ago, "Programmers Don't Read Books -- But You Should," still holds up today.

The shortcut to improving your programming ability lies in the endless loop of "reading <-> programming."

"What should a good programmer do?"

2. The essence of programming is creation

In a programmer's daily work, many things bring a sense of accomplishment and even make you sigh, "Programming is wonderful." For example, fixing a bug that was nearly impossible to pin down, or doubling performance with a new algorithm. But among all these, nothing compares to "creating something with your own hands."

In fact, opportunities to create are everywhere when you program. Releasing new software isn't the only thing that counts as creation. Writing a reusable utility function or designing a clear data model all fall under creation.

As a programmer, keeping your passion for creation is crucial. It helps us:

Learn more efficiently: The most effective way to learn a new technology is to build a real project with it—learning through creating works best.

Chance upon something remarkable: Many world-changing open-source projects began as pure hobbies of their authors, like Linus Torvalds and Linux, Guido van Rossum and Python.

During the 1989 Christmas holiday, Dutchman Guido van Rossum typed the first lines of Python. It was initially expected to be a successor to ABC, but it went on to "swallow" the world.

Though creation offers many rewards and programmers have plenty of chances to do it, many still lack the awareness of being a "creator." As the widely told story goes: a philosopher asks bricklayers what they're doing; one clearly knows he's building a cathedral, while another thinks he's just laying bricks. Many programmers see only the bricks, not the cathedral.

Once you see yourself as a creator, the way you look at things changes completely. For example, when adding error messages to an API, creators can escape the trap of "just finish the requirement fast" and take a step further, asking themselves more important questions: "What product experience do I want to create for users? What error text best helps me achieve that?"

Like any useful programming pattern, a "creator's mindset" can be a huge boost to your career. So try asking yourself now: "What will my next creation be?"

3. Building an environment for fast trial and error matters

I once worked on an internet product with beautiful design, rich features, and lots of daily users.

But despite being a market success, its engineering quality was terrible. If you opened its backend project and dug through every directory, you couldn't find a single line of unit test, let alone any automated testing. The business logic was complex, and the code ended up riddled with accidental coupling. Adding a feature easily broke old ones.

"What are you up to?" "Trying to fix the problem I created when fixing a problem, which I created when fixing another problem, which I—"

So every release put developers and PMs on high alert, with tension in the air. The process was thrilling, with emergency rollbacks happening regularly. Working in such an environment—technical growth aside—would certainly steel your nerves.

Programming is supposed to be enjoyable, but working on a project like this drains all the fun out of it. What exactly robs programming of its joy?

The ideal programming experience ≈ "solving problems"

LeetCode is a well-known programming practice site with problems at every difficulty, most algorithm-related. Users pick one they like, write code right in the browser (a dozen-plus languages supported), and run it. Passing all test cases counts as success.

Solving a problem on LeetCode

Working through LeetCode problems feels like playing a game—challenging and fun. The whole process perfectly embodies an idealized programming experience:

Separation of concerns: each problem is self-contained, so the developer can be fully immersed in one thing at a time.

Fast, precise feedback: every time the developer tweaks the code, automated tests quickly report results.

Zero-cost trial and error: syntax errors or logic bugs carry no bad consequences, so the mental burden is light.

Still, you might think I'm stating the obvious.

"And? Solving algorithm problems or writing small scripts is exactly like that. What's worth mentioning?" you might add. "Do you know how complex our company's project is? Massive scale, tons of modules, you know what I mean? Serving millions daily, several databases, three kinds of message queues—of course development is harder!"

True, software around the world varies wildly, and not all of it can be as light and pleasant as solving LeetCode problems. But that doesn't mean we shouldn't try to improve our programming environment, even just a little.

Ideas and tools for improving the environment include:

Modularity: design each module well, reduce coupling, increase orthogonality.

Design principles: at the micro level, apply classic principles and patterns like "SOLID."

Automated testing: write proper unit tests, use mocking when needed, and cover critical business paths with automated tests.

Shorter feedback loops: switch to faster-compiling tools, optimize unit test performance, and do everything to cut the wait from "code changed" to "feedback received."

Microservices: when necessary, split a large monolith into services with distinct responsibilities to spread out complexity.

…

Paying attention to your environment and deliberately creating a "code playground" that allows fast trial and error—making work as light as solving problems—is one of the best contributions an experienced programmer can make to their team.

4. Avoid the code perfectionism trap

Striving for quality in code is good, but beware the perfectionism trap. Programming isn't art; it doesn't encourage endless pursuit of the extreme. A writer may spend years polishing a masterpiece, but a programmer obsessing over code has a real problem.

There's no perfect code. Most of the time, as long as your code meets current needs and leaves some room for future extension, that's enough. A few times I've seen candidates label themselves "code OCD" on their résumés. Through the screen, I can feel their emphasis on code quality, but deep down I'd rather they had long left the perfectionism trap behind.

5. Technology matters, but "people" may matter more

In software development, the "Single Responsibility Principle" (SRP) is a very famous design principle. Its definition is simple, summed up in one sentence: "Every software module should have only one reason to change."

The Single Responsibility Principle: just because you can do it doesn't mean you should.

To grasp SRP, the key is understanding what a "reason to change" is. Clearly, a program isn't alive; it can't and doesn't need to change on its own. Every reason to modify a program comes from the people associated with it—people are the "culprits" behind change.

Here's a simple example. Look at these two classes—which one violates SRP?

A dictionary data class supporting two operations: store data, retrieve data.

An employee profile class supporting two operations: update personal info, render a user profile card image.

Most people see no problem with the first example, but the second clearly violates SRP. You seem to reach that conclusion with a bit of intuition, no rigorous analysis required. But do the analysis properly, and the second example's suspiciousness lies in how easily you can find two distinct reasons to change it:

An admin thinks the "personal phone" field should reject invalid numbers, so a bit of validation is needed.

An employee thinks the "name" on the profile card is too small and wants a bigger font.

"It is people who request changes. And you don't want to confuse those people, or yourself, by mixing together the code that many different people care about for different reasons." — "The Single Responsibility Principle"

The key to understanding SRP is first understanding people and the role they play in software development.

Another example: microservice architecture has been a hot technical topic in recent years. But many people discuss only the technology itself, ignoring the relationship between microservices and people.

What sets the microservice style apart is that after splitting a monolith into independent services, the boundaries between modules become clearer. Compared with a team of hundreds maintaining one monolith, many small organizations each maintaining independent microservices are clearly more efficient.

Without a certain organizational scale (that is, "people") as a premise, talking up microservices' technical advantages and fancy tricks is putting the cart before the horse.

Technology certainly matters. As technologists, we're naturally drawn to gorgeous architecture diagrams and ingenious code details. But please don't turn a blind eye to the other key element in software development: people. When necessary, shift your perspective—from "technology" to "people"—and it will serve you well.

6. Hunger for knowledge is good, but method matters

Everyone talks about "lifelong learning," and programming is a career that especially requires it. Computer technology iterates fast—a framework or language popular three years ago may be obsolete a month prior.

What happens in one minute? Netflix viewing grows by 70,000 hours; three million videos are watched on Snapchat; Google gets 2.4 million new searches; a new JS framework is invented (that last one isn't true 🤓).

To work with ease, programmers need to learn a great deal across many levels. Take backend, which I know well: a qualified backend engineer should at least master:

One or more backend languages / relational databases like MySQL / common storage components like Redis / design patterns / user experience / software engineering / compiler principles / operating systems / networking basics / distributed systems / …

Though there's a lot to learn, from what I've seen, most programmers enjoy learning (or at least don't mind it), so mindset isn't the issue. But sometimes a "hungry for knowledge" attitude isn't enough—when learning, we especially need to watch the "cost-effectiveness."

Watch the ROI of learning

The chart below shows the relationship between learning outcomes and investment.

Learning outcomes vs. investment; the x-axis is investment, the y-axis is outcomes.

As you can see, in the early stage, small investment yields rapid gains. But once outcomes pass a certain threshold, further improvement requires exponentially more investment.

So before learning anything new, I suggest you first figure out one question in your head: "Where on that chart should I stop?"—rather than blindly grinding away.

The ocean of knowledge is vast. Some things require years of continuous study and refinement. Others are more than covered by a superficial dip. Accurately judging and allocating your limited learning energy matters even more than the effort itself.

Choosing the right learning materials

Once you have a learning goal, the next step is finding suitable materials. Here I'd like to share one of my failures.

For a while I became deeply interested in product interaction design and thought I should improve there. So I carefully picked a classic in the field, "About Face 4: The Essentials of Interaction Design," bought it, and confidently expected my interaction design skills to improve quickly.

But things went the other way. Holding that classic, I couldn't even finish the first chapter—as the old saying goes, "Different trades are like different mountains."

From this failure I drew one lesson: when learning something new, we'd better pick materials that are easier to read and more suited to "outsiders." Don't have "big eyes but a small mouth"—don't just chase the most classic, most authoritative material.

Looking back, I think these books are excellent and highly cost-effective for beginners:

"The Non-Designer's Design Book": on design

"Don't Make Me Think": on web UX

"Brother Bird's Linux Private Kitchen": on Linux

Perhaps everyone secretly wants to be a polymath, knowing everything about everything. But the time and energy we can allocate is always limited; we can't, and don't need to, become experts in every field.

7. The sooner you start writing unit tests, the better

I love unit tests—very, very much. Writing them has had a huge influence on my programming career. To put it dramatically: if I split my career in two at "the moment I started writing unit tests," the second half is far more exciting than the first.

Unit tests have many benefits: they drive you to improve your design, they serve as a kind of documentation, and more. A solid test suite is also key to building the "environment for fast mistakes" mentioned earlier.

I've already written several articles on unit testing, like "5 Tips on Unit Testing" and "What the Game Celeste Taught Me About Programming." So I won't repeat it all here. I'll just say: if you've never tried writing unit tests, or never taken testing seriously, start tomorrow.

Normally I don't test my code, but if I do, I test in production.

8. What is a programmer's greatest enemy?

In most programmer jokes, the product manager plays the villain. Their requirements always keep changing—a new idea every day—making programmers miserable.

Clients keep changing requirements every day, so we decided to "freeze" them before the next release.

Fueled by these jokes, the requirement-changing PM seems to have become programmers' greatest foe. As if, once PMs stop changing requirements, everyone's work environment would instantly become a utopia.

Though joking about PMs now and then is fun, I want to say seriously: the PM is not the enemy.

Because in a sense, software is born to be changed—otherwise, why is it called "soft"ware? Seen this way, building software is nothing like building a house. After all, nobody finishes a building and says, "Let's tear it down and rebuild the same building with 30% less steel and concrete!"

So the PM and shifting requirements are not the programmer's enemy. And the ability to write code that's easy to change and adapt is one of the key markers separating ordinary programmers from excellent ones.

Then what is a programmer's greatest enemy?

Complexity is the greatest enemy

As "Code Complete 2" puts it: the core problem of software development is managing complexity. Runaway complexity is a programmer's greatest enemy.

Look at the factors that keep driving project complexity up:

Ever-growing features: more features means more code, and more code usually means higher complexity.

Demands for high availability: to achieve it, extra components and code like message queues get introduced.

Demands for high performance: to boost performance, caching and related code get added, and some modules get split out and rewritten in high-performance languages.

Repeatedly postponed refactoring: because schedules are too tight, urgent refactoring keeps getting delayed, and technical debt piles up.

Neglected automated testing: nobody writes unit tests, and nobody cares about testing.

…

One day, when complexity grows past a point, there's a loud bang in the air. "Thud!"—a "big pit" that nobody wants to touch or dares to change appears out of nowhere in everyone's IDE.

Guess who dug that pit?

Teams that invest time in reducing complexity tend to own more successful software projects.

Slowing the growth of complexity

Complexity will inevitably keep growing, but many practices can slow the process. If everyone can do the following, complexity may be kept within a reasonable range long-term:

Master your current programming language and tools; write clean code.

Use appropriate design patterns and programming patterns.

Have zero tolerance for duplicate code; abstract libraries and frameworks.

Apply clean architecture and domain-driven design ideas where appropriate.

Write thorough documentation and comments.

Write proper, effective unit tests.

Separate what changes from what doesn't.

…

The list looks long, but summed up, the core is one sentence: write better code.

Final thoughts

In 2020, I gave a talk within my team titled "Ten Reflections After Ten Years of Programming." After I shared the slides on the company intranet, a colleague commented that the slides alone weren't satisfying and asked me to expand them into an article. I said no problem. Now, three years later, I've finally kept that promise.

Back when I was preparing that talk, I finished the whole deck and had no idea what to put on the last slide. So I improvised: a pure white background with a line of bold black text in the center—"Ten years is short; programming is hard." Now the second decade is nearly halfway through, and the second half of that line still seems to apply to me—not much progress, keep going 😅.

One small plug at the end: if you enjoyed this article, you're welcome to check out my book, "Python Craftsman: Cases, Tips, and Engineering Practices." It focuses on combining fundamental programming literacy with advanced Python techniques—a Python advancement book suitable for many readers.

Buy on JD.com | Douban reviews