blog.buil.uk

I remember getting my first work phone. A BlackBerry Pearl. It had a physical QWERTY keyboard, battery life for days, and what was, at the time, a genuinely revolutionary feature: push email . Messages appeared on the device the moment they were sent. No refreshing. No waiting. Just information, arriving uninvited. At the time, this felt like the future. I was connected to a living organisation in real time. A sort of corporate hive mind. Alright Neo, settle down. The lasting legacy of the BlackBerry is not the hardware, or even email itself. It is the normalisation of push notifications for work, regardless of where you are. The quiet acceptance that information should interrupt you the moment it exists. Control over when information is consumed shifted from the consumer to the publisher, and we mostly went along with it without asking too many questions. A Blessing and a Curse As with most things in technology, this shift is both a blessing and a curse. Sometimes, immediate notificat...

As a developer, there’s a familiar moment many of us have experienced... You open a file to add a small feature and suddenly you’re staring at code that feels dated, awkward, or harder to work with than you’d like. Naturally, the instinct kicks in: “While I’m here, I’ll just tidy this up.” Optimise that method. Rename a few things. Reorganise the files. Introduce a more modern pattern. Upgrade the framework. After all, that’s what good engineers do… right? Well. Sometimes. And sometimes that’s how a one-line feature turns into a multi-sprint adventure, a nervous QA team, and a pull request that needs its own table of contents. The blast radius problem Refactoring isn’t inherently bad. In fact, leaving code worse than you found it is almost always the wrong call. But unplanned, opportunistic refactoring dramatically increases the blast radius of a change. What started as “add a new button to export the data” can quickly become: Increased regression risk Missed sprint comm...