Original text: humanwhocodes.com/blog/2020/0…

Nicholas C. Zakas

Early in my career as a software developer, I saw my main contribution as writing code. After all, software engineers are paid by companies to write code and make software. It took me a few years to realize that there are many other things (managers, designers, product managers, sales people, etc.) besides writing code. Gradually, I found myself becoming less of a programmer and more of a problem solver. Sometimes the problem can be solved by writing code, and sometimes the solution involves no code at all.

Once I realized the value of solving a problem, I set out to determine the most effective way to solve it. Once I became the technical lead, I ran into a lot of daily problems. I had to figure out a way to act decisively, prioritize efficiently, and solve as many problems as POSSIBLE.

Eventually, I came up with a list of questions and asked myself every one that came up. I’ve found that asking these questions in turn helps me make the best decisions:

  1. Is this really a problem?

  2. Does this need to be fixed?

  3. Do we need to fix this now?

  4. Do YOU need me to solve this problem?

  5. Is there an easier way to solve the problem?

Each question is intended to reveal some information about the issue so that you can move on to the next step; Or, if you’re lucky, avoid it altogether. Each issue has a nuance, so it helps to describe each issue in detail.

Is that really a problem?

The first step in solving any problem is to determine if it is indeed a problem and needs to be defined. For the purposes of this article, I define a problem as one that leads to an objectively undesirable outcome if left unsolved. For example, leaving Windows open at night on a rainy day is a problem because the inside gets wet and can damage floors, furniture or other items. The solution to this problem is to prevent adverse consequences, so closing Windows before going to bed can prevent property damage.

When you’re in a leadership position, it’s common to receive complaints that sound like questions but are just opinions. For example, I’ve talked to a lot of software engineers who start a new job or join a new team and immediately feel that the team is doing a lot of things wrong: they’re using the wrong framework; Code style error; The organization of the document is wrong. How will they solve all these problems? This is a daunting task.

I asked these software engineers this question: is it a problem or a difference? In many cases, “wrong” simply means “not what I was used to or liked.” If you can be sure that the reported problem is not actually a problem, then you no longer need to spend resources on a solution. Team members who are dissatisfied with the way the work is being done is not an objective undesirable outcome. Disagreements between teams are fine in nature. If you are sure that the problem is not a problem, do something else.

Does this need to be fixed?

Once you have determined that there is a problem, the next step is to determine whether the problem needs to be resolved. If the consequences are tolerable and grow steadily or slowly, there is no need to solve the problem. For example, if a part of a Web application is used only by administrators (typically five or fewer people) and loads more slowly than the rest of the application, you can be sure that this is ok. The problem is narrow in scope and affects a small number of people in rare cases. Although it is a good solution to the problem, it is not necessary and the problem is small, so failure to solve it will not lead to bigger problems in the future. Another way of asking the question is, “What would happen if the problem were never solved?” If the answer is “nothing,” then you probably don’t need to spend too much time on the question.

Do you need to fix the problem now?

If you have a problem that needs to be solved, the next problem is to determine whether it needs to be solved now or can wait until later. Some issues are obviously urgent and need to be addressed immediately: the site goes down, the application crashes every time someone uses it, and so on. These issues need to be addressed because the consequences are immediate, ongoing, and likely to grow: the longer the site is down, the more money the company loses; The more times an application crashes, the more likely customers are to use a competitor.

It is also important to determine whether the problem can be deferred. It is surprising how many non-pressing issues emerge from the leadership. These are issues that require final but not immediate solutions. The most common problem in software that fits this description is technical debt. Technical debt is any part of your application (or related infrastructure) that is not performing well. It won’t cause major problems today or tomorrow, but it will eventually. In my experience, technical debt problems are rarely resolved until they become an emergency, when it is too late. But technical debt is not the answer to every other problem. It’s in the middle zone and it shouldn’t be done today, but it definitely needs to be done.

If you don’t have to solve the problem now, it’s usually best to put it off. Putting it off means planning to deal with it in the future, rather than avoiding doing anything about it. If now is not the right time to solve the problem, decide when: a week, a month, six months? Put it on your calendar or task management system so you don’t lose it. Another way to ask the question is “Is the problem urgent?”

Do I need to solve this problem?

This question applies most to anyone in a leadership position, but it also applies to anyone who has already accomplished too much. Is the question just your special skills, or can someone else do it?

This is a question I adapted from advice given to me by a mentor. I was complaining that I seemed to be collecting tasks instead of keeping up. He said I should ask myself, “Is this the Nicholas question?” There are things only I know how to do, and that’s what I should focus on. Anything else should be delegated to someone else. Another important tip he gave me: Just because you can do something faster than someone else doesn’t mean you should do it yourself. For most non-urgent tasks, it’s not important to finish them in a day or two.

So if the problem can be solved by someone else and you are a leader or have too much on your plate, delegate.

Is there an easier way to solve the problem?

After identifying the urgent problem that needs to be resolved, the final step in the process is to determine if there is an easier way to resolve it. The point is that the simpler questions must give you the same or similar results as the original problem while saving time (or other resources).

I was working on the new My Yahoo! Page, one of our product managers said that Beta customers had asked us to add resizable columns to the page. It was pretty complicated, because this was 2006, and Web browsers weren’t as powerful as they are today. The task isn’t impossible, but adding more content to an already JavaScript filled page to manage complex mouse movements and the need to save that information back to the server is a laborious, error-prone task.

I took the raw data from the customer feedback session to see if I could determine what problem the resizable columns would solve. In the end, no customer requested a resizable column (the product manager simply inferred the request from the complaint). Instead, they complain that they can’t get the new My Yahoo! . The page looks like their old My Yahoo! Page. We created a brand new format that didn’t match the old format, but it turned out that people really liked the old format. This allowed us to focus on a simpler problem: recreating the old format.

So we spent some time recreating the old format in the new page and talking to the customer. They were pleased that the new page now looked very similar to the old one. By solving simpler problems, we saved a lot of development time, and the customer was just as happy.

Fixing a problem isn’t always easy, but it’s worth taking a moment to check that the problem seems particularly serious or difficult.

conclusion

These five questions have become the basis of my approach to problem solving, not only in my work, but throughout my life. Going through these problems every time I encounter them has made me a more effective problem solver and generally happy with the results. Can’t calculate a 15% tip for my waiter? I would calculate 20% (or 10% if I am not satisfied with the service). My high school alumni office keeps sending me notifications that I’m not a verified alumnus? That’s not my problem to solve. Do I need to get a new driver’s license if I want to travel in the US? That’s my problem this year, but not right now.

There are many ways to solve problems, but I’m not sure mine works for everyone. All I know is that a solution is better than no solution at all. Life is full of problems, big and small, and you face them every day. Developing clear, repeatable strategies is the easiest way to make problem solving more tolerable.