In the previous article, I once mentioned that “the value of a technician is not in how beautiful the code you can write, nor in how large and comprehensive the architecture you can design, but in your ability to solve problems, and in your ability to use technology to serve the business”.

Recently, I encountered some phenomena in my work, which reminded me of this sentence again, and I tried to think about how to improve my problem-solving ability. Is there a methodological means or technical framework to practice it?

Let’s start with a phenomenon or two:

  1. A colleague reported that there was a Bug mentioned in the test. When a user has more than 50 card information bound, the data displayed in the background will be confused. I asked if it is possible to limit the number of bound cards to less than 50. I asked: What do you mean the data show confusion? A: Not sure; I ask again: why is there chaos when there are more than 50? Is there any possibility of chaos when there are less than 50? What are the reasons for the chaos? A: I don’t know. I say you figure out what “chaos” is, and then figure out why “chaos” is there before you talk about solutions. After some communication with the tester, he told me that the display was not chaotic, but incomplete. I checked the implementation because I had done string concatenation on the server, and it was truncated if it exceeded the number.

  2. A colleague is complaining that this problem is difficult to reproduce, I do not know how to solve it, whether to optimize the whole. I asked him what is the purpose of your optimization, is to optimize the current implementation of the process, structure? Or do you optimize to solve this problem that is difficult to reproduce? A: To solve this problem. I said that you did not locate the problem, how to solve it through optimization, not afraid of old problems are not solved, optimization out of the new problem?

Have you ever said or heard “This problem is too complicated for me to solve”, “I can’t do this feature”, or “I don’t know why this problem is happening”?

The above phenomena and utterance may be a reflection of a person’s immature ability or methods to solve problems. So how to improve the ability to solve problems, I think first of all, we need to seek changes in the way of thinking or habits of thinking. I found an article online called “How to Think Like a Programmer — Lessons in Problem Solving” (see the reference section at the end of this article) that describes 5 steps to help people develop a mental framework for effective problem solving. This paper is based on these five steps, combined with their own understanding and experience.

“Everyone in this country should learn computer programming because it will teach you how to think.”

Think like a programmer

What does it mean to think like a programmer, and how does it need to be done?

Thinking like a programmer is essentially a more efficient way to solve problems.

Problem solving is a meta-skill

What is meta-skill? In the analogy of metadata — data that describes data is called metadata, I understand that meta-skills are skills that improve skills, which means that once you have the ability to solve problems, you can use that ability to improve other professional skills.

The ability to solve problems is also the most important ability, more important than programming language proficiency, debugging ability, and system design ability.

Ways to improve your problem solving skills

The way we usually solve problems might be:

  1. Try a solution.
  2. If this solution doesn’t work, try another one.
  3. If that still doesn’t work, repeat step 2 until you happen to solve the problem.

This approach has been defined by author Richard Reis as the worst way to solve a problem. Not only is it a waste of time, but it is also a matter of luck.

Through the analysis of the thinking frame of excellent programmers in programming, the author concluded that the best ways to improve the ability to solve problems include:

  1. There is a framework for dealing with problems
  2. Repeat the exercise using this framework

So, when you encounter a new problem, how do you solve it?

Step 1: Understand

When confronted with a problem, we should first understand the problem itself. Most of the time, problems are only difficult because you don’t really understand them (often due to inadequate communication), and understanding a problem is the first step to solving it.

How do you know if you really understand a problem?

The most effective way is to try to say it in your own words to see if there are any logical holes. When you can articulate a problem, you understand it. Good programmers write down their problems, sketch out a flow or sequence, or validate them with product managers, other developers, testers, etc. This process is to determine whether their understanding of the problem is biased.

“If you can’t explain something in simple terms, it means you don’t understand it” — Richard Feynman

When faced with a new requirement, you should understand the context in which the requirement is generated — who, by what actions, when, to achieve what goals? If the scenario and its behavioral logic make sense, if the design has any holes, then discuss the problem with the requestor and confirm it, rather than taking it out of context or coding it without thinking about it. Don’t be a code porter. Be a thoughtful programmer.

Similarly, when faced with a Bug, you should first understand the context in which the Bug was created — who, in what context, and through what actions? To trace back to the source, locate the origin of the problem in where. I think it is more important to locate the source of the problem than to solve it! You can only solve a problem if you get it right, and there are many possible solutions. And in terms of time spent, locating the problem often takes up more than half of the total problem solving time.

If you don’t get to the root of the problem, you may not only do nothing to solve it, but you may even introduce new problems. Common fixes include high CPU usage, running out of memory, and upgrading the server configuration (which may have to be done again in two days!). ; The interface timed out – increasing the timeout (which may result in user complaints or other dependent service cascaded timeout), and so on.

