Every few months, someone invents a new way to talk to AI that promises to save you money. The latest is something called TOON which stands for Token-Oriented Object Notation. If you work with large language models like ChatGPT or Claude, you might have seen it mentioned. It's
Most developers are using LLMs wrong. They treat them like glorified autocomplete - type a prompt, get some code, copy-paste, move on. It's faster than StackOverflow, sure. But it's just as shallow. The real power of LLMs isn't that they write code for you.
There's a peculiar amnesia in our profession. We learned about preconditions, postconditions, and invariants, perhaps in a university course on formal methods, or from a book on defensive programming, or during a discussion about Design by Contract. We nodded along, maybe even implemented some assertions in our code.
We're drowning in solutions. Every month brings a new framework promising to tame complexity. Another architecture pattern guaranteeing maintainability. Another service boundary that will keep the chaos contained. We've built an entire industry on the premise that if we just find the right combination of tools,
Martin Fowler's influential definition of refactoring has guided software engineers for decades: "Refactoring is the process of changing a software system so it does not alter the external behavior of the code but improves its internal structure." It's a clean, safe definition and also
AWS's US-East-1 region went dark because of a timing failure in its DNS automation layer, a system designed specifically to prevent such failures. Three components, all functioning correctly in isolation, interacted at the wrong moment: one DNS worker processing slowly, another deleting aggressively, and a planner generating updates
How foundational principles reveal both excellence and pathology in real code Note: This analysis is based on the design principles dojo created by Ilias Bartolini. The dojo provides an excellent foundation for exploring software design through Conway's Game of Life. This post extends that work by evaluating the
Going further than polymorphism - demonstrating value objects, type-driven design, and MIRO principles Introduction Martin Fowler's Theatrical Players example from Chapter 1 of "Refactoring" (2nd Edition) is a masterclass in basic refactoring techniques. He demonstrates: * Extract Method * Split Phase * Replace Conditional with Polymorphism * Move Method These
The Tennis Refactoring Kata has been solved thousands of times. Most solutions look the same: extract a few methods, add some constants, maybe introduce an enum for scores. The tests pass, the code looks cleaner, and everyone moves on. But something profound is being missed. The Tennis Kata isn'
The Challenge The Gilded Rose Refactoring Kata is famous for its nested conditional nightmare. Everyone focuses on eliminating the if statements. But what if the kata is teaching something deeper? What if it's a perfect sandbox for practicing four fundamental complexity management patterns? The Four Patterns 1. Boolean
The Setup The Gilded Rose Refactoring Kata by Terry Hughes and Emily Bache is one of the most popular refactoring exercises. It presents messy, nested conditional code that needs cleaning up. Everyone focuses on eliminating the nested if statements. And that's good! But they all miss something deeper.
For years, developers have debated the minutiae of clean code. Should methods be five lines or fifteen? What makes a good variable name…