I always look forward to the AWS Summit. It’s a great opportunity to learn what AWS, and the engineers who use it, are up to, and to catch up with my colleagues. This year, though, turned out to be a bit different. The first year I attended, I skipped the keynote entirely and spent the time in the AWS labs instead. Last year I did go to the keynote, and wished I hadn’t. This year I attempted to do both, but it didn’t really work. I managed just one very simple lab before I had to leave for the keynote. Although I did manage to get to the Red Hat stand early and be the first to get an actual red hat! Although I did have to carry it around all day and all the way back to Norwich that evening. One of the main issues is the size of ExCeL. It’s big. I mean really big. You may think it’s a long way down the street to the chemist, but that’s peanuts to ExCeL. It’s a long way from anywhere to anywhere else. Poor Hitchhiker’s Guide to the Galaxy references aside, many things, inc...
Judiciously: With good judgement. Logging is one of the simplest things a developer can do, and one of the easiest things to get wrong. A single misplaced log line can be harmless, but a pattern of careless logging turns into noise, confusion, and even security risk. The challenge isn’t teaching engineers how to log, it’s helping them understand why they’re logging in the first place. Here I intended to draw that distinction clearly: choosing logs that illuminate behaviour, support debugging, and reveal failures, while avoiding the chatter, duplication, and reassurance‑driven messages that bury the real signals. Finding the Line Between Useful and Noisy Teams often fall into the trap of believing that if they simply “log enough,” the rest of observability will take care of itself. It’s an appealing idea: produce a steady stream of detail, let dashboards and alerts sift through it, and assume that somewhere in the noise the truth will reveal itself. But this mindset skips th...