Innovation Tokens

McKinley introduces the concept of innovation tokens — you get about three. Each new or unfamiliar technology you adopt costs one token. Use them wisely. PostgreSQL might be less exciting than the latest distributed database, but it has decades of battle-testing, excellent documentation, and a massive community.

Boring Does Not Mean Bad

Boring technology is technology that works. It has known failure modes. It has Stack Overflow answers. It has monitoring tools. It has people who have operated it at scale and written about what went wrong.

The most reliable systems I have worked on were built with boring choices. The most painful ones were built with resume-driven development. Choose wisely, and save your innovation tokens for the problems only you can solve.

Aliases and Functions

Simple aliases for common git operations save thousands of keystrokes per week. But custom shell functions are where the real power lies. I have a function that creates a new branch, sets up the PR template, and opens my editor in one command.

Tmux and Session Management

Tmux changed how I work. Persistent sessions mean I never lose my context. Named windows keep projects organized. And the ability to pair-program by sharing a session is underrated.

FZF: The Universal Fuzzy Finder

If you install one tool from this list, make it fzf. Fuzzy finding through command history, file paths, git branches, and process lists transforms how you navigate your system. Combine it with ripgrep and fd for an incredibly fast search workflow.

The OWASP Top Ten

Injection, broken authentication, sensitive data exposure, XML external entities, broken access control — the OWASP Top Ten has been the standard checklist for web security for over two decades. If you have not read it recently, take an hour and review the latest version.

Practical Steps

Parameterize your queries. Hash your passwords with bcrypt or argon2. Validate input on the server, never trust the client. Set security headers. Keep dependencies updated. Use HTTPS everywhere. These are not advanced techniques — they are the baseline.

The best time to think about security is before you write the code. The second best time is right now.

Ship Early, Iterate Often

The first version was embarrassing. A single PHP file with inline CSS. But it solved a real problem, and that was enough. Over time, I rewrote it twice, added features users actually asked for, and removed features I thought were clever but nobody used.

Sustainability Over Growth

I never tried to scale. No venture capital, no growth hacking, no marketing budget. The project grows when someone finds it useful and tells a friend. That pace is sustainable. I can maintain it in a few hours a month, and it still brings value to its small community of users.

Not every project needs to be a startup. Sometimes a small, useful tool is exactly enough.

My Setup

I run a small cluster of three machines: a mini PC as the main server, a Raspberry Pi for DNS and monitoring, and a NAS for storage. Total cost was under 300 dollars, most of it secondhand.

What I Run

Docker makes it easy to spin up services. I run Gitea for personal repos, Grafana and Prometheus for monitoring practice, a Postgres instance for database experiments, and Nginx as a reverse proxy tying it all together.

The best part of a home lab is permission to fail. No SLAs, no customers, no pagers. Just curiosity and a terminal.

What Makes a Good Commit Message

A good commit message answers three questions: What changed? Why did it change? What effect does the change have? The subject line should be imperative and under 72 characters. The body should provide context that the diff alone cannot convey.

Common Anti-Patterns

“Fixed stuff.” “WIP.” “asdfasdf.” We have all written these. But every vague commit is a future debugging session made harder. Take thirty seconds to write a real message. Your future self — and your teammates — will thank you.

Conventions like Conventional Commits can help, but the real goal is communication, not format compliance.

Let us walk through what actually happens when you visit a website, from your local resolver cache all the way up to the authoritative nameservers.

The Lookup Chain

Your browser checks its cache first. Then the operating system cache. Then your configured DNS resolver — often your ISP or a public resolver like 1.1.1.1 or 8.8.8.8. If none of them have the answer, the resolver walks the DNS hierarchy: root servers, TLD servers, and finally the authoritative server for the domain.

Understanding this chain helps you debug propagation delays, TTL issues, and the occasional mystery of “it works on my machine but not in production.”

Production debugging is a skill that is rarely taught but frequently needed. In this guide, I share the mental models and practical techniques I have developed over years of on-call rotations.

Step One: Do Not Panic

The first instinct is to start changing things. Resist it. Before you touch anything, gather data. Check your logs, look at your metrics, and form a hypothesis. The worst production incidents are the ones made worse by hasty fixes.

Isolate and Reproduce

Can you reproduce the issue? If yes, you are halfway to a fix. If no, you need more observability. Add structured logging, trace requests end-to-end, and build dashboards before you need them — not during an incident.

The modern web ecosystem encourages complexity. Every problem has a package, every pattern has a framework. But at some point, the overhead of managing all those moving parts starts to outweigh the benefits.

What Changed

I replaced my React SPA with server-rendered HTML and a sprinkle of vanilla JS. I dropped my ORM in favor of raw SQL. I traded Kubernetes for a single VPS with a deploy script. The apps still work. They are faster. And I actually understand every line of my infrastructure.

This is not advice for everyone. Large teams need different tools than solo developers. But if you have been feeling the weight of your stack, it might be worth questioning what is truly necessary.