Đã đăng vào thg 7 22, 2021 8:18 SA 17 phút đọc

267

Do you know how to think?

Bài đăng này đã không được cập nhật trong 3 năm

About Us

We are MMJ Vietnam, a product company. We are posting a series of articles about becoming a matured developers with a good mindset as we want to work with such people. We are now hiring front end dev. Contact to hr@mmj.vn if you're interested in us.

VNese version

Introduction

We are working in a software industry and building software everyday. When building softwares, unlike physical works such as construction, we need to spend a lot of time for thinking. So you've been thinking for many hours every day and you can consider yourself as "thinking expert", right? If someone says he is swimming expert, then you would expect he knows how to swim and he can teach you. Then, do you know how to think and can you teach me how to think?

If you think these quesitons are a bit too big, you can answer the following questions instead.

What is the goal of thinking?
What it the input and output of thinking?
How can you assess if you're thinking clearly or not?

Before reading further, please think about the questions above by yourself.

I personally had this question when I started my career as a software developer. I was thinking about how to improve my productivity then thought that improving the quality of my thinking would be high impact as I am spending most of my time for thinking about something. Then I was so shocked to find that I could not answer the questions above by myself. I was really really shocked. No one ever taught me. I've never questioned by myself. How can I be confident when I can't answer them?

After thinking for a while, I came up my own satisfying answer. Since then, I feel my thinking process is much clearer than before especially when I am facing with unknown problems, unclear problems or even undefined problems. This is one of my highest impact discovery in my life. It might be obvious for some smart people, but anyway I will share my findings here.

What is "THIKING"?

So here is my definition of thinking. In my definition, it consits of the following 3 steps.

Make a rough question
Split the question into smaller and clearer sub-questions.
Repeat step 2 until you can give answer to the known/small questions

Let me explain. First of all, when we think about something, we always have questions in mind. Always. See the following examples.

Think which folder you put this class
Think which bug we should fix first
Think what to eat for lunch

As you see, the verb "think" usually receives a question. However, there are many cases we "think" without any clear question. Read the following conversation between a staff and his boss.

(Boss): So what is the progress of the task of finding the most suitable databse?
(Staff): Sorry I am still thinking about it.
(Boss): OK then what are you thinking about, specifically?
(Staff): Now I'm still doing research.
(Boss): What research specifically?
(Staff): I am finding the best database for our service.

From this very short conversation, it is very clear that he is not clearly thinking at all. What the staff speaks is just re-phrasing what the boss say and has no information about why it is delayed or what the boss can help.

The good conversation should look like this.

(Boss): So what is the progress of the task of finding the most suitable databse?
(Staff): Yes. I am still stuck of it. Our DB's workload would be 90% insert and 10% read. So we need to find a database that has good insert performance.
(Boss): Yes right.
(Staff): So I found two databases: Cassandra and MongoDB. But I have little idea how to compare these two databases. According to the document, both of them say they are fast.
(Boss): OK the architecture of two databases are totally different. I can have a quick lecture about the difference. Don't believe their marketing document.

As you see in the second conversation, the staff's thinking is clearer than the first guy. He first asked himself "what is the requirement that the new database needs to satisfy" and got the answer "90% insert + 10% read". Then he founds two candidates and then he thought that he needs to understand the difference between two databases.

The first guy, on the other hand, does not look like he had any specific question in mind. Instead it looks like he just randomly searched "good database" "fast database" and waste time reading random documents.

So the difference comes from how they make questions. The first guy start working without having specific question. The second guy always makes question he needs to answer, then work on it. In other words, the first guy got a knife and finds something to cut, but the second guy decided what to cut and finds the suitable knife. Smart people always start from question. But stupid people always start from solution. It is too obvious that a solution without a question is useless, right?

So if you want to think about something clearly, what you have to do is to define your question very clearly. More importantly, if you define a right question, you almost automatically get the answer. So the most important part of thinking is to define a clear question. Finding answer is a very tiny part that anyone can do. It means that the most important skill in your life is how to make a clear question. If you have this skill, you can think much faster and more accurately. If you don't, your thinking is more like random, depending on luck.

Again, look at the definition of thinking.

Make a rough question
Split the question into smaller and clearer sub-questions.
Repeat step 2 until you can give answer to the known/small questions

Schools teach us problem solving, not problem finding

In Japan, at schools, we are always taught how to solve a given problem. We are always given clearly defined problems and expected to give the right answer. If you give a wrong answer, you're loser. The more problems you can solve, the smarter teachers think you are. I believe Vietnam is the same. We are all familiar with this game.

But the truth is, the real-world situation is so much different from schools situations. In the real work or life, problems are never well defined.

In schools, we are usually given problems that are

Clearly defined
Known solution exists
Have exactly one answer. If you're given an unclear problem, you can even blame your teacher.

But in a real situation where high impact problems exist, the real-world problems look like

