digitaljournal

  No, AI Is Not Going to Replace Software Engineers A senior engineer I know spent three days last month trying to get an AI coding assistant to fix a bug that turned out to be a missing semicolon in a config file the tool itself had generated. He fixed it in ten seconds once he actually looked at the code. That story tells you more about where we are with AI than any headline does. Every few months, the internet panics again. Software engineering is dead. Designers are finished. ChatGPT can do your entire job. Stop learning to code. It happens like clockwork, usually right after some company demos a flashy new model or a CEO says something dramatic in an earnings call. And every time, a wave of people in tech either spiral a little or roll their eyes and move on. Here's the thing nobody says loudly enough: these tools are genuinely good, and also genuinely limited, and both of those facts are true at the same time. What These Tools Actually Are Large language...

  Every Great Software System Starts with a Good Trade-off A senior engineer once told me the worst systems she'd ever seen weren't built by bad engineers. They were built by good engineers who refused to make trade-offs. Every decision had to be the best one, the most correct one, the one that would hold up in every conceivable scenario. Six months later, nothing shipped, and the "best" architecture was still a diagram nobody had built. That stuck with me because it goes against how we're taught to think about engineering early on. In school, in tutorials, in interviews, there's usually a "right answer." The optimal algorithm, the correct data structure, the proper design pattern. But real systems don't get built in that world. They get built by people choosing between options that are each good in one way and bad in another, and picking the one that fits the situation they're actually in. That's not a compromise on engi...

  The Myth of Building for Scale Too Early I once watched a friend spend three weeks setting up a Kubernetes cluster for an app that had exactly zero users. Not "small user base." Zero. He was proud of it too, showed me the architecture diagram like it was a tattoo he'd been planning for years. Meanwhile the actual product, the thing people were supposed to use, didn't exist yet. This happens more than anyone in tech wants to admit. At some point, building for scale became proof that you're a "serious engineer." Like if your architecture isn't complicated enough, people won't take it seriously. But from what I've seen, chasing millions-of-users infrastructure before you've convinced even ten people to use your thing is a special kind of self-sabotage. The annoying part is it looks like productivity the whole time. What Scaling Actually Means When people say "scaling," they're talking about handling more user...

  Why Most Side Projects Never Make It Past Version 1 (And How to Actually Finish Yours) The repo exists. The idea was good. Something still went wrong. It's 11 PM on a Tuesday and you just had an idea so good you can't sleep. Maybe it's an app that tracks your gym progress better than anything on the App Store. Maybe it's that tool that fixes the one annoying thing at your job nobody else seems bothered by. You open your laptop and start typing like your life depends on it. By 2 AM you've got a repo, a README with way too many emojis, and a folder structure that's honestly more organized than half the production code at your job. Three weeks later that repo is just sitting there. README still says "Coming Soon." Last commit message says "wip" and you can't even remember what you were in the middle of fixing. Looking back, you're not even sure when you stopped opening the folder. It just sort of happened. I don'...

  Failure Is a Better Architect Than Success The most reliable systems you have ever used were not designed that way. Someone got paged at 2am, spent three hours confused, and then added the metric that should have existed from the start. I used to think reliability was mostly a design problem. If you thought carefully enough upfront, modeled the failure cases, wrote good tests, the system would hold. That belief survived until the first time I watched a queue silently back up for six hours because a Lambda function was retrying on a 429 and nobody had a metric on retry count. The monitoring dashboard showed everything green. The system was on fire. That gap, between what your dashboard shows and what is actually happening, is exactly the problem observability exists to close. Monitoring and Observability Are Not the Same Thing Monitoring tells you something is wrong. Observability tells you why, including why in ways you did not think to instrument for. A monito...

Why Consistency Beats Motivation in Tech Most people don't fail because they lack motivation. They fail because motivation is the only system they ever built. The Problem with Motivation The thing about motivation is that it's mood-dependent. It showed up when you watched that conference talk at midnight and felt invincible. It didn't show up three weeks later on a Tuesday when you were tired and the bug wasn't making sense. And if your entire practice depends on it showing up, you're not building a skill. You're waiting for a feeling. What Consistency Actually Is Consistency is different because it doesn't require you to feel anything. It's a decision you make once, then stop making. The engineer who spends thirty minutes every weekday reading through PostgreSQL internals will, over a year, understand databases at a depth that someone who binge-watches database courses every other weekend simply won't reach. Not because they're...