In my early academic days, the rigor of engineering and science held all my interest, making language and grammar classes feel like a diversion, a waste of time better spent on technical subjects. I was focused on the 'how' and the 'what,' not the 'why.'
However, over time, my perspective began to shift, driven by a growing curiosity that started by asking "Why" more and more frequently. This curiosity eventually led me to Philosophy—the realization that it wasn't just ancient texts, but a crucial methodology for analyzing thought, asking deeper questions, and structuring knowledge. I realized that true learning starts with context. As I learned, words and terms are meaningless until they are placed within a proper framework.
This new way of thinking gave me a deeper appreciation for people like my teacher, Dr. Rifat Colkesen, and others who championed writing and context. I now understand that they were trying to pass along the real method for learning, often constrained by the rigid structure of a curriculum. My journey through remote Computer Science studies, spanning five or six years, forced me to self-digest and analyze information. When you begin to ask "Why," something clicks; the framework of your mind changes, and you develop a craving to keep asking and finding answers.
This perspective deeply informs how I interpret the field of Information Technologies, starting with the very word we use for problem-solving: Troubleshooting.
Breaking the word down into Trouble and Shooting suggests a clear objective: there is an issue, and we are attempting to remove or eliminate it. In the programming world, we call this Debugging (removing the "bugs").
In essence, troubleshooting is a three-part process:
Analyzing the situation.
Identifying the core issue(s).
Proposing the solution(s).
In IT, the "trouble" is often a moving target we must eliminate through precise analysis.
The most powerful realization is that analyzing the situation is fundamentally a search problem—a structured search for a specific malfunction within a large, complex space of possibilities (the entire system architecture).
If we consider all possible points of failure as a search space, the goal is to find the single faulty component as efficiently as possible. This requires an efficient search algorithm.
One of the most effective techniques that fits the troubleshooting process perfectly is the Divide and Conquer paradigm, specifically executed through the logic of a Binary Search:
Divide: Split the problem domain (the system or process) in half.
Conquer/Test: Test the exact midpoint or boundary between the two halves.
Eliminate: Based on the result of the single test (Pass or Fail), you can immediately eliminate 50% of the entire search space.
For example, when diagnosing a failed web request (Client to Database), you don't test every piece sequentially. You jump to the middle (e.g., the API server):
Test: Does the request fail before reaching the API? (If yes, eliminate the API and Database as the source.)
Test: Does the request fail after the API tries to talk to the database? (If yes, eliminate the Client and API as the source.)
This process guarantees that you isolate the root cause with the minimum number of checks, moving efficiently from the initial state of "I have trouble" to the final state of "I have pinpointed the target to shoot."