For the purpose of this article, let’s adopt the following working definition for “Problem Solving” by Alan H. Schoenfeld: “You are engaged in Problem Solving when you are trying to achieve something, and you do not know a straightforward way to do so.” For example, calculating 9481759*201471 may not qualify as Problem Solving (for someone who learned how to do it, and I assume you did). It's not easy, it's time consuming and error-prone, but at the end of the day, it's not Problem Solving. When you encounter a math problem without a clear solution or face a blank page while attempting to write an essay, you are engaging in problem-solving. It's about figuring out the best approach, whether it's tackling numbers or crafting words. Many Development tasks involve Problem Solving: you need to think about how to implement a specific function, or browse through code to try and find a hint as to why something works the way it does. Many D(evelopment) tasks involve Problem Solving - you need to think about how to implement a function, or browse through the code for a hint to how something is working. Yet, if you are thinking about the implementation of something you know can be implemented, I will not consider it as R(esearch). It is a R(esearch) task, when you simply do not know how to proceed - what to look for, and whether the path you are pursuing can even produce a relevant solution. Throughout these posts, I will relate to such tasks, and the “R” in R&D in general, as "Research" (with a capital R).