subscribe via RSS
Recent Articles
-
The Coming Battle About Psychological Safety
Psychological safety is helpful. No, it’s awesome! No, it’s evil! You’re doing it wrong! Well, we tried. What? Are you still talking about that stuff?
-
Agile's Hyperproductivity X-Prize
A small group at IBM has found a shortcut to hyperproductivity. (Humor, in case that wasn’t clear.)
-
Sooner, Not Faster Revisited
Over a decade after I first heard it, “sooner, not faster” remains one of quickest ways I know to explain one of the key points of lightweight software development.
-
XP: My Greatest Misses, 2000-2009
Instead of my greatest hits, this is a collection of my greatest misses: ten big mistakes that I made early in my career. I believe that I’ve learned from these mistakes. Perhaps you can relate to some of them. Perhaps you can learn from them, too.
-
Sometimes The Ax Is Sharp Enough
Sometimes the ax is already sharp enough. Sometimes you believe you’re sharpening the ax, when you’re doing something else. And sometimes it doesn’t actually matter.
-
TDD "Isn't About Testing" Revisited
I’d written an article to my mailing list decrying the attitude of “TDD isn’t about testing, you idiot!” and a reader asked me a few things to clarify my position. In the process, they pointed me to an article that they considered a reasonable articulation of the issues involving the importance of writing tests first, then asked me what I think about it.
-
Choosing New Habits
We have a limited amount of energy to invest in new habits, so how do we know which habits to try to form? I know two complementary strategies.
-
Avoiding Distractions While Programming
If you have read Getting Things Done, then you can already guess what I’m about to write here: use your inbox. If you haven’t read Getting Things Done, then you need to know what I mean.
-
Flow Requires Focus, Not Time
You’ve almost certainly heard about flow, an immersive state of intense focus during which a person often does their best, most effective, most rewarding work. I see many people use flow to justify recommending against certain working practices, like open workspaces, pair programming, and incremental delivery, arguing that people need long stretches of time to enter the flow state. Not only does working for long stretches not necessarily help me reach “the zone”, but by working in short bursts, I’ve conditioned myself to reach “the zone” quicker, and more often. I’d like to tell you what I do and how I think it might work.
-
What If We Forget To Write the Tests?
When programmers forget to write tests for features, we might interpret that as a sign that their heart’s not in it. This easily leads one to look for ways to ensure compliance. Even if you’re well-intentioned, you’re probably barking up the wrong tree.