Many times in my learning journey I’ll read or watch something, understand it at that point, but when the time comes to explain it to someone else, I have a difficult time relaying it back. I remember when I applied to Dev Bootcamp, they even asked during the interview process for you to pick any concept or action and explain the procedure to the interviewer. I did not see the value at the time, but now I get it.
Whenever I’m stuck with a specific problem or in general interested in learning about a principle from which I could gain an immediate benefit, I tend to do a decent amount of research. When I do find the solution to a problem that’s been bothering me for a while, I will often do the least amount of work to get past the problem, and then move on.
The Five Whys
“The 5 Whys is an iterative question-asking technique used to explore the cause-and-effect relationships underlying a particular problem. The primary goal of the technique is to determine the root cause of a defect or problem.”
I remember some days during the DBC, I would start the day by writing down two questions:
What must I achieve today for the day to be a success? If I encounter problems, how will I deal with them?
On the first question I would list the objectives of the day, usually 4-5 specific things. On the second one and after some thinking, I came up with an answer that is related to the five Whys technique.
Whenever faced with a problem that would cause major pain, I told myself that the solution would be to chase the problem all the way down to its root and really understand its source.
Example
Wikipedia lists an effective example problem:
The vehicle will not start.
- Why? - The battery is dead. (first why)
- Why? - The alternator is not functioning. (second why)
- Why? - The alternator belt has broken. (third why)
- Why? - The alternator belt was well beyond its useful service life and not replaced. (fourth why)
- Why? - The vehicle was not maintained according to the recommended service schedule. (fifth why, a root cause)
Often when I’m dealing with a programming related problem, the answer, or at least the most valuable answer, never lies at level 1.
This is something that I am thinking about a lot when I am doing test driven design. TDD forces me to analyze the problem even deeper, considering the players and how everything interacts. For instance, when I am deciding to use an interface with something, I now force myself to understand the value added from the interface and the root cause of needing it in the first place.
Doing the above allows me to understand why I am doing what I’m doing and instead of randomly trying things to make something work, I make conscious decisions based on a advantages vs disadvantages analysis. I’m not saying trying things out is bad, I do it a lot myself and have learned a lot as a result, but in order to learn something in a really deep level, the 5 Whys or a similar approach can be immensely beneficial.