Code is a User Interface (And Yours Might Be Terrible)

We obsess over our users.

When we build a frontend, we agonize over the User Interface (UI). Is the button clear? Is the contrast high enough? If a user has to click three times to find the "Logout" button, we consider that a failure of design. We treat the customer like royalty.

But when we close the frontend and open the backend code, that hospitality vanishes. We treat the next person who enters that file like a trespasser.

Here is the secret that changes your career trajectory from "Coder" to "Engineer": Your code is also a User Interface.

But the user isn't the customer with the credit card. The user is the next developer.

The Empathy Gap

It might be your teammate. It might be the poor soul hiring you. But most often, the user of your code is Future You, six months from now, staring at a screen at 2 AM, wondering, "What on earth was I thinking?"

There is a massive disconnect I call The Empathy Gap.

A "Coder" writes software to convince the compiler to work. They think their job is done when the terminal flashes green.

But a "Professional" knows that the compiler is actually the easy audience. The compiler is a cold, unfeeling robot. It doesn't care if your variable is named x, data, or spaghetti_monster. It converts everything into the same binary zeroes and ones.

Humans, however, need context. Humans have a limited cognitive budget.

When you write code that works but is impossible to read, you are building a terrible User Interface. You are forcing your teammate to reverse-engineer your logic just to understand what input a function expects.

The Interface Test

Let’s look at a function signature. This is the "API" of your code. It is the door handle. If I have to kick the door down to see what’s inside, you have failed the test.

Which of these two signatures scares you?

// Before: The Mystery Box

This is the "Coder" approach. It compiles. It works. But it tells me nothing.

// I have to read the entire function body to know what 't' and 'm' are.
// Is 'u' an ID? An object? A string? 
// The only way to know is to waste my time reading your implementation.

function notify(u, t, m) { 
  // ... 50 lines of logic ...
}

If I see this in a codebase, I immediately lose trust in the author. I am now forced to hold the entire logic of the program in my head just to call a single function. You have stolen my focus.

// After: The Clear Interface

This is the "Professional" approach.

// The "UI" tells me exactly what is required.
// I don't need to read the code inside to use it.
// This respects the reader's time.

function sendNotification(user, templateType, messageBody) { 
  // ... 50 lines of logic ...
}

The Verdict

Look at the difference.

1. Action: notify is vague. sendNotification is an action.
2. Context: u is a keystroke saver. user is a domain concept.
3. Clarity: t could be "time", "token", or "title". templateType leaves no room for error.

Does the function name tell you exactly what is happening? If the answer is "no", the code isn't done.

It works, sure. But it isn't finished.

We are going to stop writing code just to get past the compiler. We are going to start writing code that communicates with human beings.

---

Stop writing code just to please the compiler.

This article was an excerpt from my handbook, "The Professional Junior: Writing Code that Matters."

It’s not a 400-page textbook. It’s a tactical field guide to unwritten engineering rules.

👉 Get the Full Handbook Here