From f11408578a4b5c6983cb7c3987f9dadeca0d7be5 Mon Sep 17 00:00:00 2001 From: ida-ccc Date: Sat, 28 Feb 2026 12:43:21 +0800 Subject: [PATCH] Update understanding.md --- _mental_models/understanding.md | 92 ++++++++++++++++----------------- 1 file changed, 45 insertions(+), 47 deletions(-) diff --git a/_mental_models/understanding.md b/_mental_models/understanding.md index c84ce3d..32ba16f 100644 --- a/_mental_models/understanding.md +++ b/_mental_models/understanding.md @@ -6,14 +6,16 @@ summary: Understanding enables us to find sustainable solutions prerequisites: --- -#### Description +## Description -When we overcome a problem but don't fully understand why, it doesn't become easier to solve it next time. When we overcome a problem and fully understand it, next time we see it becomes a piece of cake. For this reason our goal should be seeking to understand rather than getting it over with. +When we overcome a problem but don’t fully understand why it happened, it doesn’t become easier the next time. We may fix it today, but we will struggle again tomorrow. -When there is a problem we can take 2 approaches: +When we overcome a problem and truly understand it, the next time becomes easy. What once felt confusing becomes simple. - 1. Focus on understanding +For this reason, the goal should be understanding, not just getting it over with. +When there is a problem we can take 2 approaches: + 1. Focus on understanding 2. Focus on fixing Markdown Monster icon -#### Examples: - -##### Software Development +### Examples: -Here is an example of how my co-worker implemented this model. +#### Example-1 -"I was trying to solve the a bug where users ended up not taking action X. I got curious and wrote queries on how many users were running into this bug. I saw that 5% of people did not take action X because of this bug. But I also discovered that another 10% also did not take action X. I dived into why that was the case ; and turns out it was due to a logic (programming concept) we impleneted. I looked at the submission that created the logic that was based on an assumption. Then I asked 5 players their thoughts about the result of this logic and turns out none of them want this feature. Then I ran this poll in the community to verify it. I solved the initial bug, I created design tasks for the second bug and I saved the queries so it'll be easy for us to run them in the future." +**Software Development** -Here the developer has acquired a good understanding of user behavior, instead of solving an unwanted bug they figured out if it was necessary for the users, then created systems making it easier for future developers. +Here is an example of how my co-worker implemented this model: -Another time they said something like this: +He was trying to solve a bug where users were not completing an important action. -"I was trying to solve the rendering problem, but I didn't know how rendering worked. So, I spent 15 minutes learning about it. Then, I realized I didn't understand how our library rendered, so I dedicated another 15 minutes to understanding it. After that, I became curious about how we were using the library, so I spent 15 minutes gaining clarity on that aspect. It dawned on me that we could solve our rendering problem by changing just one line of code. Additionally, I noticed that our rendering process was not optimized, so I submitted a task to refactor our rendering engine, which would clean up our codebase. I also created two other tasks, which are of lower impact, but will further optimize rendering when necessary." +Instead of only fixing the visible issue, he became curious. He ran data queries and discovered that 5% of users were blocked because of a technical bug. But he also noticed that another 10% were not completing the action for a different reason. -The developer understood the problem by breaking it down into its smaller components, which helped him solve it and become an expert in the process. As a result, he will be able to handle any future rendering problems with ease. +He looked into the logic behind that part of the product and realized it was based on an assumption about user behavior. He reviewed the original implementation and then asked several players for feedback. None of them actually wanted that feature. He ran a community poll to confirm it. -The developer who understands why it works will -- spend less time solving the same bugs -- create better solutions +In the end, he: +- Fixed the original bug +- Redesigned the flawed logic +- Saved the queries for future analysis -##### UX Design +He didn’t just fix a bug. He understood the system and user behavior. -Same as developer, 2 approaches. +#### Example-2 -1. Creates 5 types of buttons. PM selects `Design B` and asks for iterations. The designer gets curious why that was selected. Reads case studies. Ask the PM. Talks to users. Then does 1 iteration and it gets approved. Here the designer spent time understanding what needs to be done and why. In the future the designer will be less likely to receive feedback. +**Your significant other is frowning all day** -2. Creates 5 types of buttons. PM selects one of them and asks for iterations. Designer changes it, after 3 iterations, it gets approved. Short term problem solved. But next time something similar happens designer will still need iterations. +Approach 1: Assume they’re upset with you. Defend yourself or withdraw. - +#### Example-3 - +Instead of just correcting the error, you ask: +- Was the requirement unclear? +- Was the deadline too tight? +- Was there missing documentation? +- Did we skip a review step? -#### Practice +You discover that the real issue was unclear communication and no checklist before release. So you fix the bug — but you also create clearer documentation and add a simple review process. -1. Select one thing you're working on -2. Book 60 minutes in your calendar -3. Spend 15 minutes diving to understand a core thing -4. Spend another 15 minutes for the next related thing -5. Repeat 15 minutes 2 more times +## Practice +1. Select one thing you are working on. +2. Book 60 minutes in your calendar. +3. Spend 15 minutes understanding one core component. +4. Spend 15 minutes understanding a related component. +5. Repeat two more times. 6. Now you can solve the problem -Whatever you dive in 4x15 minutes you should become a semi-expert in 4 components of that thing. Compound this with 2 years and you'll be one of the top people in your company who understands how things work together. +Understand first. Fix after. +Whatever you dive into for 4 × 15 minutes, you should aim to become a semi-expert in four components of that area. Compound this over two years, and you’ll become one of the top people in your company who truly understands how things work together