Update understanding.md

_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
 
 <img src="https://pbs.twimg.com/media/DMes69xXkAA4-7z.jpg"
@@ -23,71 +25,67 @@ When there is a problem we can take 2 approaches:
      alt="Markdown Monster icon"
      style="width: 20%" />
 
-#### 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.
 
-<!-- ##### Management
+Approach 2: Try to understand.
 
-Lets say a team member messed up somewhere.
+You ask calmly:
+- “Is something bothering you?”
+- “Did something happen today?”
+- “Is there anything I can help with?”
 
-1. The manager gives feedbacks, asks it to be fixed and moved on.
-2. The manager asks questions to gain deeper understanding of the employee's situation.
+You learn they had a stressful day at work and were mentally exhausted — it had nothing to do with you. Instead of creating unnecessary conflict, you respond with support.
 
-> I think you’re smart and conscientious, however I noticed a drop in your performance and I want to understand why that is. 
-> 
-> 1. How are you feeling about your current workload and responsibilities?
-> 2. Are there any specific challenges or obstacles you're facing that are affecting your performance?
-> 3. Is there anything about the work environment that you find demotivating or hindering your productivity?
-> 4. Are you clear on the goals and expectations set for your role? If not, what areas need clarification? 
-> 5. Have there been any changes in your personal or professional life that could be impacting your work?
-> 6. Have you been receiving feedback or guidance on your performance? If so, what has been helpful, and what would you like to see more of?
-> 7. What resources or tools do you believe would assist you in improving your performance?
 
-Active listening and providing a safe space for open and honest communication are essential during these discussions. It's crucial to avoid placing blame and instead focus on finding solutions and offering support to help the employee succeed. By asking more question the manager can delve deeper into understanding how the employee works. What temperature are they working at? What devices do they use? What is their work environment like? What are their working hours? Are they getting enough sleep? Are they rushing things? Are they organized? Do they take notes? These inquiries help the manager gain a better understanding of the employee's work habits and preferences, ultimately leading to a clearer understanding of the individual's work style. -->
+#### Example-3
 
-<!-- ##### Relationship
+**A team member shipped something that caused an issue.**
 
-Your significant other (SO) has been frowning for the past week.
+Approach 1: Fix the mistake quickly and move on.
 
-1. You decide to take them out to dinner, and they become happy. Problem solved, so you go home and sleep.
-2. You ask your SO why they are frowning? What feelings are they experiencing? Would they like to talk about it or have some space? Is it related to you or something they experienced at work, with another friend, etc.? How can you support them? 
-By asking these questions, you can understand the reason behind the frowning of your SO, their needs, and how you can help them. 
+Approach 2: Understand why it happened.
 
-Your goal is to understand how things work.  -->
+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