The First Law of Computer Programming

There’s a law that every programmer learns eventually, usually the hard way. At its most fundamental, a computer is nothing more than a very obedient machine. It always does exactly what it was told to do. That observation leads directly to the First Law of Computer Programming:

A computer is only as smart as its programmer.

And the First Corollary, which anyone who has spent time in the industry will recognize immediately:

There are a lot of stupid computers.

The basic intelligence of any software system is a direct reflection of the skill, knowledge, and judgment of the person who built it. It always has been. What's changed is the scale of the problem.

The Language Everyone Loves to Hate

The image accompanying this piece is a snippet of COBOL code. COBOL is the easy target, the language that has been complained about since the 1960s, the punchline in every conversation about legacy systems. But here's what's worth knowing: COBOL code written by disciplined programmers fifty years ago still processes trillions of dollars in financial transactions every single day. It runs payroll systems, banking infrastructure, and government benefit programs at a scale and reliability that most modern software never achieves. The problem was never COBOL. It was never the language. It was always the programmer.

That's the First Law in practice. A disciplined programmer working in an unfashionable language produces software that outlasts generations of replacements. An undisciplined programmer working in the most modern framework produces software that must be rewritten before reaching production.

What Seventeen Years of Progress Looks Like

I first wrote the initial version of this piece 17 years ago. Even before that time, there were already books and websites dedicated to cataloging bad software and unusable interfaces. Those titles still exist today, and with good cause. The problem hasn't been solved. It's gotten worse.

The challenge today is no longer finding bad software. It's finding good software. Despite better tools, better development environments, better educational resources, and more investment in the craft than at any point in history, the ratio of good software to bad has not improved. If anything, it has declined. Features multiply. Interfaces become harder to navigate. Enterprise software requires days of training to perform tasks that should take minutes. Consumer applications add capabilities until nobody can find the ones they actually need.

This is not a tooling problem. Better tools don't produce better software when the person using them lacks the foundational knowledge to make sound decisions.

The Education Gap

Several years ago, I was coaching a team of programmers at a client site. One developer had been there about six months and was struggling with a troublesome piece of conditional logic. I suggested he build a truth table to list out all the permutations and expected results.

"What's that?" he asked.

This was an intelligent, articulate person with an IT degree from a respected local university. He disclosed that during his entire time at college, he had been required to write a total of three programs. Just three. None of them were in programming languages with wide commercial use.

His education had covered syntax, basic logic structures, computer history, UML, and similar foundations. Students in that program could produce a polished flowchart and a solid entity relationship diagram. What they couldn't do was decompose a problem into logical steps or design an interface that a real person could actually use.

Around that same time, I was interviewing a candidate for a developer position. His resume listed "familiar with the use of meaningful indentation" as one of his skills. When I asked him what that meant to him, he replied: "I know how to hit the TAB key."

Next.

These aren't stories about bad people. They're stories about a systemic failure to teach the thinking that underlies the craft. Syntax can be looked up. Logical decomposition, domain understanding, and genuine empathy for the person using the software cannot be automated or skipped.

AI Makes the Fast Lane Faster

Seventeen years ago, the tools that let underprepared developers write bad code quickly were merely inconvenient. Today, they're everywhere and extraordinarily capable.

AI coding tools like GitHub Copilot, Cursor, and Windsurf can generate syntactically correct, plausible-looking code at a speed no human developer can match. For a skilled practitioner with deep domain knowledge, these tools are genuinely transformative. They handle the mechanical work, freeing the developer to focus on the decisions that actually matter.

For an underprepared developer, they are a faster path to the same destination. The First Law doesn't have an exception for AI assistance. A computer is still only as smart as the person directing it, and the person directing it is now directing it through a natural language interface rather than a keyboard. The underlying judgment required is identical. The speed of the output has increased dramatically. The quality of the thinking behind it has not.

The usability decline of recent years isn't caused by the tools. But it's partly because of them.

What to Do About It

The answer isn't complicated, though it requires genuine commitment. For anyone writing software, at any level of experience, three practices make a measurable difference.

Watch people use your programs. Not in a controlled demo environment, and not over someone's shoulder while they perform for you. Watch real people use your software on their own terms, for their own purposes. What you learn about your own assumptions will permanently change how you write code.

Spend time on the help desk supporting the code that you wrote. Nothing clarifies the gap between what you intended and what you built like listening to the people who actually have to use it. Developers who have never done this carry blind spots that never fully close.

Sharpen your skills continuously. You will never know everything, and there will always be someone who knows more than you. That's not a threat. It's an invitation. Be humble enough to learn from them. Read. Practice. Build things that have no immediate commercial purpose just to understand how they work.

And a fourth, which is the most urgent recommendation for the current moment: develop and protect your domain knowledge. AI tools are remarkable at generating code. They cannot substitute for understanding the problem you're trying to solve, the people you're solving it for, or the constraints that make one solution better than another. A developer who hands a poorly understood problem to an AI model and ships the output hasn't saved time. They've automated the failure.

The First Law was true when the first programmer wrote the first line of code. It's true today. The corollary keeps writing itself.