The 5 Whys is a problem-solving technique developed by Sakichi Toyoda, which involves asking “why?” five times to get to the root cause of a problem. The goal of the technique is to identify the underlying causes of a problem, rather than just addressing the symptoms. By asking “why?” five times, teams can better understand the root cause of a problem and develop effective solutions to address it. The technique is simple but powerful, and can be used in a variety of contexts, from manufacturing to software development to personal problem-solving.
Improper allocation of time is the most common mistake that programmers make when tackling algorithmic programming problems, according to John Sonmez’s article titled “How to Solve Programming Problems.” In his article, Sonmez emphasizes that before diving into coding, programmers should spend a significant amount of time understanding the problem thoroughly. He suggests a step-by-step approach to solving algorithmic programming problems, which includes reading the problem twice, solving it manually with sample data, optimizing the manual steps, writing comments or pseudo-code, replacing them with real code, and finally, optimizing the code. Sonmez recommends spending 70% of the time on the first three steps and stresses that understanding the problem is the most critical step. Additionally, he advises solving the problem manually first to simplify the actual code and suggests using loops to reduce manual steps in algorithms.
As someone who has worked in the food service and customer service industry for the past 17 years, I bring a unique combination of both soft and hard skills to this career. Through my experience, I have honed my soft skills in areas such as customer engagement, nuanced interpersonal problem solving, empathetic leadership and management, attention to detail, and organizing systems. These skills have allowed me to adapt and adjust on the fly, which I believe are invaluable and crucial to success in the tech world. Overall, my diverse skill set and adaptability make me a valuable asset to any team in this field.
To overcome being stuck on a tough piece of code, logic, or feature, I have developed a three-step approach. First, I step away from the problem and take a short break to clear my mind. Then, I seek help and collaborate with a colleague to brainstorm new ideas and perspectives. Finally, I tackle a smaller, more manageable challenge to rebuild my confidence before returning to the original problem with renewed energy.