Notes from building software

I didn’t start out with strong opinions about software. Most of what I know today came slowly, through building things, breaking them, fixing them, and repeating the process long enough to notice what tends to work and what doesn’t.

These are not rules. They’re small observations shaped by real projects, deadlines, trade-offs, and the quiet lessons that only show up after something ships.

Simplicity is usually a decision, not a limitation

Complex systems don’t usually start out complex. They become that way when short-term convenience wins repeatedly over clarity. The systems that hold up over time are often the ones that were intentionally kept boring.

// Before: implicit behavior
toggleModal();

// After: explicit intent
setIsModalOpen(true);

If a piece of code feels easy to understand, it’s usually because someone chose readability over cleverness.

Good user experience begins before the interface

Many UX problems aren’t visual problems. They’re the result of unclear flows, hidden assumptions, or logic that doesn’t match how people think. A clean interface can’t compensate for a confusing system underneath.

// Guard early, reduce mental load
if (!user) {
  redirect("/login");
  return;
}

// Everything below assumes a valid user
loadDashboard(user);

When the underlying decisions are simple and honest, the interface usually follows.

Code is a long conversation

Code is read far more often than it’s written. I try to write it as if I’m leaving notes for the next person who will work on it — including myself months later.

function calculateTotal(items) {
  return items.reduce(
    (total, item) => total + item.price,
    0
  );
}

Clear naming and structure reduce the need for explanations. If code needs too many comments to be understood, it’s often a sign that it can be simplified.

Shipping creates clarity

Waiting for a perfect solution usually delays learning. Shipping something small and usable reveals problems faster than weeks of planning ever could.

// Start simple, evolve with usage
export function save(data) {
  return api.post("/save", data);
}

Most good systems aren’t designed in one pass. They evolve as they’re used, questioned, and refined.

Writing is part of building

I don’t write regularly, but when I do, it’s usually because something feels unclear in my head. Writing forces me to slow down and confront assumptions that don’t hold up when explained.

If an idea is worth keeping, it’s worth articulating — even if only as a note to revisit later.

These notes will change over time, and that’s expected. Software evolves. So do the people who build it.