Huang Dongxu: Cognitive psychology for back-end programmers丨Go+ 1.0 conference dry goods sharing

On October 15, the "Go+ Together! Go+ 1.0 Launch Conference and Go+ Developer Foundation Launching Ceremony" hosted by Qiniuyun was grandly held in Shanghai.

In this conference, Huang Dongxu, the co-founder and CTO of PingCAP, shared a unique theme, entitled "Cognitive Psychology for Back-end Programmers", "Interactive design requires one more thought. Tell users half a step. Let users take a half-step." Huang Dongxu merged cognitive psychology with the code and software closest to the physical world, and shared our understanding of the external world and the two gaps that need to be bridged.

The following is the content of Huang Dongxu's keynote speech:

Let me introduce myself first, my name is Huang Dongxu, and I am the co-founder and CTO of PingCAP.

I've been looking at psychology things, and it's actually weird to do so as a programmer. I found that there is a particularly big problem. I don’t know if you have read a slogan-"How do I quit Vim?". This question got me into a deep thinking.

Back then, I always felt that I didn't use GDB well because of my poor IQ. Later, I thought about the Stockholm syndrome of system software. I have used Vim for many, many years, and many of my own Vim configurations have been maintained. I feel very proud of this, and it took a long time to get this difficult thing to know.

I think the programmer community, especially the back-end programmers, often have a tendency to think that a complex thing is powerful, and especially advocating complex things. However, since the 21st century has passed, why can't you programmers make the software easier to use?

Why do I look at psychology? It's because I found a lot of C-side software, including many consumer electronics products. No matter if you buy an Apple or an Android smartphone, no one reads the instructions, right? When you buy a mobile phone and open the box, it seems that you know where the power button is. Compared with software like Vim that doesn't even know how to exit, I think VSCode is better. The comparison of these two things made me think that system programmers would take a step forward and enter the field of metaphysics. This field of metaphysics needs to start studying psychology.

I'm looking at a course on the basics of cognitive psychology. There is a picture in it that I think is very good. When people interact with the outside world, they probably have to go through two links. The one on the left is what we see. What should be done afterwards, there will be an implementation and evaluation immediately after completion.

Friends who have lived in the United States may often use this kind of gas stove. The problem with the design of this thing is that I don’t know which knob corresponds to which stove? If you arrange the knobs in a simple way, you can simply map to them.

Take the second example.

Do you think this doorknob feels weird? Obviously, Push is written on the door handle, but it is a shape that makes people pull it. Seeing the doorknob, I naturally want to pull it, but it actually needs to be pushed. This is a product that violates self-awareness.

I have summarized some things myself before. For example, if you design a database, or design a system software, it is written super stable and has super good performance, but what if the user just can't use it? I provide you with theoretical support:

1. Crossing the execution gap: interactivity

How to bridge the execution gap? ——In technical software, there is an important point called "interactivity".

1) The first key point of interoperability-"NO Surprise! Conceptual model"

When a person is doing something, his mind often has a subconscious presupposition for what to do next. If your behavior is different from the presupposition, it will be very strange.

Most students who have a driver’s license can basically drive any car as long as they go up, because basically all cars look like this. If you go beyond this mode, everyone will become very confused and will no longer be able to drive.

For a programmer, when he sees the "$" sign and the underline, what he thinks of is not making money or not, but he will realize that this place can be used to knock things. Similarly, when you see a greater than sign and an underline, you will also think that this place can be knocked on. Why is this happening? Because of habit.

For another example, when designing a basic software, through a particularly simple concept, or a self-consistent model, avoiding a TV with five remote controls similar to the design. Let me give a few examples of particularly good conceptual model design.

In addition, when designing software, many programmers only pay attention to the internal and ignore how external people view the software. I think there are too few articles and references in this area. I hope that more people can write similar things in the future.

The first example is UNIX. I think it is actually a very powerful thing to do something simple, just like the five axioms in Euclid's book, not the hundreds of theorems. UNIX is also very good, everything is a file, data is a stream, and Pipe is a serial stream.

The second example I want to pick up alone is the controller. This thing is too important.

In the basic software, there is an interactive mode used by the software called the control object, such as redis, which is commonly used by everyone. I found a particularly strange phenomenon. I asked ten back-end programmers who are doing infrastructure what is the best tool they have used. Eight or nine of them will say redis-cli. I believe students who have used redis will definitely know cli. The tools are impressive.

