29 “Laziness” should be the pride of all programmers #

Hello, I’m Zheng Ye.

After studying the previous modules, our column has finally entered a topic that seems most familiar to programmers: automation.

Whenever automation is mentioned, I always think of a classic statement by Larry Wall, the inventor of the Perl language: Excellent programmers should have three virtues: laziness, impatience, and hubris.

Some people have even created a website specifically dedicated to explaining this seemingly absurd statement.

Laziness is a quality that will make you exert great effort to avoid excessive energy consumption. It urges you to write programs that save physical effort and can be utilized well by others. It also drives you to write comprehensive documentation to prevent others from asking questions.

Impatience is the anger you feel when the computer is being lazy. It pushes you to write programs that go beyond expectations, rather than just fulfilling requirements.

Hubris is extreme self-confidence, enabling you to write (or maintain) programs that others cannot find fault with.

I don’t know if you’ve felt the unique humor and pride of programmers: what I create should be the best.

The reason why I start this module on “automation” with Larry Wall’s statement is because whenever automation is mentioned, I can’t help but think of the word “laziness”. Yes, the essence of our work as programmers is to build various automated tools that free people from various complicated tasks and give them the opportunity to “be lazy”.

However, I also know that the “laziness” we steal from the machines is quickly filled with more work. But Larry Wall’s statement can encourage us to constantly build better tools.

As a programmer, you certainly know the value of automation. In your daily work, you are also actively creating automation tools. However, many people may have a somewhat shallow understanding of automation. Today, I will start discussing a topic that you may overlook: Do not automate.

Don’t Automate Everything #

First, let me tell you an impressive example of “not automating everything.”

When I was working at ThoughtWorks, we had a job of helping other companies launch new products. Once, two of my colleagues were hired by a company to kickstart a video website project. At that time, the market was not like it is today, where a few major video websites dominate. Many companies saw the potential of video websites and thought they could have a slice of the pie. This company that hired us was no exception; they believed they had a chance.

Two weeks later, my two colleagues returned. We were interested to know about the progress of the project because after launching it, there would usually be follow-up development collaborations. But the result was unexpected — the project had been stopped.

“What happened?” we asked.

“We advised the client to stop the project,” they replied.

We “hatefully” asked why they gave up on such an important opportunity. Their answer was straightforward. They calculated the costs in line with the client’s ideas: the project required a huge investment, much larger than the client had imagined. With the current plan, the project would definitely incur losses. Either it needed to be re-planned or canceled altogether. After careful consideration, the client chose to cancel the project.

This incident happened about ten years ago, and today we see the massive money being poured into the major video websites. Compared to that company’s capacity, it indeed fell far behind in competing in this arena.

This incident left a deep impression on me because it was the first case I witnessed in my professional career where “canceling a project proactively” led to project success.

Perhaps you cannot understand what I mean by “project success” here. In my opinion, doing valuable work is important, and within this value lies not only what we “do,” but also the value of saving time and costs through “not doing” unnecessary things. My two colleagues prevented the client from wasting resources, so I consider this project a success.

The same principle applies to development as well. Programmers possess such strong technical skills that it seems natural to come up with technical solutions for everything. We faithfully automate every requirement, trying to automate the “world.”

However, the reality is that there is too much waste in this world from doing things we shouldn’t be doing. In our column, I repeatedly emphasize that we should ask more questions, with the purpose of not doing things that shouldn’t be done.

Beware of NIH Syndrome #

You can determine which tasks can be skipped from the perspective of requirements, but we also need to prevent programmers from “adding drama” themselves. Let me tell you about a common problem among technical personnel: Not Invented Here Syndrome (NIH Syndrome).

What does NIH mean? It means that some people don’t appreciate what others have done and insist on doing it themselves just because it wasn’t done by them, possibly resulting in various issues.

This phenomenon was particularly popular before the advent of open source. Many companies wanted to develop their own middleware and database wrappers. Although many companies now have their own unique frameworks as a result, the products they create are often extremely difficult to use due to limited expertise. Many people criticize these products while continuing to develop on top of them.

I thought this phenomenon would improve after the rise of the open source movement, but reality has proven me wrong.

For instance, this chaos has also emerged in the frontend field, with various frameworks that leave many frontend developers feeling overwhelmed and unable to keep up. Another example is when I once interviewed a programmer who had been exposed to Go at an early stage, and he wanted to write all the frameworks himself.

