Why We Write Code (It's Not for the Computer)

When I first started coding, I believed my job was done once the program ran without errors.

I was wrong.

We don't write code for the machine. We write it for the person who will maintain it — the colleague who will debug it at 2 AM, the junior developer who will learn from it, or even our future selves months or years down the line.

I learned this the hard way. I rushed to get features out the door, and later, debugging that code felt like deciphering a puzzle without clues. That's when it hit me — code isn't just for computers; it's a letter written to other humans.

So let's talk about why we actually write code — and why it matters more than you think.

Code is communication — not just to machines, but to the humans who will read it. Image via Unsplash

Code Is Communication — Full Stop

Code, and programming languages more generally, are about communication — from humans to machines, and to other humans.

When you write computer software, you're effectively explaining a process to a computer in perfect detail. But that's only half the story.

Most software is intended to be used by someone other than the programmer, and generally will be written or maintained in part by more than one person. This implies that, as well as explaining a purpose to the computer, the code also has to explain a purpose to other programmers.

This is one of the reasons good programming is as much art as science. Any coder can eventually write a program that produces the desired output. But a professional software engineer does more: He writes a program that is easily understood by others, reusable and easily modified.

The Human Factor: Why People Matter More Than Code

Here's a truth that took me years to fully appreciate: software is about people, not code.

When I was starting out, I thought software development was all about code. I wrote style guides, researched new technologies, argued about code formatting, and joined design pattern groups — all to be better at writing code.

But eventually, I realized that people were far more important for the success of a software project than code.

• Software and code is created for people and their purposes. It doesn't exist on its own, isolated from human needs.
• People will use the tools or applications built with code. (Or, worse, they won't.) This means they have to be bought into what is being built.
• Most people don't know or care about the code. They're just trying to get something done. The most beautiful, well-tested codebase that does the wrong thing is useless.

Code Is Thinking Made Tangible

Here's something I've come to believe: your code is your understanding of the problem you're exploring.

I can think all the Big Thoughts I like, but until I have a working program, I'm never quite certain that these thoughts make sense. Writing a program forces me to specify and clarify; it rejects fuzziness and incoherence.

As my program grows and evolves, it reflects the growth and evolution of my idea. As Paul Graham famously said: "the program is the growth and evolution of my idea".

This is why teaching everyone a little programming would be good. It's not about making everyone a professional developer. It's about giving people a way to make their thinking precise.

Why Style Matters (Even When It's Just You)

80% of a programmer's work is modifying existing code. And programmers come and go frequently.

The benefits of code that works are immediate: a running system and a nice paycheck. But the payoffs of readable code accrue in the future when your code will be maintained and extended.

The key observation? Good style should be a matter of habit. If you think about style as you write code originally, and if you take the time to revise and improve it, you will develop good habits. Once they become automatic, even the code you produce under pressure will be better.

Why bother? Because well-written code is easier to read and to understand, almost surely has fewer errors, and is likely to be smaller than code that has been carelessly tossed together.

The Unix Philosophy in Practice

There's a reason the Unix philosophy has endured for decades. It's not about being old-school. It's about writing code that humans can understand.

• Rule of Clarity: Write programs as if the most important communication is to the developer who will read and maintain the program — rather than the computer.
• Rule of Representation: Choose to make data more complicated rather than the procedural logic, because it's easier for humans to understand complex data than complex logic.
• Rule of Simplicity: Design for simplicity by breaking up program systems into small, straightforward cooperating pieces.

What Customers Actually Want

Occasionally, I think we developers just write software for the pleasure of putting a few cool technologies through their paces.

But most of the time, we write software to address specific requests from customers or to provide a service for others to consume.

Software exists and thrives because of its inherent capability of reproducing the reality of some business experience while speeding up existing processes and enabling new and more effective processes.

The Real Reason We Write Code

So why do we really write code?

We write code to think. To make our ideas precise enough to execute.

We write code to communicate. To explain processes to machines and to other humans.

We write code to serve people. To solve real problems for real humans.

We write code to leave a legacy. For the colleague who'll debug it at 2 AM, for the junior developer who'll learn from it, for our future selves.

And finally — we write code because it's one of the most creative, rewarding activities you can do.

The Bottom Line

Code is communication. It's a letter to the future. It's an explanation of a process. It's thinking made tangible.

Now go write something worth reading. 🚀