Capturing thoughts

I needed a resume site, but also figured it’d be a good place to host random thoughts for my audience.

Ever since the rise of LLMs that are capable of great utility when writing code, I’ve wanted to capture some of the finer points of code authorship—to preserve a little bit of the kinds of problems we used to solve regularly when everything was written by human hands. Hopefully someone finds them amusing.

Today’s Gem: Avoiding ternary expressions and unnecessary nesting

Early in my years authoring JavaScript and TypeScript, I often used ternaries in my code—they felt more concise. As the years passed, I changed my position, especially after reading Clean Code by Bob Martin. I wouldn’t take blind advice from any programming book, especially as times change, but one core idea in that book melded with my learning about functional-programming paradigms and languages.

That idea was to make statements short and declarative:

// Business logic sandwiched between 2 `null` literals
const someData =
  items != null
    ? items.map((item) => ({
        ...item,
        timestamp: new Date(),
      }))
    : null;

// Ensures the return type is always an Array, but with an extra ternary to think about...
return someData != null ? someData : [];

While avoiding if/else control flow for null handling can initially seem clever, functional programming taught me that eliminating ambiguity in a variable’s type as early as possible reduces cognitive overhead. If the code guarantees a value has a particular type up front, it eliminates certain possibilities immediately and “narrows” what any future reader has to mentally grapple with when reading the code again:

// someData begins its life as a `const` array, hinting that it will
// always be an array up front.
const someData = [];
items?.forEach((item) => {
  someData.push({ ...item, timestamp: new Date() });
});

// No ternary needed, and we know this is an array.
return someData;

Ternaries always introduce “what if” mental nesting, so expressing the same logic without them makes for flatter logic that is simply easier to follow.

Another variation on this theme: early returns!

function achieveEffect(input) {
  if (input) {
    // do something
    // do something
    // do something
    // perhaps 20 more lines of logic...
  } else {
    // Such a simple case here forces all code in this function
    // to be nested one level
    return null;
  }
}

At first, this felt like it best expressed what I thought I cared about: placing the happy path first so we could focus on it immediately. Eventually, though, the zen of an early return rang truer. That pesky else clause could be buried below tens of lines, and I’d need to scroll to the end of the function just to find a banal expression. Until I did, I’d have to bear the mental weight that the else case could be just as complex as the if clause’s primary logic. The nesting we see on the first line of the function body “hints at” complexity where none really exists. You could say it introduces a form of “complexity paranoia” when reading the code again six months down the road.

I realized that returning early for things like null handling led to functions that were more ergonomic to read in the future:

function achieveEffect(input) {
  // Get the simplest base case out of the way immediately. This frees up
  // cognitive focus to understand the rest of the function as the "meat" of its purpose.
  if (!input) return null;

  // The main logic exists without an extra level of nesting
  // do something
  // do something
  // do something
  // perhaps 20 more lines of logic...
}

In fact, idiomatic Go embodies this same theme, too! Early returns help us express exceptional cases that, piece by piece, eliminate possibilities until only the happy path remains at the bottom of the function—sitting there almost “on stage” for all of us to see.

If your entire codebase adheres to this approach, you can rely on complexity being expressed as layers to be “peeled away” rather than “traced through” a cat’s cradle of nesting and ternaries!

import (
	"errors"
)

type User struct {
	ID         string
	Age        int
	IsVerified bool
}

func ProcessUser(id string, age int) (*User, error) {
	// 1. Guard clause: Validate inputs immediately
	if id == "" {
		return nil, errors.New("invalid user ID")
	}
	if age < 18 {
		return nil, errors.New("user must be an adult")
	}

	// 2. Action: Execute operation and handle the error instantly
	user, err := getUser(id)
	if err != nil {
		return nil, err // Return early on failure
	}

	// 3. Happy Path: The core logic sits cleanly at the bottom
	user.IsVerified = true
	return user, nil
}