What “Car” Does the Enter Key Actually Return? Essential Reading for Becoming a Professional

What “Car” Does the Enter Key Actually Return? Essential Reading for Becoming a Professional

Compared with traditional industries (with the exception of media and writing), the software industry seems to produce an unusually large number of writers. This may be because a programmer’s day job is already to type on a keyboard, so writing a little more text is not especially difficult. But a more likely reason is that the software industry has developed and standardized at extraordinary speed over just a few decades, accomplishing in a short time what many traditional industries take centuries, or even millennia, to complete. That process naturally generates a great deal to talk about. And because programmers are a typical kind of knowledge worker, with relatively strong analytical and expressive abilities on average, they are more likely to organize and articulate their thoughts.

Today, the “software” industry has become a vast and highly specialized field, and the category of “programmer” includes many fine-grained roles that outsiders can barely distinguish. Yet to the outside world, programmers are still often seen as a group of quiet, hard-to-understand people. As Uncle Bob explains in this book, when we speak of doctors, lawyers, or accountants, we immediately recognize them as professionals. But when it comes to programmers, people often hesitate to place them in the same category. The Clean Coder was written precisely to address how one becomes a “professional.”

In my view, this book applies to far more than programmers alone. At the very least, in traditional industrial fields such as engineering and energy, it offers highly valuable reference points for anyone who wants to become a true professional. (Of course, for programmers, the material is more directly relevant and more deeply detailed.) Over the past few decades, the software industry—using that broad label for convenience—has rapidly moved from rough, loosely managed practices to fine-grained standards and then to continual iterative improvement. Compared with traditional industrial sectors, this progress has been exceptionally fast, and that speed is determined by the nature of software itself.

If a piece of software is not standardized enough, it will not compile. Even an error in capitalization or punctuation may confuse the compiler. If there is the slightest logical oversight in a program, an entire system can be dragged into a pit of defects. Compared with almost any other kind of work (perhaps finance being one exception), these requirements are extraordinarily strict. Of course, critical steps in engineering can demand a level of rigor no less severe than software, and the consequences of mistakes can be just as serious. But engineering generally does not impose such exacting, almost obsessive scrutiny on every single action of every practitioner. The development and standardization of the software industry emerged precisely because of these demands. By contrast, due to differences in scale, industrial fields cannot achieve the same degree of standardization as software no matter how strongly project management is promoted. In this sense, any book about the software industry and software practitioners is worth studying for people in other industrial fields as well, if only to gain inspiration and useful points of reference for progress in their own domains.

In principle, the material in The Clean Coder about professionalism is not tied to any one industry. It is simply that the author, Robert C. Martin (Uncle Bob), is a programmer by trade, so the examples and practices in the book come from software development. The book discusses topics such as how to understand professionalism; professional conduct and effective commitment (including the importance of firmly saying “no” to things that cannot truly be promised, and of honoring commitments once they are made, which is the minimum standard of professionalism); how to manage one’s working state, adjust one’s condition, maintain rhythm, and face obstacles and difficulties (asking colleagues for help is one of Uncle Bob’s especially constructive suggestions); how to estimate and test work; how to practice (deliberate, disciplined practice is indispensable for becoming a professional); how to manage time, handle pressure, work with others, and become part of a cohesive team; and how professionals progress through apprenticeship and competence toward mastery. All of these elements matter to anyone who seeks to be a professional, and the content of the book is highly instructive. It is, in many ways, the distilled essence of Uncle Bob’s 42-year programming career.

I especially want to emphasize that this book is also highly suitable for people in industrial fields. Naturally, one reason is that I myself work in and am familiar with engineering. But more importantly, the software industry and industrial sectors are quite similar in their operating models, with many shared ideas and many points worth learning from each other. Traditional industry, especially in project execution and engineering management, has much to gain from borrowing more ways of thinking and more methods from software.

In the final part of the book, Uncle Bob talks about detail. In programming, writing code is never the most important thing; detail is. He mentions the two most important characters in programming: \n and \t, the former representing a line feed and the latter a carriage return. Today, almost no one really knows the difference between the two, yet programs still contain mixtures such as \n, \n\t, and \t\n. Why is that?

The answer is that they are relics from the age of printers. In that era, when one line of text had finished printing, you first had to perform a line feed so the print head would move to the next line. Then you needed a carriage return, because the print head sat on a device called a “carriage.” To return the carriage meant moving it back to the position of the first character, so that printing could begin on the new line. Today, for most computer users, both line feed and carriage return are handled by a single “Enter” key. We no longer think about what “carriage return” is returning, or where it is returning it to. But for programmers, even such a subtle distinction can crash a program. So even details like this deserve serious attention.

Here are some excellent passages from the book:

Management keeps stressing to us, again and again, how important these deadlines are. If we miss one, the government will blacklist us for the year; and if customers do not sign with us immediately, they will sign with another vendor instead. If we fail to get the contract, we are finished.

Ultimately, career development is your own responsibility. Your employer has no obligation to ensure that you remain competitive in the workplace, nor any obligation to train you, send you to conferences, or buy books for your growth. Those who rely entirely on their employer for career development will have a miserable outcome.

Keep learning: Would you go to a doctor who no longer reads medical journals? Would you hire an accountant who knows nothing about new tax laws and accounting rules? Would you seek help from a lawyer who is unfamiliar with current statutes? Then why should employers hire developers who fail to keep up with the times?

True professionals practice diligently and relentlessly in pursuit of technical mastery. Merely doing your day-to-day work does not count as practice; that is execution, not practice. Practice means deliberately training your skills outside everyday work in order to improve yourself.

Professionals do not need to say “yes” to every request. However, they should strive to find creative ways to be as helpful as possible. When professionals give an affirmative answer, they use the language of commitment so that everyone clearly understands exactly what has been promised.

For professional developers, “done” has only one meaning: done means done. It means all the code has been written, all the tests have passed, and QA and the stakeholders have accepted the result. Only then is it done.

Meetings are in fact expensive, once salaries, benefits, equipment, and other factors are taken into account. There are two truths about meetings: first, meetings are necessary; second, meetings waste enormous amounts of time. Professionals understand the high cost of meetings, and they also understand that their time is valuable. Therefore, if a meeting has no practical and significant outcome, they should actively refuse it.

You should understand that continuing to sit in a meeting room wasting time, and continuing to attend meetings with little real value, is unprofessional behavior. You have a responsibility to use your boss’s time and money wisely.

Even under pressure, professional developers remain calm and decisive—think of a surgeon in the operating room. As the pressure mounts, they still adhere to their training and discipline, because they know these are the best tools they have for overcoming the stress created by deadlines and commitments.

Let your team and your manager know that you are in trouble. Tell them the best plan you have for getting out of it. Ask for their support and guidance.

A cohesive team usually has about 12 members. At most it may have 20; at minimum it can be as small as 3.

Aside from inner drive and effective guidance from a senior mentor, nothing can turn a young software developer into an agile, efficient professional more quickly.

The worst behavior of a professional programmer is to shut out everything happening outside, bury themselves in a pile of technology, and ignore the fact that the company’s business may be in urgent trouble or on the verge of collapse. Your job is to keep the business from falling into distress, so that the company can continue to thrive. Therefore professional programmers seek to understand their obligations… in short, they focus on how to stay in the same boat as the business.