Like many programmers, I am not a “people” person, but this article is about people. First, how might you discern what “people” aspects of your project are essential? Here’s my approach. Second, how might people inspire you and help make what you do more fun? We’ll see my approach as we make the transition from abstract discussions back to concrete details.

This month, we’re indulging in a bit of magic and a bit of weirdness. That’s my way of explaining what I call Wizard Thinking, something I’ve found to be an instrumental skill indeed.

When you encounter extremely costly errors, take steps to prevent the error from happening in the future. The earlier we catch an error, the less expensive it is to fix. Here we discuss two costly situations: a typo in an if statement and upcoming PHP 8 breaking changes.

Last month, we used Herbert O. Yardley’s “The Education of a Poker Player” to learn about testing business rules. This month we’ll explore what happened when the world shifted, and Yardley lost not just his job but his career. The lesson here will be “don’t be like Yardley”—yet Yardley’s story is, by all accounts, fascinating. […]

There’s an old joke that runs, “We just got a new project. You two start coding while I go find out the requirements.” This month we talk about evaluating and implementing business rules, thus meeting project requirements. We focus on discerning what’s important and what isn’t, and recognizing interactions that can quickly get out of […]

While completing the Deep Analysis we discussed last month, I was faced with the inability to test. That’s because—I discovered–accounting data cannot be erased—even in the sandbox. There’s no way to begin each test with a clean test environment. This month we walk through a relatively convoluted solution. We’ll capture the accounting data as we […]

Sometimes, I need to write experimental code in order to explore and understand how the system works. This is particularly true when dealing with third-party software. Sometimes those experiments become large with many thousands of lines of “experimental” code. Here are my principles and guidelines for making that experimental code a success.

Domain Events are one of the mainstays of modern Domain-Driven Design. They’re powerful, simple, useful. However, when developing them, we need to consider infrastructure. We’ll examine the need for explicit database transactions, view a table design, and provide a way to do our future selves a favor!

Technical debt is always, and continuously, a challenge. Needs change. This month we’re looking at an approach for being continually prepared for change—refactoring, with unit tests in place.

How might we keep the next PHP project from evolving into the dreaded Big Ball of Mud? This month we’ll explore and build a possible foundational structure, a “composite.” Then, having built out this structure, we’ll realize that we might still be over-engineering things a bit—but this structure remains a necessary step along the way.