What is the difference between an easy-to-use software and a difficult-to-use software? The focus of redis-cli operation is "Everything is KV". Assuming that redis itself is a KV and the controller is also a KV model, it is very acceptable. Modifying the configuration in redis also adopts the KV form, and developers don't need to learn it separately.

The MySQL database is also the most natural way to provide interaction through the cli interface when operating any database or viewing the system status, even though SQL itself is a language used to invert data. It is normal to use SQL to control the database, but the biggest taboo is the confusion of correspondence.

2) The second feature of interactivity-no one can read documents for programmers

In my opinion, documents are basically similar to dictionaries. You certainly don't learn Chinese by looking at the Xinhua Dictionary.

I don't know if it is a common phenomenon, but at least for me, when I use a new thing, I will have a similar mental activity. For example, on GitHub or Go+, I open a page that I don’t know what I’m talking about. My eyes will always look for something that can be copied and pasted. If the code can’t be copied and pasted, I will pull down again until it appears that I can copy and paste. Things, copy it to the shell and see what happens.

For the author of a project, this is the only chance you can win users. I think most domestic software companies have never paid attention to this matter.

In addition, the first shell command of Quick start is very important because it determines whether there is any follow-up.

In this PPT, I briefly summarized this model.

One year I was in a meeting in Brussels, chatting with a stranger, and then he drank too much and said to me, "Any software that cannot be installed in the App Store is a rogue." So the official manager must be your first choice.

Docker is also a good choice, but you can't assume that users have Docker on their machines, such as front-end programmers.

What should I do next after the first line of shell is completed? Many people will notice the first step. Many programmers think that the installation is complete, but in fact, after the first line is successful, it is best to guide the user to an interactive environment and tell the user what to do next.

Here I give an example.

This is how I opened the TiUP website. There is only a two-sentence introduction, which I have never read. As a programmer, I focused on the first line. After I copied it to the shell, I saw what would happen, and the system immediately told me what to do next.

Then execute copy and paste, and a local TiDB cluster will be set up within one minute. Finally, take a closer look. In the next step, you can use the MySQL client to connect, or many other methods, such as importing data and so on.

Another example is Telegram, which is very useful when doing robots.

When we want to do ecological cooperative development, such as using GitHub, we must first find the GitHub Developer Center, then find the project in it and then read the documentation. Various things are very complicated. And Telegram's Botfather is very good, you can directly let it create a bot, and you can directly name the bot, the whole process is an interactive experience.

Even though telegram has a particularly long document, I have never read it. I can be very proud of this, and I believe that the botfather of telegram will also be very happy. I have never read the document and can develop bots.

Regarding interactivity, the next point is to think more about it, tell the user a half-step, and let the user take a half-step by themselves.

There are many programmers who think that if I think about it for you, and then do it for you, that's not enough. Man is actually a very strange animal. I mentioned earlier that people always dream of having self-awareness, but in fact we don't have it at all. But if people feel that they are in control, it will feel very good. So try to provide DryRun mode before doing the operation.

Today is the field of Go+, but I want to Amway rust.

Everyone, look at this Complier. After you make a mistake, it will tell you where you went wrong and how you should be. You certainly don't like a compiler forcing you to make changes directly.

The other most important point about interactivity is feedback.

Why do you think Redis feels so good? Because it's fast, it quickly makes people feel smooth. According to physiological theory, human reaction time is about 100-200 milliseconds. If you are operating for 100-200 milliseconds without feedback, people will think that this thing is a card.

How to make a software enjoyable? No matter what, no matter whether it is processed or not processed, give a feedback within 100 milliseconds, and people will feel very smooth.

I have summarized a three laws of feedback:

First, don't expose internal concepts! Don't expose internal concepts! Don't expose internal concepts! I think this is the most common mistake most programmers make when writing a to user's documentation. For example, there is an internal thing called "engine". When driving, you tell him that there is a problem with the third wheel of the engine, and the user will be blinded.

Second, use simple human words to expose progress and status. Don't talk nonsense, let alone nonsense.

Third, feedback must be immediate.

Let me hack myself and give an example of TiDB.

This is a question written by users. For the user, who can tell him what Region is? What should I do next?

Give another good example.

