The origin(s) of Solutions 9330
Does it ever happen to you to be hit by a very deep question while enjoying you morning coffee? Each time it happens, I am here sharing that specific thought that probably emerged following the effect of caffeine. How do we think about solutions? Before thinking about this question, I feel that it’s a must to present its context in order to understand more my perspective.
The day before, I wanted to stretch my brains neurons by trying to solve a puzzle, in other words a problem, a necessary element for the existence of solutions. The puzzle, or the problem I wanted to solve was a coding problem by LeetCode, in which I need to develop a code to recognize Palindrome numbers. Palindrome numbers possess the very unique property of being symmetric, meaning that you can read them from both sides. One famous example is 121, you can think of 1111, 2222, and the list goes on. The goal is not to dive in this amazing world land of Palindromes, perhaps we can do it later, but to illustrate an important point. I thought of two solutions, each one is relative to a different approach. I noticed that this applied to other problems too. I generally think of two types of solutions:
1) A domain knowledge based solution
2) A technical based solution
The first category are solutions that come as a result of a domain expertise. Let’s take the example of the Palindrome numbers problem. One first reflex I had is to assess all mathematical properties that these numbers might have before putting my hands on the keyboard to translate those thoughts into code. The domain here is Mathematics, it could be any domain. One origin of solutions is the expertise ones gather through domain knowledge. This is what Data models try to imitate by capturing the hidden patterns given a set of features that are chosen, based on statistical measures yet they make sense from a domain knowledge point of view.
The second category is relative to each domain. One easy way to recognize a Palindrome number is to convert it to a string, reverse it and then compare it with the original string. This is a technical solution brought up by the world of coding. Similar solutions exist in many domains, and if they are coupled with domain knowledge they can solve numerous problems. This type of solutions require the discipline’s domain knowledge which can be different from the problem’s domain knowledge, especially for a category of disciplines that are suppliers of tools (Coding, Statistics…).
These two categories tell us about the origins of solutions. In every problem, there are two layers that we need to be aware of, the domain and the tool, both can offer a solution. A lot may argue that it’s not true in all cases, but we will assume it is possible to develop a solution following both methods, as numerous discoveries shape everyday reality and change the meaning of what is impossible. Quantum physics stun the world at their emergence, Information theory, and many other so called impossible things at a certain time. From a tool perspective, it is possible to merge tools that seems different yet they share a common point, no wonder why we see some domains interfering in many other domains like Data Science. Once we define clearly the roles of each layer it is possible to craft an ingenious solution to all problems, or we might end up realizing that we need to outsource an additional layer to help craft a more sophisticated solution that finds a way around the previous limitations.
When I talk about origins, I place myself from a procedural perspective. This is one way to see it and not the only one.
“ Genius Takes Time and Extraordinary Effort “
