I recently read a great book about products called “User Mind + Good Products Make Users Scream for Themselves”. Although it’s a product book, it’s all about how to make your users better. The author’s point is clear and original: sustainable and successful products are generated by recommendations (word of mouth). What motivates these recommendations is how users feel about themselves, what our products or services help them do or become. This is probably one of the reasons why paying for knowledge has been so popular in recent years.
The author has taken the user’s mind to the extreme, and this is evident throughout the book. The book itself is very user-oriented, so to speak, and it’s easy to read with just the right amount of vivid illustrations on key points or points. Think of the Head First books. Oh, and Kathy Sierra, the author of this book, is one of the people behind the Head First books.
When I read the book, I thought of myself more as a user of the book. So after reading the book, the biggest feeling is, can I use the book to make myself better? After all, user thinking is everything from the user. After thinking about it, I think so. In this sense, the book goes beyond discussing how to make a good product and focuses on thinking within the user’s mind. And this kind of thinking is the growth mode of thinking mentioned in the translator’s preface. This is also the purpose of writing this article, I hope that this kind of growth thinking can be used for reference on their way to progress. It would be great if it could help everyone, too.
How do you maintain your ideal growth curve?
User ideal growth curve:
If we follow the growth curve up and to the right, we will eventually reach the height of an expert. But most of us just want to get better, and a little improvement can be very noticeable. So what do you do to move up and to the right very quickly, even close to the ideal curve? Perhaps the answer can be found in experts. First we need to know what is an expert?
Experts don’t just mean what they know. The important thing is that they can apply their existing knowledge to practice. And they can repeat the process over and over again. Given a representative task in a field, experts perform better and more reliably.
And then what do the experts do?
- Continually build skills
- Keep wanting to succeed
Continually build skills
Build skills
To have expertise, you have to build expertise. Skill building is moving a skill from “can’t do” to “can do”. The ability to do is divided into two categories: effortful (unreliable) and proficient (reliable, internalized).
Our imagined skill building process might look something like this:
However, this is not an effective route to a high level of professional competence:
Here’s how the experts do it:
- Experts never stop adding new skills.
- Experts build skills both consciously and unconsciously.
- Experts refine existing skills.
We should pay special attention to this process:
Knives rust if they are not sharpened, and skills that do not require conscious practice will slowly deteriorate. So it’s not enough just to use it, but to take it out and practice consciously.
Deliberate practice
We often have the feeling that we put in the effort and time to practice a certain skill, but the results are just not good enough. Many people may blame this on their stupidity and lack of talent; In fact, it’s not. It’s probably the wrong posture.
With the same amount of time, experts will spend more time on deliberate practice, noting that it can be deliberate practice rather than deliberate practice. Practice helps prevent mediocrity. Here’s why: Mastering half a skill beats a bunch of half-skills.
More granular subskill learning is often the best way to build skills, but no one wants to spend a week on simple exercises. Deliberate practice is always right out of our current comfort zone. This is very important, because if we practice skills that are far beyond our current abilities, we are likely to give up because they are too difficult and go too long without feedback. If we practice a skill that is not difficult or challenging all the time, the consequences can be even worse. The more we practice in mediocrity, the more we strengthen the mediocrity, and the effects of practice are permanent.
The concise principle of deliberate practice: Achieve 95% mastery in one to three 45-90 minute sessions of a fine-grained task.
If this is not possible, we can divide the task into smaller sub-tasks or lower the requirements and criteria.
- If the task or skill is too complex(too many unmastered skills),Break it down into more fine-grained sub-tasks or sub-skills
- If the task is not complicated but simply too difficult, lower the requirements or standards
But the biggest problem most people run into on most professional growth curves is that stage B is piling up too much stuff. Instead of doing one thing at a time, there are so many things we want to learn and practice at the same time. This form of skill piling slows and stifles progress.
Experts put more time in deliberate practice, giving us the meaning of reference. Programmers are a profession that is obsolete if you don’t learn. Learning means building new skills and enriching your skill base. This is the time to use the above deliberate practice. First of all, we should make clear our learning goals, learn what this skill can help us to complete, whether it is worth our learning, do not be greedy, should determine their core competitiveness is what. Take reading good source code (as for why to read source code, will be mentioned later) for example, generally a project’s source code is worth reading, the project should be relatively mature. So the amount of code and the difficulty of the code should be not small, if from the latest and most complete version, it is easy to give up because it is too difficult. At this point, the task can be broken down, and you can see from earlier versions, this period of code is relatively small, the code design is easier to understand. Or you can study one feature of the project and switch to another later. For example, when we look at databases, the implementation of databases is incredibly complex. So we can start with a few of the main features, such as indexes, locks, and so on.
In addition, we need to pay special attention to the two problems mentioned above. One is that there are too many things piled up in stage B, we want to learn too much, but our energy is limited. This is the time to narrow down and focus on building the most important skills. Half a skill is better than half a skill. The other is that the more practice we do in mediocrity, the more it reinforces mediocre skills, and the effects of practice are permanent. There are a lot of older programmers out there who don’t have as much expertise as someone who’s been working for a few years. Is it all because of lack of effort? Otherwise, they try. They just stay in their comfort zone too long.
The perceptual contact
We often hear the argument that Chinese people do not learn English well because they never use English and just memorize it by rote. In the same way, experts become experts because they are surrounded by a better environment and are exposed to a lot of high-quality expertise. As an old Chinese saying goes, “Those who stay close to a ruler will be red, and those who stay close to ink will be black.” Right now, if you’re surrounded by great people, you’re probably not that bad. But unless certain conditions are met, simply reaching out to professionals won’t help you build professional competence.
One of the most vivid examples in the book is the sexing of chicks. It is extremely difficult to identify the sex of a newborn chick, but identifying the sex of a chick earlier, and separating the male from the female, can help speed egg production. In the early 1900s, the Japanese developed a method for determining the sex of chickens, but only a few experts had mastered the skill. The key now is to train new people with this skill so that it can be applied on a large scale. The problem is that as an expert in this skill, I don’t know how I did it. Your brain can learn something that you can’t. It’s not magic, it’s perceptual knowledge.
Here’s how they train the recruits to point out the sex of the chick, just make a random guess. Then the chick sex expert gives the couple feedback. Yes, no, no, yes. Every new person’s guess gets expert feedback. Eventually, as time went by, the couple got better and better at sexing the chicks. Only the new guy still doesn’t know why, you know?
In fact, with enough exposure to feedback, your brain begins to detect patterns and underlying structures without conscious intervention, and with more exposure, your brain begins to fine-tune its perception to find the real solution. Your brain is able to pick up finer features, distinguishing signals from noise, even if you can’t explain how it works.
Experts in all fields learn and use unconscious perceptual knowledge, and their brains know a lot more than they let on.
When you’re exposed to a lot of diverse examples, your brain starts to see what doesn’t change. Where perceptual learning can be useful, discovery is actually more effective than teaching. Our goal is to help ourselves become better by showing better examples.
Now you know why you should read source code, and read good source code. You don’t have to watch good programmers code, you just have to read lots of good code. So don’t blame your inability to write good code on the fact that you don’t have a great person around you, and don’t wish you had a great person to show me how to code.
So what about bad code? Want to see! Because sometimes it’s not a matter of whether you want to see it or not, it’s that you have to see it, and the project has bad code. Create discomfort when you do need to show or read examples that are wrong or bad. I used to tell my team that sometimes reading bad code makes more progress than reading good code. But only if you can tell what is good code and what is bad code. When you see bad code, you hate it in your gut, and you want to fix it. That’s an opportunity for improvement. The best way to learn to identify “bad” instances is to learn the underlying patterns of “good” instances. Refactoring to Improve the Design of Existing Code does just that, first identifying the characteristics of bad code and then identifying ways and solutions to refactor those characteristics.
Keep wanting to succeed
The obstacles
How do you keep yourself on your desired growth curve? Know that there is a gap between desire and reality. There’s something that interferes with us, there are two different types of interference gaps.
- Skills gap
- Relationship between the gap
Learning to program for the first time can cause you a lot of pain. This is true of anything worth your while. So when we are faced with difficulties, the first thing is to admit the difficulties. People don’t give up when they’re in trouble because they’re in trouble. This is because they do not know that their situation is normal. This is because they do not know that their efforts are in the right direction. This is because they don’t know that other people will have difficulties at the same stage. Those who give up, do not realize that difficulties are only temporary and normal.
After acknowledging the difficulties, we also anticipate and compensate for the problems we may encounter along the growth curve. Anticipate factors that might interfere with our progress. For example, when I am reading a book, I will mute my cell phone and put it somewhere out of my reach. That way, I don’t have to worry about whether I’m going to get a message from my phone until I finish the book. Then you have to compensate for your difficulties. Take programming as an example. The problems we encounter are similar to those of our predecessors. Forums and communities are also important.
Progress + Reward
We know what’s holding us back, but what’s drawing us in? I think it’s a sense of accomplishment. What we gain on the growth route will give us a sense of achievement. If we don’t get any benefit from progress, everything will be meaningless. So it’s important to have a growth path map, and just knowing that there is one is a powerful source of motivation.
For programmers, make a list of skills, ranging from beginner to advanced. It is then divided into levels and hierarchies. One possible approach is to spend twice as much time on each level as on the previous one. It doesn’t matter if the path isn’t optimal, because what matters is not the path, but the progress. Let’s be bold and just try. In addition, using domain specific terminology to communicate is not only useful, but also motivating. So talking to colleagues or writing a blog about our skills can be a great motivator.
Maintaining cognitive resources
In 1999, Professor Baba Shiv and 165 college students conducted a simple experiment. Half of the students were asked to memorize a seven-digit number and the rest a two-digit number.
The result in the picture above may be what many people think is that the brain needs more calories after work and needs to eat cake to fuel it up. But the researchers revealed a counterintuitive and shocking fact:
Willpower draws energy from the same resource pool as cognitive processing.
The participants who remembered the seven-digit number chose the cake not only because their brains needed more calories, but also because the memorizing task drained their willpower to resist the temptation of the cake. So we need to make sure that we’re using our scarce, easy-to-consume cognitive resources for the right things. The core mission is to reduce resource leakage.
Reduce cognitive leakage
-
To reduce cognitive leakage, delegate cognitive work to the outside world (so it doesn’t get stuck in the user’s brain)
Our brains can only focus on one thing at a time, reserving a “background process” for unfinished or interrupted tasks, and switching between tasks drains the brain of energy. People are more likely to remember unfinished or incomplete tasks, known as the Zeigarnik effect.
-
To reduce cognitive leakage, don’t give the user a choice
Choice is an expensive cognitive expense. I read an article about not studying or working in your bedroom. I strongly believe that studying is inherently a violation of human nature. If you choose to study or work in your bedroom, you are likely to spend the whole weekend torn between getting up and working or lying in bed. So don’t give yourself a choice. I now wake up early on weekends and go straight to work to stop myself from wanting to be lazy.
-
To reduce cognitive leakage, help users internalize their skills
Skills at stage B consume a lot of cognitive resources, while skills at stage C consume very little. So we would rather master one skill than learn too many at the same time.
-
To reduce cognitive leakage, reduce the need for willpower
Self-control and willpower are expensive costs of cognitive resources. To reduce users’ need for willpower, help them form a habit by assuming it doesn’t exist. Habits require little or no willpower. But our focus should not only be on developing new habits, we must upgrade or replace bad habits that are prone to plateau and mid-skill dilemmas.
Through the garbage filter of the brain
Our brains are always trying to distinguish between noise and signal, which is a good thing, but we can’t control the filter. So there’s another thing we need to do, to stop the brain from trash the things we should be focusing on.
We have to help the brain agree:
- This is a matter of concern
- This is something to concentrate on
- That’s something to remember
The brain likes to learn on the go, not by reserve. This is also why the same working hours, different people’s ability to improve greatly. If your job is challenging, you’ll always need to learn new skills to meet the needs of the job, and learn on the go, which our brains love. Instead, your work is not challenging, and even though you’re constantly learning, you’re never using the new skills you’re learning. We often get the feeling that much of what we learn in the moment is largely forgotten over time because our brains don’t like reserve learning. So we can use skill mapping to validate the usefulness of knowledge by mapping knowledge to skills to validate (reduce) the knowledge that must be learned. Delete, delete, delete the excess knowledge directly.
Convince your brain with application scenarios. When we learn abstract skills that are hard to understand and remember, we can try to convince our brain with application scenarios. For example, when learning the five basic data structures of Redis (now six), you can think about the scenarios in which each structure can be applied. Hash can be used to record the number of likes, comments, and clicks on a post; Zset can be used to record hot list post IDS and so on.
The last
Work hard, SAO year, achievement outstanding oneself