Because when he learned Go, there were indeed fewer frameworks, but the problem is that Go today is not the same Go he learned back then. Now, there is already a wide range of frameworks available, and there is no need to do everything on your own. At that time, I asked him, “What would happen to the company if you were to leave one day?” In reality, he had never considered this question.

After saying so many things, it all boils down to one thing: before writing code, ask yourself, do you really need to do it? If you can avoid doing it, then don’t do it until you have enough reason to do so. In Larry Wall’s words, you should be lazy and invest great effort into avoiding unnecessary energy consumption.

Embrace Automation #

After discussing the part about not wanting automation, let’s talk about the parts where automation is necessary.

First, let’s address an issue that you might overlook. While your daily work involves creating automation for others, is your own work automated enough? To be more specific, what processes do your code go through before going live?

Let me start with a terrible example. When I first started working, there was a time when I had to travel to a client’s site. Towards the end of the day, I discovered a bug in the program. During that time, our programs were written in Enterprise JavaBean (EJB) following the official recommendations. Many young programmers today may not be familiar with it, as it could only run when deployed to an application server.

My solution was to add some print statements, deploy it to the application server, check the output results, add some additional statements, and deploy again. This process repeated several times. Back then, we had to package and upload everything manually, which took at least ten minutes each time. Eventually, I found and fixed the problem with just one line of code. However, several hours were needlessly wasted.

Afterwards, I spent a long time researching how to automate incremental deployment, which simplified the process. This incident had a significant impact on me. It was the first time I realized how a deployment process could affect development and gave me a personal understanding of automation in the development process.

Compared to when I first started working, it is much easier now to accomplish similar tasks at the tool level. In the following sections, I will combine specific scenarios to introduce the current best practices.

You need to understand software design #

Finally, let’s talk about our main job, which is to provide the ability to create automation tools for others: software design.

Software design is a familiar yet unfamiliar term for many people. People are familiar with it because they know that software development requires design, and some can even name a few design patterns off the top of their head. People find it unfamiliar because in my career, I have encountered very few programmers who truly understand software design. Most people confuse design with implementation.

Let me give you an example. Once, I needed to create a connector between two systems to allow the upstream system to send messages to the downstream system. Perhaps you already know that what we need here is a message queue. However, in reality, we needed more capabilities than just a message queue, such as removing duplicate messages. A colleague recommended Kafka as the foundation for this connector, and I gladly accepted.

However, during the subsequent design discussions, we often had different views on the discourse system. I would talk about the capabilities this connector should have, and he would talk about what Kafka can do. The root cause was that I was discussing design, while he was discussing implementation, so it was difficult for us to discuss the problem together.

Why do I value design so much? In software development, everything else is subject to change, but the variability of design is something you can control.

Using the previous discussion as an example, although Kafka is currently popular, I cannot guarantee that I will not replace it in the future. Just a few years ago, message queues were still the strength of traditional middleware, but now they are slowly being forgotten.

I don’t want my design to constantly sway with a particular technology choice. If we have been working for many years and our knowledge system relies solely on various new frameworks and tools, we as programmers will be left constantly trying to catch up. Without understanding software design and focusing only on various tools, the result will definitely be getting left behind by new technologies, which is one of the main reasons why many people often complain about the fast pace of the IT industry.

Going back to Larry Wall’s statement, if you want to write a program that no one can find fault with, you need to understand software design. Fortunately, software design has not changed much over the years, so once you grasp software design, learning many frameworks and tools will become much easier. In the second half of this module, I will discuss the topic of software design with you to reduce the probability of digging pitfalls for ourselves.

Summary #

Larry Wall, the creator of Perl, once said that excellent programmers should have three virtues: laziness, impatience, and hubris. To become an excellent programmer, one should make machines work well for them, which requires a good understanding of automation.

When studying automation, it is important to know what not to automate and avoid wasting time. On one hand, we should avoid unnecessary tasks from the requirements. On the other hand, we should prevent NIH syndrome (Not Invented Here Syndrome) in ourselves and strive to be a lazy programmer.

For tasks that need to be automated, we need to reflect on whether our own work processes have been well automated while creating automation tools for others. And if we want to create good automation tools, we need to have a thorough understanding of software design.

If there is one thing you can remember from today’s content, please remember this: Automate your work with caution.

Lastly, I would like you to share how you understand automation after studying this lecture. Feel free to write down your thoughts in the comments section.

Thank you for reading, and if you found this article helpful, feel free to share it with your friends.