The best line of code is the one you never write. That idea sounds like an excuse for laziness until you have spent a few years maintaining someone else's enthusiasm. Writing software feels like construction, but it behaves more like gardening. Left alone, a garden grows whether you want it to or not. Code does the same thing. The real craft is knowing when to stop planting.

Your Code Is a Liability

Every line you commit creates a set of ongoing obligations. You will read it again during a late-night incident. You will test it after your framework releases a minor version bump that changes string handling. You will debug it when logs from production make no sense. You will explain it to a teammate who joined last week, or to yourself twelve months from now when the context has evaporated.

This is not an argument for obscurity. It is geometry. Bugs need space to hide. The smaller your surface area, the fewer places failure can burrow in. A function with eighty lines and six nested conditions is not just harder to read; it is statistically more likely to surprise you. Restraint is not the absence of effort. It is the recognition that unwritten code has exactly zero defects.

When Cleverness Becomes a Tax

Consider the task of calculating an order total with a few business rules: apply a discount, check for taxable items, skip anything marked as removed. One developer writes a single expression. It streams the list through a complex filter chain, invokes a helper library, folds the result with a curried reducer, and returns the sum. It is compact. It might even be elegant in a academic sense. But to read it, you must understand the helper library's implicit casting, the order of operations inside the stream, and the business logic all at the same moment. You cannot set a breakpoint in the middle. You cannot drop a log statement without breaking the chain. The code is short on the page and long in the mind.

Another developer writes a basic loop. She declares a running total, iterates through the items, and uses a plain if statement to decide whether tax applies. The block is taller vertically, but the intent is obvious. You can read it from top to bottom without holding five abstractions in your head. You can step through it in a debugger. You can add logging on line four without refactoring the whole expression.

Clever code looks smart in a pull request for about ten minutes. Simple code looks boring, and boring is exactly what you want when you are troubleshooting at two in the morning. Your goal is clarity, not a demonstration of intelligence.

Systems Need Structure, Not Heroes

This principle scales up to architecture. A clever system might rely on handwritten consensus logic, bespoke orchestration scripts, and undocumented caching shortcuts that only one engineer truly understands. That system does not run on its own; it runs on the constant brilliance of whoever is holding it together. When that person takes a vacation or a new job, the system starts to wobble.

Well-designed systems rely on structure and constraints instead. They use database schemas that reject bad data, API contracts that define boundaries, type systems that catch category errors before deployment, and module separations that make the intended path obvious. They do not require heroics to stay stable. They are designed to survive contact with tired humans, which is the only kind of human who ever operates software in production.

The AI Amplification Problem

Artificial intelligence coding assistants make this lesson urgent. These tools generate text quickly. Present them with a simple problem and they will often return a large, complex solution that imports utilities you already have in-house wrappers for, handles edge cases that do not exist in your domain, and uses idioms from a framework version you migrated away from two years ago. The AI looks at the immediate task. You must look at the whole system.

Nếu bạn chấp nhận mọi gợi ý mà không quản lý chi phí dài hạn, việc tạo mã sẽ dẫn đến tình trạng lạm phát. Repository của bạn sẽ phình to với những đoạn mã trông có vẻ hợp lý, có thể biên dịch, vượt qua các bài kiểm tra, nhưng chẳng ai thực sự hiểu chúng. Nguy hiểm không nằm ở những lỗi cú pháp lộ liễu. Những lỗi đó sẽ bị phát hiện trong quá trình review. Nguy hiểm nằm ở sự dày lên dần dần của codebase, nơi mỗi tệp riêng lẻ trông có vẻ hợp lý khi đứng độc lập, nhưng tổng thể lại không thể nằm gọn trong trí óc của bất kỳ con người nào. Đó là cách mà tốc độ phát triển phần mềm lụi tàn. Không phải bằng một cú va chạm mạnh, mà bằng sự tích tụ âm thầm của những thứ mà không ai dám xóa vì họ sợ chạm vào những gì mình không nắm rõ.

Xóa bỏ là một kỹ năng thiết kế

Những kỹ sư giỏi không chứng tỏ bản thân bằng cách gõ phím nhanh hơn mọi người. Họ chiến thắng bằng cách chọn sự đơn giản, và chọn xóa bỏ thay vì tích tụ. Việc xóa mã đòi hỏi sự thấu hiểu. Bạn phải truy vết luồng dữ liệu, xác nhận rằng một tính năng không có các hàm gọi ẩn, và xác minh rằng yêu cầu nghiệp vụ đã thay đổi. Xóa bỏ khó hơn thêm mới vì nó đòi hỏi sự chắc chắn.

Các đội ngũ thường ăn mừng những tính năng đã ra mắt và những người tạo ra tác động lớn (multipliers) với các pull request khổng lồ. Ít có đội ngũ nào ăn mừng kỹ sư đã xóa bỏ bốn nghìn dòng logic thừa, giúp hệ thống chạy nhanh hơn và dễ hiểu hơn. Nhưng con số dòng code âm đó thường là đóng góp lớn hơn cho tương lai của tổ chức.

Phần đắt giá nhất

Mã nguồn giờ đây đã rẻ. Bất kỳ ai cũng có thể tạo ra hàng trang mã chỉ trong vài giây. Tài nguyên đắt giá chính là sự rõ ràng. Cần có thời gian, sự phán đoán và sự tiết chế để giữ cho một hệ thống luôn dễ hiểu. Kỹ thuật thực thụ nằm ở khâu chỉnh sửa, chứ không phải ở khâu viết bản thảo.

Viết ít hơn. Xóa nhiều hơn. Thiết kế đơn giản.