On October 15, “Go+ Together! Go+ 1.0 press conference and Go+ Developer Foundation launch Ceremony” was held in Shanghai.
In this conference, PingCAP co-founder and CTO Huang Dongxu shared a unique theme, titled “Cognitive Psychology for Back-end Programmers”, “Interactive design needs to think one more step, tell users half step, let users take half step.” By fusing cognitive psychology with code and software that are closest to the physical world, Hwang shares how we perceive the external world and the two gaps we need to bridge. The following is the summary of Hwang Dong-wook’s keynote speech:
I’ve been reading psychology stuff, and it’s a weird thing to do as a programmer. I found a particularly big question, I don’t know if you have seen a meme – “How to exit Vim?” . This question got me into a deep thinking.
At that time, I always thought that GDB was not good because OF my intelligence, but then I thought it was Stockholm syndrome. I have been using Vim for many, many years, and many of my own Vim configurations have been maintained. I feel very proud of it. It took me a long time to master this difficult thing. I think the programmer community, especially the back-end programmers, often have a tendency to think that something complex is awesome and worship complex things. But, in the 21st century, why can’t you programmers make software better?
Back to why DID I read psychology? Is it because I find that a lot of C-terminal software, including a lot of consumer electronics, whether you buy an iPhone or an Android smartphone, nobody reads the instructions? When you buy a cell phone and you open it, it’s like nature knows where the start button is. Compared to a software like Vim that doesn’t even know how to exit, I think VSCode smells better. The contrast between these two things makes me think that systems programmers go one step further into the field of metaphysics, and that the field of metaphysics needs to start studying psychology.
I was reading a course on basic cognitive psychology, and there was a picture in it that I thought was particularly good. When people interact with the external world, there are probably two links. The one on the left is what we should do when we see something.
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 do not know which knob corresponds to which stove. If you put these knobs in a neat and simple arrangement, you can easily map them to.
I summed up a few things myself earlier. For example, design a database, or design a system software, write super stable, super good performance, but the user is not up how to do? I offer you theoretical support:
Bridging the implementation gap: interactivity
The first key to interactivity — “NO Surprise!” Concept model When you do something, your mind often has a subconscious preconception of what you’re going to do next, and if you don’t behave like that, it’s going to be weird. Most of you who have a driver’s license can drive almost any car you want, because almost all cars look like this. If you go beyond that, people get very confused and don’t drive.
For a programmer, seeing the “$” sign and the slide line doesn’t mean making money or money, but realizing that this is a place to knock things. Similarly, when you see a greater than sign followed by a glide line, you think of this as a place where you can hit something. Why is that? Because of habit. For example, when designing a basic software, avoid having five remote controls for a TV set with a very simple concept, or a consistent pattern. Here are a few examples of conceptual model design that are particularly good.
By the way, there are many programmers who, when designing software, focus only on the inside and ignore how outsiders see the software. I think too few articles and references have been written about this topic, and I hope more people will write about it in the future. The first example is UNIX. I now think that a simple thing is a very powerful thing, just like the most powerful thing in Euclid’s book is the five axioms, rather than the hundreds of theorems. UNIX is also great. Everything is a file, data is a stream, and pipes are cascaded streams. The second example THAT I want to isolate is the controller. This thing is too important.
2) The second feature of interactivity — no one reads the document for the programmer
In my opinion, the document is basically about the same as a dictionary, and we certainly do not learn Chinese by reading xinhua dictionary.
I don’t know if it’s universal, but at least for me, WHEN I use something new, I have a similar mental activity. For example, on GitHub or Go+, if I open a page with no idea what I’m talking about, MY eyes will keep looking for something that can be copy-pasted. If the code can’t be copy-pasted, I’ll scroll down until something that can be copy-pasted appears, and I’ll copy it to the shell and see what happens. For a project author, this is the one and only time you can win over an audience. I think most of the domestic software companies have never paid attention to this. In addition, the first shell command of Quick Start is crucial because it determines whether there is any follow-up.
One year I was at a conference in Brussels, and I was talking to a strange foreigner, and he got drunk and said to me, “Anything that can’t be installed on the APP Store is a gangster.” So the official manager must be your first choice.
Docker is also a good choice, but you can’t assume users have Docker on their machines, such as programmers on the front end.
What’s next after the first line of the shell? A lot of people notice the first step, and a lot of programmers think it’s done, but after the first line has been successfully installed, it’s best to direct the user into an interactive environment and tell the user what to do next. Here’s an example.
That’s what happens when I open TiUP’s website, a two-sentence introduction I’ve never read. As a programmer, I focus on the first line, copy it to the shell, see what happens, and the system immediately tells me what to do next.
Copy and paste again, and in less than a minute you have a local TiDB cluster. And finally, if you look carefully, the next step you can do is connect to the MySQL client, or you can do a bunch of other things, like guide data in and so on.
Another example is Telegram, which is very useful when doing robots.
When we want to do eco-collaborative development, for example, to use GitHub, we have to find the GitHub developer center, and then find the project there and then look at the documentation, all kinds of things are very complicated. Telegram Botfather is very good, can directly let it create bot, and can directly give bot names, the whole process is an interactive experience. Even though Telegram has an extremely long document, I have never read it. I can say this with great pride, and I’m sure Telegram botfather will also be happy, I never read the document can also develop robots. In terms of interactivity, the next step is to think a step further, tell the user half step, and let the user take half step.
Why do people think Redis feels so good? Because it’s fast, and fast makes people feel smooth. The physiological response time is about 100 to 200 milliseconds, and if you’re doing something for 100 to 200 milliseconds and you don’t get feedback, you think it’s a card. How do you make software enjoyable? A feedback will be given to you within 100 milliseconds. I’ve come up with three laws of feedback:
First, don’t reveal the inside concept! Don’t reveal the inside concept! Don’t reveal the inside concept! This is one of the biggest mistakes I think most programmers make when creating a document for users. Let’s say there’s something inside called an engine, and when you’re driving, you tell them there’s a problem with the third wheel of the engine. Second, expose progress and status in concise human language. Don’t talk nonsense, don’t talk nonsense. Third, feedback must be immediate. I’m going to blacken myself by giving you an example of TiDB.
This is a user-written question. For the user, who can tell him what Region is? What should we do next? Here’s another good example.
This is the database scanning process, although it is not fast, but because there is a progress bar constantly moving, you will feel very fast. This is the behavior of software that has been carefully designed to be interactive, not to “get the big idea” and scan slowly in the background for 30 seconds and tell you what the result is. It’ll tell you one by one, with a progress bar. There’s another very awkward question, but I haven’t figured out the answer yet. The variety of configuration files is a particularly unpleasant experience, especially for complex software. I don’t think any of us in this room like configuration files, maybe some Stockholm Syndrome programmers do or have. From the point of view of human nature, 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 not get the hands of the first change and then use. But based on the current human technology can not do that. The most troublesome aspect 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, and then exit and restart. If you make a typo, you may not know it until the next reboot. It’s a very messy process, and I’ve written some principles for it. In the current industry are generally not very good circumstances, can do the best degree.
The first point is to put it where a normal person can think of it. I especially don’t like configuration files in the “current folder”, when you are running in a strange environment, what is your current folder? The last line is my own mental burden, and the environment variable is the least mental burden. Environment variables are smaller than command line arguments, approximately equal to controllers, and worst of all, configuration files. This list is my own perception, not a particularly authoritative order. The last step in interactivity, like the Go+ syntax, takes a lot of Go, which is a good way to do it. There are many good examples in the world, including Docker CLI, Kubectl, Redis CLI are actually good, copy over.
Bridging the evaluation gap: observability
The first question of observability is “Who is observing?”
The answer to this question, as you all know, is that programmers, developers, observe. More than once I’ve heard of our own includes lots of friends, very proud to tell the customer “there are thousands of monitoring items in our monitor”, but since I studied psychology, only know that there are four people at the same time to focus on what the object number, more than four don’t know what is it, so, don’t do too much. The next problem is “distinguishing noise from information”. My rule of thumb for what is useful information is “follow the key sources”.
What are the key resources? For a system, I would basically soul test these 20 questions. For example, if you are suddenly given a completely strange environment for no apparent reason, you will probably know the state of the system as long as you understand these 20 questions. One of the most powerful characteristics of software that does well in observability is to “exploit human intuition.”
For example, when you see red, you know STOP and green means GO. I believe you have all used HTOP, I think the most ingenious point of it is the use of progress bar, red and green make people directly have an intuitive cognition of the CPU utilization rate of the system.
The shape of these fire charts is how often a small piece of data is accessed in the production environment. Instead of drawing these boxes, I can probably see that there is something wrong with the bottom, only one hot spot working in it. So if you look at that, you can see that there’s a problem, that there’s an auto-increment primary key. Before, I also thought that I was not skilled in using BCC because of my poor IQ. Until I used Go, I thought that the user experience of Go was too perfect. It would use some psychological skills of human cognition to make people pay attention to some abnormal things in the system.
Let me give you one more example, which is also a little exercise.
This is TiDB will soon launch TopSQL, not to tell you what this is a function, I believe you can also find the left and right there is something wrong with the green thing. The vertical axis is CPU usage, and the horizontal axis is time, where the different color blocks correspond to statements that occurred during that time. The green part is how much CPU this statement is taking up at this time, and we don’t have to go down to the exact number to figure that out. Observability is also particularly important, and that is the period.
An old driver and a new driver went to see the system separately, and I came up with one big difference. Older drivers automatically draw a timeline in their mind, focusing on the state of the entire business over the course of the cycle, while newcomers focus on discrete points.
Another point that is often overlooked is hindsight. I recently received a nuisance call from a user who hung up because of CPU problems, but I see no problem with the various monitors as all Settings are pre-set. But WHAT I found was that it was so weird, you know, like when you go for a checkup and you have your ear, nose and throat, but you can’t tell because you have something wrong with your gut or something. It’s a matter of intuition, and it’s scary. I’m going to have to build a feature that makes a Profile every minute, and that’s when observability saves life. In my opinion, anything written by a human will have problems. As long as there is a problem, someone must rescue and relieve the disaster. At this time, the user experience is the most valuable. I think it’s important to share this topic today. Thank you.