So in daily work, how to locate the root of the problem? For common problems, you can find the problem by viewing logs. For difficult problems, you can use the following methods based on the nature of the problem:

  • For problems that are easy to reproduce: Debug is commonly used to track data flow and change through IDE breakpoints, and check whether data input and output are correct one by one. You can use techniques such as conditional breakpoints and exception breakpoints to improve debugging efficiency.
  • For problems that are not easy to reproduce: you can compare them by comparing similar functions or implementations elsewhere to find the difference between the two. The difference is often the problem. Analysis — read the whole process code, clear the logic of each link, analyze and locate problems; Log method – Add logs in each key link, mirror the scene, and analyze the logs to locate the problem when the next time it reappears.

Step 2: Plan

Understanding the problem, then the solution to the problem. Don’t tackle a problem without a clear plan, and don’t leave it to chance. Many developers tend to take a quick look at requirements, open the IDE and start loading code, only to find that it either doesn’t match the requirements or is full of bugs.

To make a plan is to make strategic steps to solve a problem.

Plan your solution for both requirements and bugs. Design the various links in the solution, such as the data table design of business requirements, interface design, flow logic, the specific implementation steps of Bug repair. Give yourself some time to think about and rehearse the possible bugs and impacts of the solution, and what better solutions might be available.

Don’t go straight to the code without a clear solution. Take a break and give your brain time to analyze the problem and process the information.

Step 3: Break it down

This is the most important step in the frame of mind.

Decomposition, is to simplify the complex, is the idea of division and rule we often say, resolution method – the big problem is divided into a number of small problems, and then beat each small problem one by one, and then merge summary. Microservices architecture, MapReduce algorithms, are all examples of this thinking.

Don’t try to solve a complex problem at a time, but complex problem is decomposed into several simple question (or questions), start from the simplest subproblems (the simplest means that you know how to solve it or it is easier to solve, or the sub problem does not need to rely on other sub-problem), one by one to solve step by step. Once you’ve solved all the subproblems, connecting them together usually means you’ve solved the big, complicated problem.

The ability to break down problems is the cornerstone of problem solving. This is a skill that good programmers use most often in programming, for whom the ability to break down problems is more important than programming language proficiency, system design, etc.

Step 4: What if I get stuck?

What happens when you understand the problem, make a plan for the solution, break down the complex problem into subproblems, and still get stuck working on the subproblems?

First, calm down! Then tell yourself that this is normal and happens to everyone.

The difference between a good programmer or problem solver and the average person is that they are more curious, more patient, and more focused on solving problems than they are on getting angry or whining about them.

Here are a few things to try when you get stuck:

  1. Debug: Perform step by step debugging until you find out what is wrong.

“The art of debugging is what you tell the software to do, not what you think you tell the software to do.” – Andrew Singer

  1. Reassess the problem: Step back and look at it from another Angle. Don’t let yourself get lost in the details. Sometimes it’s easy to get lost in the details and lose sight of the more general principles. Another way to reevaluate a problem is to start over. You can delete (roll back) everything you’ve already done and start over.

  2. Search for solutions: Use search engines to find solutions to similar problems and learn from them. Use search engines need to learn to refine keywords, the more representative keywords, the easier to find answers. Should take reference view of the result of the search, rather than copy, to understand why this treatment can solve the problem, and solve the problem after can understand its upstream and downstream, in turn, extension or related knowledge, such as SQL query slowly, found that the index is not effective, can be extended to understand what are the scenarios can lead to index the failure; For example, concurrency problems, you can learn how to ensure thread safety, synchronization mechanism, locking mechanism and other relevant knowledge. In fact, you can always do this even if the problem has been solved, because you can learn more from other people’s solutions and upstream and downstream knowledge.

  3. Ask for support: When all else fails, ask your colleagues, superiors, or friends for help. If it’s an open source project, post to the open source community, tech group, or Github issue list for help.

  4. Record problems and solutions: Record your problems and final solutions in an (electronic) notebook for later review or reference.

Step 5: Practice

Rome wasn’t built in a day, and you can’t expect to become a problem solver by solving one or two problems. However, if you can approach problems with a learning attitude and develop a frame of mind through the four steps above, each problem is an opportunity to improve your skills. There is only one step to becoming a problem solver: Practice, practice, practice. Practice in questions to train your thinking patterns and habits.

“I am not afraid of the man who practices a thousand kicks at a time, but I am afraid of the man who practices a thousand kicks at a time.”

conclusion

In fact, the ability to solve problems, no matter in the field of IT technology, or in every other field, is a basic skill. Before you say “THIS is a problem I can’t solve” or “this is a problem I can’t locate”, try this advice on understanding, planning, breaking down, and getting stuck. Be patient and practice step by step, and you may see the light at the end of the tunnel. By following this pattern or habit, you may have become a problem solver without even realizing it.

Reference:

  1. www.freecodecamp.org/news/how-to…

Original address: blog.jboost.cn/think-like-…

[reprint please note the source] Yu Ge, you can pay attention to the author’s public account: Halfway Yu Ge