Beginning a thing.

The following are November reflections as I build a thing. Dev log °1.

The following are November reflections as I build a thing.

Your domain is about to expire

A month ago I received an email from Vercel telling me that my domain was about to expire. Getting a domain expiration email always feels embarrassing. It's an unexpected reminder of what could've been. You recall a year ago when you ran `npx create-react-app world-changing-idea` only to forget about it 3 days later.

The crossroads: let the domain disappear into the ether like it never happened, or renew? Let's renew.

The proof is in the weekend

One of my favorite essays is "How to Build Anything Extremely Quickly". The gist is simple: outline the tasks and speed run them. A complicated task? Break it up into smaller tasks. Speed run those.

I used this method to build a weekend prototype of the core functionality of the thing. No SAAS landing page, no login, or database. Just a simple frontend with one component that hits a single Hono endpoint. It just works. This proved to me that thing could in fact be a functional product.

Don't obsess about your knives

There's a tendency in software engineering to obsess about our tools. Our stacks. Our frameworks. Our Neovim or Obsidian configs. I think tooling matters, but time spent perfecting your tooling is time wasted. I'm saying this having spent hours on YouTube trying to nail the "perfect" Neovim setup or Obsidian setup .

When tools have infinite customizability, our brain tricks us into thinking: surely if I configure this tool "the perfect way" I'll have superpowers. Our pursuit of perfect tooling will only lead to a dead-end. I doubt chefs spend this much time obsessing about their knives when they have a dish to make.

The zen of avoiding the cool thing

After completing my weekend proof of concept, I wanted to start building the actual product. I thought about using NextJS for this application but I think I have Javascript fatigue. I know building a thing using Next is probably what the cool kids would do but in the words of one of my favorite artists:

You can't be too cool, because then you'll just freeze to death.

- Tyler the Creator.

I'm choosing not to do the cool thing. I'm building the application using Laravel (which is like Ruby on Rails) but for PHP. It gives me authentication, queues, workers, and sockets all out of the box.

In the JS ecosystem simple (yet core) parts of the application end up requiring entire companies. Like Clerk for authentication, Pusher for real time sockets, and Trigger for queues and workers.

Maybe I'm jaded on the JS ecosystem but I know that each `npm install package` will inevitably come with issues. Either if it's needing to eject from the predefined happy path of these third party services, or their lack of documentation, or their cost, or their downtime.

Find your dependencies and eliminate them.

- Excel team moto by Joel Spolsky.

Nginx on a Saturday morning

Taking daily notes on development can paint a picture of overcoming difficult things. You inevitably come across a technical problem that feels like work.

For me, a couple Saturday mornings ago, I was trying to get an Nginx config wired the right way to work with SSL and CloudFare tunnels. What the words in the previous sentence mean doesn't really matter but what matters is that it was tough. But you put the work in, try different methods, and come out to the other side with some new scar tissue. The breakage of tissue is how muscle grows I'm told.

Earning the right to work on things

There's always a little rabbit telling Alice to go down a different hole. I'm Alice. The never-ending technical SAAS products is my rabbit hole.

One Tuesday evening I spent an hour looking at the perfect no-code Business Intelligence tool. Something that could give me insight into a product's user behavior. I have zero users. I barely have a product. Why was I wasting my time? I need to earn the right to work on certain things.

It's all distraction. Avoid it.