Dev Tooling

Every codebase has it. The file, the service, the function that everyone knows about and nobody goes near. It works. Probably. And that is the most dangerous sentence in software engineering.

The technology industry tells itself a story about quality rising to the top. The actual history of software suggests something more complicated and less comfortable.

Every engineer has watched a system slow down over time despite nobody intending it. The causes are not mysterious. The prevention is not complicated. What is missing is the habit of treating performance as something that requires continuous attention rather than occasional rescue.

Every team adds rate limiting eventually. Most add it after the incident that made it obvious they needed it. The interesting question is not whether to rate limit but what you are actually protecting, which most implementations get wrong.

The curriculum teaches you to code. The job requires something else entirely. After years in this industry, here are the things that determine most of the variation in how careers go and that almost nobody says out loud.

After years of working with engineering teams, the most valuable person is almost never who you would expect. It is not the fastest coder. Not the one who knows the most. It is someone doing something much quieter and much harder.

Being right all the time is not what makes someone excellent at this work. Knowing what to do when you are wrong is. The engineers who progress the fastest have figured out something that takes most people years to understand.

Engineering teams propose rewrites with confidence and complete them with regret. The second system is almost never as much better as it was supposed to be, and the cost is almost always more than anyone planned. Here is why, and what to do instead.

Event-driven systems are elegant in talks and brutal in production. After building and operating them across multiple companies, here is what nobody tells you before you commit to the pattern.

At some point, many senior engineers quietly transition from building things to managing the building of things. This transition is often presented as growth. Sometimes it is. Often it is the beginning of a slow professional collapse.

We test the wrong things obsessively and the right things barely at all. The unit test orthodoxy has produced codebases with 90% coverage that break constantly in production. It's time to say this out loud.

The user in your head when you make product decisions is not your actual user. The gap between those two people is where most product failures live.

Most code can be refactored. APIs are different. The decisions you make when you first expose an interface become the constraints everything downstream is built on. Here's which ones actually matter.

The teams shipping reliable AI products in 2026 have something in common: their infrastructure is aggressively uninteresting.

A passing dashboard and a healthy system are not the same thing, and most teams only find out the hard way.

Flexibility is not free. Every abstraction you add to avoid being locked in has a price, and most teams are paying it without realising what they bought.

Most teams think they have observability because they have logs. They don't. Here's what observability actually means, why the distinction matters, and what it costs you when production breaks and you're flying blind.

Infrastructure as code promised to make infrastructure reproducible, auditable, and safe. Most Terraform codebases I've seen deliver none of those things. Here's what goes wrong and why.

Every week I talk to a team running three services and forty users on Kubernetes. They're solving tomorrow's scaling problem while today's reliability problems go unfixed. Here's what that costs.

A generation of developers learned to treat the database as a dumb storage layer and move all the logic into the application. That decision is quietly running up a tab that production systems eventually pay.

Vibe coding is a genuinely useful tool for getting ideas out of your head and into a browser. It is also producing a generation of production systems that nobody fully understands. That bill is coming due.

Green builds don't mean working software. Most pipelines are optimised to pass, not to catch failures. Here's what a pipeline that actually tells the truth looks like.

Every serious workflow I run on AI has moved to local models. Not because cloud models are bad — because ownership, latency, and privacy compound in ways that matter more than benchmark scores.

AI is compressing the entry-level job market faster than the industry wants to admit. What that actually means for people starting out, and the only honest advice I have.

Adding an AI button to your product is not an AI strategy. Here's the difference between bolting on a model and actually re-architecting around what AI makes possible.

A complete guide to controlling your Android device from your desktop using Scrcpy GUI — setup, mirroring, recording, wireless mode, keyboard shortcuts, and every option explained.