5 Whys

One of my favorite things about working at my company is the numerous training sessions held throughout the week.

There are five key words that define how good a developer is:

1. Knowledge
2. Speed
3. Analytic
4. Communication
5. Quality
6. Attitude -> quite personally

As a fresher, knowledge seems to be an important keyword, but it only accounts for 25-30% of what makes a good developer. A far more critical skill is analytic ability. When encountering a problem, I always try to figure out a solution and fix it. This is a common mistake that most freshers, including myself, tend to make.

Analytic skills are the most important to improve a developer's level. When you analyze a problem properly, you can solve it more easily and ensure that it does not recur. One effective technique for this is the "5 Whys" method. The 5 Whys technique involves asking "why" repeatedly whenever a problem is encountered to move beyond the obvious symptoms and discover the root cause.

For instance, Taiichi Ohno provided this example regarding a machine that stopped working:

1. Why did the machine stop?
   There was an overload, and the fuse blew.
2. Why was there an overload?
   The bearing was not sufficiently lubricated.
3. Why was it not lubricated?
   The lubrication pump was not pumping sufficiently.
4. Why was it not pumping sufficiently?
   The shaft of the pump was worn and rattling.
5. Why was the shaft worn out?
   There was no strainer attached, and metal scraps got in.

Without repeatedly asking why, managers would simply replace the fuse or pump, and the failure would recur. The specific number five is not the point; rather, it is to keep asking until the root cause is reached and eliminated.

As a result, there is two principle in my company:

1. Empathy with any first mistake of anyone
2. Never accept second mistake with the same cause