The problem is very umbiguous like "what database should we use?". We even don't know what is the goal.
No one has ever solved it before. Google will not answer how to solve it.
Maybe there is no answer. Or maybe there are so many possible answers and you have to choose the most suitable one for your situation.
When we choose from multiple possible solutions, we have to find the best balance between multiple criteria (performance, security, productivity, scalability, stability, ...), not only one criteria, depending on your situation.

So, very unfortunately, what we have learnt at schools is not very useful in the real life. What is more difficult and what makes you earn more is to find the right problems. How to solve the problem (coding skill, knowledge about how to use some software) will not make you outstanding because so many people can do it.

Defining right problem

Here are some examples of unclear problems in real world.

What database software/application framework should we use?
How can we improve our productivity?
What technology should I learn now? How much time should I spend?

They obviously look different from schools problems like math equations. And usually it is hard to answer directly because

The question is too big
The question is too blur
The question might be wrong

So before you answer to the questions, you have to polish your question. It means you have to split a big question into small ones and make each word very clear. Also you have to clearly understand your situation. You need to have accurate data.

Here are steps.

Step 1. Write it on a paper

The first and very important fact is that you have to write the initial question on a paper. You might think it is not necessary because you can think anything in your brain. But it is really really important.

There are a few reasons but the most important reason is that your brain is not reliable, or actually broken. Every time you read/write, it almost always has some error but you don't notice that. Maybe you should think your brain as a completely broken SSD which pretend to work normally. If you have a broken SSD, you will never use it as a storage, right? Then don't use your brain as a data storage.

This is especially true when you store text information in your brain. Our brain is not designed for text information. And question is in text format. So you have to write your question on a paper.

Step 2. Clear 5W1H

Once you write the initial question on a paper, check if 5W1H (Why, What, When, Who, Where and How). For example if your initial question is "Can I develop a great service?" Then you need to write down further questions like:

Why do I want to build it? For money? For interest?
When (or until when) do I want to do?
Who will do it, I or other people?

Step 3. Give definitions

The next step is to give a clear definition of each word. Let's start by example.

When you have a question "what is the best database for this project?" then you have to define what "best" means. In this example maybe you need to choose what quality criteria are important: performance, scalability, maintainability, durability, security, data flexibility, development easiness, ...

The answer totally depends on your situation. If your service is financial service for millions of people, maybe performance, scalability and security might be the most important ones. If your service is drawing app for small number of people, then data flexibility and development easiness might be the top concern. So understanding your situation with high resolution is very important.

You can also clarify 5W1H for it. For example

Best for who? For users? For customers? For your boss? Maybe all.
Why is it best? Saves money? Saves time? Fun?

By this way, you can divide a big question into smaller problems.

Find high performance eand scalable database
Find how to make it secure

You can even go deeper by asking what is "high perfromance" and what is "scalable". Then after some calculations, you can get the following questions

Can we handle 10,000 write / second and 100,000 read / second?
Can we add new cluster node easily with no downtime?

You need to repeat this process until you feel every thing is crystal clear. You should not leave any ambiguous word.

Step 4. Give answer

Once you split your questions smaller and clear enough, it is not so difficult to give an answer. If your question is "Can we handle 10,000 write / second", you can just find some document or you can just run a performance testing by yourself.

After giving answers to the most of the small questions, now you have much more clear view about your original problem. And based on your understanding, you can choose a better option, if not the best.

Extra Step. Ask verifying questions

Sometimes there is a case that your initial question is totally wrong. To avoid such mistakes, you should ask many verifying questions as much as possible.

Is it possible? How much time will it take?
Is it true? Is there an evidence?
If it is so easy, why no one does it? What are the typical solution?
Do we really need to solve this problem? What is the impact if we ignore this problem.
What is the worse case scenario?

Example : Evaluating a software

Think about a case that you are asked to evaluate a software so that team can decide to use it for the next project or not.

Without clear questions

If you work on this task without clear mind, it will proceed like this.

Hmm I don't know where to start. Let's just install the software.
Ok It runs. Then try sample code.
I feel it is very fast and easy. I have a good impression.
I checked the document. It is quite a lot. I just read a few pages randomly. I think we can solve any problem with this amount of document.
Hmm I have no idea what to do next. So I think it's time to stop the research.
From my research I have good feeling about this software. I also heared that many people say it's hot. So I think we can use it for our next project.

You can see the process is a kind of random walk which depends on luck. It is not a professional work at all.

With clear questions

Let's first define what criteria is the important ones. It should be writing scalability and durability.
To assess scalability, we need to understand their architecture. Let's read the architecture section of the document. We can also check github issues if there are significant scalability issues unsolved.
To assess durability, we need to build a cluster and conduct some durability testing like power-off one cluster node while it's running.
It seems it satisfies our requirement for the two major criteria. So let's go on to the basic evaluations such as performance, backup, replication, that most of databases have.
We have answered all the questions so let's stop the research here and discuss with team about the 2 risks we found.

