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 there is a problem we can take 2 approaches:
Focus on understanding
Focus on fixing
Here is an example of how my co-worker implemented this model.
"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."
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.
Another time they said something like this:
"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."
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.
The developer who understands why it works will
Same as developer, 2 approaches.
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.
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.
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.