Defining Computer Science Through Algorithmic Processes Not Tools

Computer science faces a crisis of definition. Many people mistakenly believe the field is defined by the tools it uses rather than the problems it solves. By tethering the identity of computer science to physical machines, we obscure the true nature of the field: the rigorous study of processes, algorithms, and the fundamental constraints of problem solving. This confusion creates a blind spot where practitioners prioritize the what, such as hardware or code, over the how, which is the logic of the process. For leaders and technologists, recognizing this distinction provides a competitive advantage. It allows you to apply algorithmic thinking to systemic, human, and organizational problems that have nothing to do with silicon, letting you solve for the underlying process rather than just the visible output.

The hidden cost of the computer label

The idea that computer science is about computers, often summarized by the quote attributed to Edsger Dijkstra, "Computer science is as much about computers as astronomy is about telescopes," is more than a clever provocation. It is a diagnostic tool for a systemic failure in how we view the field.

When we label the field by its tool, we limit our scope to computational tasks. This creates a downstream effect where we ignore the fundamental theoretical work that predates physical hardware. As Ben Brubaker notes, the field emerged from a collision between mathematical logic and engineering. By focusing on the engineering, or the machine, we lose sight of the logic, or the process.

"Computer science is as much about computers as astronomy is about telescopes."

-- Edsger Dijkstra (attributed)

The hidden danger here is the telescope trap. If you define the field by the machine, you assume that solving the problem requires the machine. In reality, the most critical breakthroughs in theoretical computer science occur on whiteboards, independent of hardware. When we force these insights into a hardware first framework, we create unnecessary complexity, treating human centric problems as if they require a digital architecture to be understood.

Why the how outperforms the why

In most sciences, the core objective is to ask why to uncover the fundamental laws of nature. Computer science is distinct because it is primarily concerned with how. This focus on the process itself, the transformation of input to output, is where the field derives its power.

Conventional wisdom suggests that if you have a problem, you build a system to solve it. But systems thinking reveals that the process of solving is often more important than the tool used to execute it. Brubaker highlights that researchers are now applying algorithmic analysis to ecology, evolution, and even human interaction. They are not using computers to simulate these fields; they are using the mathematical properties of algorithms to understand the processes governing those fields.

"The other sciences ask why, while computer science asks how."

-- Ryan Williams (via Ben Brubaker)

The competitive advantage here lies in abstraction. When you stop viewing your work as writing code and start viewing it as optimizing a process, you become immune to platform shifts. Whether you are using a quantum computer, an AI model, or a pen and paper, the underlying algorithmic efficiency remains the primary constraint.

The inflection point: when practice outruns theory

We are currently in a period where practice, specifically in AI, is sprinting far ahead of theory. This creates a dangerous feedback loop. We build systems that work in practice but lack a theoretical foundation, leading to black box outcomes where we do not understand the process generating the result.

The system responds to this by forcing us into an experimental mode. We poke at AI models because we lack the theoretical framework to predict their behavior. This is a fragile state. The long term payoff belongs to those who return to the fundamental theory. As Brubaker points out, the impossible problems of full scale generality are often solved in specific, real world instances. Understanding why those instances work, the fundamental process, is the only way to build durable, scalable solutions that do not collapse when the environment shifts.

Key action items

• Audit your tool first bias: Over the next quarter, identify three projects where your team is optimizing for the technology, such as "we need to use AI for this," rather than the process, such as "what is the most efficient algorithm to solve this logic chain?" Shift the focus to the process.
• Decouple the problem from the platform: Practice defining your most complex organizational or technical challenges without mentioning the technology used to solve them. This reveals the true algorithmic structure of the problem.
• Invest in theoretical literacy: Dedicate time over the next 12 to 18 months to study foundational algorithmic concepts, such as complexity theory or information theory, that are platform agnostic. This pays off when current tech stacks become obsolete.
• Adopt process first communication: In meetings, stop asking "what tool should we use?" and start asking "what is the process we are trying to optimize?" This forces the group to define the input output relationship clearly.
• Seek out human algorithmic frameworks: Read Algorithms to Live By to understand how computer science principles apply to everyday decision making. This creates a mental model for applying logic to non technical, high stakes human problems.
• Monitor the theory practice gap: If your team is relying on poking at a system to see what works, or experimentalism, rather than understanding the underlying logic, flag this as technical debt. Plan to replace experimental hacks with rigorous process definitions within the next two quarters.