This is the database scanning process. Although it is not fast, everyone will feel very fast because there is a progress bar that is constantly moving. This is the behavior that a software that has been carefully designed for interactivity should behave. It is not to "hold the big move", scan slowly in the background for 30 seconds, and finally tell you the result. Instead, it will tell you one by one and set a progress bar at the same time.

There is another very embarrassing question, but I haven't thought of an answer yet.

Various configuration files are a particularly bad experience, especially for complex software. No one of us here would like configuration files, maybe some programmers with Stockholm syndrome would like or have liked them.

From a human point of view, from the point of view of an ordinary programmer, I think the system should not need to be configured, just like the iPhone, we can't change it before using it after we get it. But based on the current human technology, it has not yet been realized.

The most troublesome point of configuration is a slow feedback process. For example, if we want to modify the configuration, the first step is to find the configuration file, modify it after finding it, and then exit and restart. In case of a typo, it may not be known until the next restart.

This process is very tangled, for which I wrote some principles. Under the current situation that the industry is generally not so good, it can do the best.

The first point is to place it where normal people can think of. I especially don't like the configuration file to be placed in the "current folder". When you run the program in a strange environment, which is your current folder?

The last line is my own mental burden. Environmental variables are the least mental burden. The environment variable is smaller than the command line parameter, approximately equal to the controller, the worst is the configuration file. This arrangement is my own perception, not a particularly authoritative order.

Regarding the last step of interoperability, just like Go+'s grammar borrows a lot of Go from it, this is a good way. There are many good examples in the world, including Docker CLI, Kubectl, and Redis CLI. They are all pretty good, just copy them.

2. Bridging the assessment gap: observability

The next topic is observability.

The first question of observability is "Who is observing?"

Everyone knows the answer to this question. It is programmers and developers who are observing. I have heard more than once that our own people, including many friends and businessmen, are very proud to say to customers that "we have thousands of monitoring items in our monitoring." But since I learned psychology, I learned that people can pay attention to things at the same time. There are four objects. If you exceed four, you don’t know what it is, so don’t do too much.

The next question is "distinguish noise from information". As for what is useful information, my experience is "follow key resources."

So what are the key resources? For a system, I will basically ask these twenty questions in my soul. For example, if you suddenly inexplicably give you a completely unfamiliar environment, as long as you clarify these 20 questions, you will probably know the state of the system.

Software with good observability must have a particularly powerful feature, which is to "use human intuition."

For example, when people see red, they will realize STOP, and green is GO.

I believe everyone has used htop. I think the most ingenious thing about it is the use of the progress bar. The red and green colors let people have an intuitive understanding of the system's CPU usage.

The shape of these flame graphs is how often a small piece of data is accessed in the production environment. If I don't draw these boxes, I can probably see that there must be some problems below, and only one hot spot works in it. In this way, you can find that there is a problem, and an auto-incrementing primary key has appeared.

In the past, I also felt that I was not proficient in using BCC because my IQ was not good. Until I used Go, I felt that the user experience of Go was too perfect. Pay attention to something abnormal in the system.

Let me give another example, which is also a small exercise.

This is TopSQL that TiDB will launch soon. Without telling you what function it is, I believe you can also find the difference between the left and the right. The green thing is a bit wrong. The vertical axis is the utilization rate of the CPU, and the horizontal axis is the time. The different color blocks in it correspond to the sentences that occurred during this time. The green part refers to how much of the CPU is occupied by this sentence during this time. We don't need to be precise to the number to know that we can distinguish it.

There is also a particularly important point of observability, which is the period.

An old driver and a newcomer went to look at the system separately, and I summarized the biggest difference. Old drivers will automatically draw a timeline in their minds, focusing on the status of the entire business in the cycle, while newcomers will only focus on discrete points.

Another point that is often overlooked is the hindsight. I recently received a harassing call from a user. I hung up because of a problem with the CPU, but I see that all kinds of monitoring are fine, because all the settings are preset. But I found that the problem is too weird. It is equivalent to going for a physical examination. The physical examination includes ear, nose and throat, but it is actually something like internal organs, so it can’t be seen. At this time, it needs to be found by intuition, which is very scary.

I must make a function in the future. This system makes a profile every minute. This is the moment when observability saves lives. I think things written by people will have problems. As long as there are problems, someone must go to rescue and rescue disasters. At this time, the user experience is the most valuable.

I think the topic I shared today is quite important. thank you all.