It is unfair to say that I am completely ignorant of this skill because if it was the case, I would have not been able to survive in this industry. But it is not bad to enhance a skill that you know haphazardly and that is why I am going to sum up some key points that I have learned from the articles in my Reference section.
In the first article, Emily Cain propose 4 steps to solving any software problem. I love the way she pointed out kinds of problems. The list is relevant and I noticed that sometimes I even avoided some problems or did not wholeheartedly go with the solution such as when dealing with legacy code of other programmers. When identifying and understanding the problem, I know that it is best to write down the questions and answers but procrastination can take over me and I might fail to do that. Furthermore some problems look challenging but actually quite simple. It is probably a good rule of thumb to spend 15 minutes only to think in my head what I am about to do. If I still stuck, some short keywords on a paper would be good clues. When it reaches about 30 minutes, maybe I want to write down thoughts and analysis. Her suggestion at Gathering information is quite spotted-on. Try reading the source code is something I rarely do since I find it difficult to understand when that code run. Perhaps I can do some rubberducking when reading the code. Looking at the commit history is an interesting idea that I have never thought of. I like the way she proded the reader into going beyond simply using a searched answer for the problem by reading relevant links but I would argue that it can be really time-consuming and sometimes we only want to quickly implement the solution.
Arc team have their own way of tackling a problem. In Problem-Solving Skills for Software Developers: Why & How to Improve, there are 6 steps for practice. They also attempted to answer why this skill is important, gave tips, analyzed kinds of problems and listed complementary skills. But somehow I feel this article is quite abstract and not to the point. It failed to point to more detailed source or suggested technique as well as gave examples in the software world. The Google autocomplete example at the beginning was good but other than laying out goals and tasks, the article failed to stick to this example till the end and failed to present how this autocomplete problem can be approached by the method above. However, I still find parallel thinking a great idea because I had witnessed our client’s CTO did this. He would architect the entire system and lay out plans for each modules. Then many squads would work on the own module until they reach a point of integration.