This type of thinking process is also good for your growth.

Relation between question and smartness

As you saw in the above example, if you always think with clear questions, your research will be always to-the-point and your knowledge will be far more practical. You can even answer confidently why the database you chose is better than others. But if you think without question, you only have superficial understandings. Your answer to why you chose it will be very unreliable like "because this is fast".

To be very frank, the smartest people ask so many questions, and silly people rarely ask questions. Indeed, smart people are smart because they ask so many questions and silly people are silly because they never ask questions. Because they ask questions, they learn much quicker and their knowledge is practical.

In other words, The number of questions you have will define how deeply you see the world. If you rarely have questions about anything, your intelligence level might be same as dog and cat. I'm not joking.

Bad Habits

OK then now we've got how the right "thikning" looks like. To give you better understanding, let me explain about several "bad habits" that so many people do.

Bad Habit 1. Talking about solution before talking about problem

As I said in the beginning, a solution without defining problem is useless. But in my personal experience, 98% of people do this. In a meeting, sometimes someone say "we should do this or that" suddenly. Then I often have to ask "for what?", even though I knew that the proposed solution will improve some part of our product. You know our time and resource are limited. So, when we solve a problems to solve, we first have to identify which is the most important problem, and next we need to find the most effective solution to the chosen problem. But what many people do is to throw away a random solution to a random problem. If we do that, our work must be very inefficient and low-impact.

I know we like to talk about solution because talking about solution is very easy and fun. But you need to understand that solution without problem is low impact.

Bad Habit 2. Discussing without sharing questions

Similarly to the bad habit 1, if a group of people need to discuss about a problem, the first thing we have to do is to write the question on the wall so that every one can know what we are talking about. Also, once the question is shared, we have to keep focus on the question. All the opinions in the discussion should be related to the question.

Poorly organized meeting looks like this: Facilitators suddenly ask "please give your opinion" without clearly telling what is the problems we're discussing. And members give comments about totally unrelated things to the main question. As a result, the meeting will take so much time with no output. They keep talking about everything in the world. Meetings sometimes end not because we've got a nice conclusion but because we have nothing more to say. Is it productive?

Bad Habit 3. Worrying without questions

When we had trouble in our life or work, some people keep worring or thinking about the problems and completely stuck at the same place for months or even years. They just scratch their head, crying in their pillow and keep saying "what should I do?" without taking any action. After months, they are still complaining exactly the same thing with no progress. Then they suddenly make an emotional decisions with no logical thought.

Is it familiar to you? This happens when you don't have a clear question in your mind. You have to describe what is the problem and what solutions are possible.

So you should ask questions like

Why don't I like the current situation? What action of which person makes me feel so bad?
What is my expectation? Is it reasonable?
To solve the root cause, what action is needed? By whom?
Did I have right communication with right person? Or do I just expect someone to miraculously notice and solve my unspoken problems and do I just complain until the miracle happens?

Here are a typical conversation between mother and her crying daugter

Mother: Why are you crying? Because you are sad?
Girl: no
Mother: Because you are angry?
Girl: Yes
Mother: What made you angry? Because you could not get the chocolate?
Girl: Nooo. Because they laughed at me.
Mother: Okay poor girl. What do you want them to do? Let's talk with them.

In this conversation, mother tries to help her daugter to describe her emotion. Specifically, she helps to clarify the following elemens.

What emotion makes her crying.
What action of someone triggered that emotion
What is her expectation
What she should tell them

This is a general framework to get out of emotional situation. You can ask the 4 questions above to yourself when you get emotionally stuck.

Bad Habit 4. Solution mania

Working as software engineer, I've met many developers who are overly interested in solutions rather than problems. Here solution means like new languages, tools, frameworks React, Angular, Typescript, Rust, MongoDB, Redis, ...

They like to learn many technologies. They want to spend time for those tools instead of patterns, theories or mindsets. They talk a lot about what technology is hot and what they know without deeply understand the theory. For them, "growing up" means to add new knowledge or hard skill. So their knowledge might be wide but not so deep.

The point is, we have these many technologies in the world because we have many types of different problems. Each type of problem has different solution. So to have a good understanding about a technology, we need to understand what problem the technology is designed for. With such understanding, you can choose the right technology for your specific case. If you can't choose the appropriate technology, what is the meaning to have knowledge about so many technologies?

Also, learning new technology will not make you so valuable in the market because learning new knowledge is not difficult at all and those knowledge will be outdated after a few years. Instead, learning about computer science theory, architectural design of each software and their pros and cos, having a good mindset and discipline, will make you an awesome developer. What you need is to be able to find the right technical problems to solve. Finding the right solution (which framework, database, ...) is easy.

Conclusion

So the process of thinking is actually process of discovering the right question. Once you have the right question, you get the right answer. We should always spend time for finding the right problems.

We also should try to ask as many questions as possible. If you ask so many questions, some people will think you are stupid. Don't care about it.