Writing
Writing for senior engineers, engineering leaders, and anyone who cares about internal systems, production software, and the technical decisions behind them.
The right engineering decision is not always the cleanest one. Sometimes the safer move is to contain the mess instead of triggering a risky rewrite.
Flexible APIs look powerful, but in real systems constraints often create better usability, consistency, and safer defaults.
Clean code can improve local readability, but it is mostly a matter of taste and familiarity, not an objective measure of engineering quality.
Even simple AI workflows create architectural pressure that traditional CRUD systems were never designed to handle.
Architecture is often just a frozen prediction about the product, which is why small product decisions quietly become long-term technical constraints.
The most valuable way to use AI is not to skip thinking, but to expand it and pressure-test your reasoning before you commit to a solution.
AI can one-shot a convincing first pass, but the work that makes software valuable still lives in judgment, boundaries, and tradeoffs.
Slowing down, explaining your thinking, and focusing on process can make hard debugging work much easier.
Before turning a small ticket into a rewrite, ask whether the business actually needs the bigger fix right now.
A basketball analogy for software tradeoffs: sometimes the right engineering decision maximizes upside, and sometimes it maximizes the chance of success.
How to make a whole card clickable without nesting links or relying on JavaScript.
Libraries are useful, but they are not free. Sometimes the right move is to write the code yourself first.
Remix already gives forms a strong foundation, but complexity can still justify bringing in a library.
Two clean ways to make Remix breadcrumb handles work with i18n without fighting where translation context lives.
A practical way to wire third-party services into Remix by treating runtime boundaries, environment variables, and SDK placement as separate problems.
A practical guide to moving heavy work out of request handlers without overengineering it on day one.
When equations depend on each other, the real problem is dependency ordering. A graph plus topological sort makes that explicit.
End-to-end tests get flaky fast when a real database is involved. Reliable suites start with isolated state and predictable execution.
Breadth-first and depth-first search solve different problems. The useful part is knowing when the traversal order changes the answer.
