subscribe via RSS
Recent Articles
-
A Central Conflict in 'Readable' Code
Programmers routinely complain about code being “unreadable”. They also routinely argue, sometimes quite heatedly, about how to make code “more readable”. I have noticed a conflict that they might be missing which could help moderate those arguments and make them more constructive.
-
In the Age of Generative AI, Better Design Remains Up to Us
When Common Practice becomes even more commonly-practised, the economic forces on software design change in a way that both creates more opportunities and makes it harder to seize those opportunities. I suspect that means that so-called “better” design will remain up to the individuals who decide that they simply enjoy their jobs more when they get to work in more-habitable code.
-
Blue Tape and Inbox Technique
Many people struggle to apply the ideas in Getting Things Done, partly because those ideas seem like abstract “good things to do”, rather than as simple, practical solutions to immediate problems. Michael Lopp’s metaphor of “Blue Tape” offers another way to understand the power of Inbox Technique, which might help you (or someone who needs it!) persist in writing things down, even when it seems like they’re doing it, but nothing’s really happening.
-
An Alternative Formulation of Getting Things Done
Describing the transformative benefits of Getting Things Done sometimes sounds like cult indoctrination. Describing the concrete steps of getting started with GTD risks making it sound like pointless busywork. I propose another way to think about GTD that, I hope, makes it sound more compelling, both to get started and to stick with it.
-
How I'd Like Automation Engineers to Support Delivering Features
Between the programmers and the testers stand the automation engineers, who allow each of those other groups of people to focus on what they do best, all in the service of delivering features more effectively.
-
Making Use of 'Silly' Advice: Part 3
When we read advice that ignores our context, we have a choice: ignore it, refute it, or allow it to help us. Here, we explore a way to get more value from that advice, even when we feel the impulse to merely react to it.
-
Forecast Costs Responsibly
I routinely encourage clients to resist forecasting project costs, especially at the detailed level of tasks, stories, features. I do this because I think they could spend their precious energy elsewhere more effectively and with greater benefit. Even so, project costs tend to stir up intense emotions, so people struggle mightily to set those concerns aside. If you insist on trying to forecast cost more accurately, then I’d like to point you towards helpful advice on doing that without tying yourself up in knots.
-
Slack's Role in Managing Software Projects: Revisited
When I first read the “Slack” section of Extreme Programming Explained, nearly 20 years ago, it shocked me. It instantly repelled me. Over time, however, I have seen the wisdom of that approach and I’d like to share that wisdom with you.
-
Making Use of 'Silly' Advice: Part 2
A simple substitution is all it takes to transform silly advice into something valuable! Here is an example that you can find just about everywhere on the internet.
-
Our Collective Struggle Over Technical Debt
People have struggled to understand and make use of the concept of Technical Debt for over 20 years now. I offer one idea with the hopes of reducing even just a small amount of our collective suffering.
-
Making Use of 'Silly' Advice
Some advice seems just silly: pointless, nitpicking, arbitrary. You could yell at it, complain about it, ignore it, or perhaps find a way to make use of it. I offer you an example of how to do that.
-
Giraffe Ears: An Example
A practical example of how to use the “Giraffe Ears” concept from Nonviolent Communication, taken from conversations that programmers routinely have with their coworkers.