jbrains.ca

Deadlines As An Act Of Love

Fri, 20 Feb 2026 00:00:00 -0400

When you think of deadlines you likely think of deadline pressure. Most business environments make deadline pressure part of their culture. Moreover, as we talk more about folks having difficulties with executive function, we have become more aware of the challenges they have with deadlines, resulting in more acceptance but also more stigma. Given all this, the larger We has a complicated relationship with deadlines.

Fortunately, we have the chance to reframe this situation to make all this work more with us than against us. Join me!

I propose deadlines as an act of love. (I’ve made this sound saccharine and grandiose on purpose, so that you might remember it, but I also genuinely believe it to be true.) You might resist this and see deadlines as an attempt to control, a way for some folks to exert power over others, as an imposition on others’ time on one side of the transaction or as an unfair demand on the other side. Let’s reject all that!

(I mean, yes: some folks will try to wield deadlines as a weapon, but we don’t have to optimize for those folks, even if our financial situation might require us to tolerate and even accept them.)

I want people to give me clear deadlines for some straightforward reasons:

A deadline allows me to schedule my work.
A deadline allows me to judge reasonably accurately whether I can fulfill their request or not.
A deadline helps me infer something about how the requester sees the urgency of a request, if that’s not already clear.
A deadline helps me decide whether I can accept the cost of missing the deadline as compared to the cost of hitting it.

Framing the situation this way, people are doing me a favor by giving me a clear deadline!

I want to give other people clear deadlines because I want to give them the same clarity they give me. We can really decide to let it be that simple.

Beyond this, I can refer to the mounting experience of folks with executive function difficulties who need and even embrace the controled motivation associated with deadlines in order to actually get around to the task I’m asking them to do. This seems especially true when I’m asking them to do something that they would not otherwise do spontaneously, voluntarily, and happily.

In order for this to work, however, we need to reframe deadlines more generally.

I propose that we treat deadlines as statements of value or vulnerability about constraints, not as demands. The more of us who agree to do this, the better the whole system works, and the more harmoniously we can work and live together. You might notice that I’ve used words like “request” and “ask” here, rather than “requirement” or “demand”. I do this because, no matter how much you have been conditioned to believe in deadlines as demands and requirements, they are always requests and statements of value. “I need this by Friday” means “If you can’t do this for me by Friday, then I need to find someone else to do it, because its value to me after Friday drops to nothing”. Something like that. A person who gives you a deadline for a task is showing vulnerability by sharing with you something about the value of completing the task to them or about the constraints they face if they fail to deliver their work to someone else. They are trusting you to help them reach their objectives. They are hoping (often desperately!) that you will be able and willing to help them.

Yes, even when they are yelling or barking orders to take advantage of their positional authority over you. The yelling manager is often covering for insecurity about something they’re trying to deliver to someone else. If we show them compassion now, maybe they will learn to show us compassion later.

This feels different to me than it does to consider deadlines as a cynical attempt to extract more output from me sooner. Again: some folks will try to do this, but if you sense this, then you can fall back to this classic adage:

When you owe the bank $10 thousand, that’s your problem; when you owe the bank $100 million, that’s the bank’s problem.

At some point, the person standing before you barking orders at you increasingly loudly, threatening you with deadline after deadline has to understand that they need you more than you need them. You can tell them this, even gently, but you can’t learn it for them.

Nonviolent communication practice encourages us to make clear requests to others so that they have enough information to decide safely and accurately how able they are to help us. This frees everyone up to act freely, to choose consciously, to say “yes” or “no” based on real constraints and capacity, rather than based on their mental relationship scorecard of accumulated unbalanced favors over time and the need to exert power over others in order to feel more in control of one’s own life. Clear deadlines represent a way to talk to each other more honestly and gives us more space to react consciously.

We can turn deadlines into an act of love, but it starts with choosing to see deadlines as an act of love, even if buried under crusty layers of controling motivation and contempt. It starts with recognizing that a deadline is merely helpful information when we negotiate with someone to do a task for us. It starts with remembering that “no” is always an answer we can accept. (Right?)

That seems to me like a modest concession for a huge shared victory. What do you think?

Adopting Tricky Design Concepts Safely

Thu, 15 Jan 2026 00:00:00 -0400

Quick question, if you want to implement a design that leverage a particular tricky concept but it’s a good technical decision for the software you’re building, what should you focus on?

What kind of “good” is that good technical decision? Who will need to change that code after you finish writing it?

An example that immediately comes to mind would be something like writing Front-End components using the Atomic Design Pattern. It makes writing modular components simpler but the pattern can be difficult to understand at first and apply properly at first.

Would mostly apply to Front-End & UI Devs

If I can see how to refactor safely from What We Typically Do to the Desired Future Standard Design, then that would make it safer to advocate for the DFSD while falling back to WWTD. Yes, it takes time to refactor, but in exchange, I don’t have to view the dilemma as all or nothing. Meantime, it’s hard to say where I’d focus, but I’d always be prepared for the group to decide that they’re just not going to accept the DFSD yet. Then I can decide which strategy to adopt: enlist a trusted colleague, demonstrate a pilot project, extract a Warm Dry Place with freedom to choose…

Typically, when technical leaders treat such a dilemma as “all or nothing” and “now or never”, then they get into trouble. This often creates more problems than it solves. Decision making like this is either an ongoing negotiation or a dictatorship. Pick one. (I can respect both choices.)

BTW: I didn’t know about Atomic Design, but I made some guesses, then I read a few articles. I mostly guessed correctly. This approach is not new. It has been proposed and discarded several times over the last 3 decades, especially during the Early Mainstream Adoption of OO design.

I believe (based on evidence from similar discussions in the past) that the conflict lies mostly in viewing software design as an activity of “First figure out the correct boxes, then carefully put each line of code in the correct box, and get it right the first time.” Even when programmers don’t say this explicitly, their objections and complaints reveal a bias towards deciding every little thing correctly the first time. Notably, they view changing decisions as “mistakes” and “avoidable rework”.

I propose that we radically change this attitude.

This is why I promote understanding how to refactor towards patterns such as Atomic Design: when we feel competent and confident doing this, then we are free to “get it wrong”, secure in the knowledge that we will gradually converge towards a reliable pattern as we need it.

I find patterns and styles such as Atomic Design more helpful when I know how to break them without disastrous consequences. Sometimes, we need to break the rules for a while, to achieve some other goal, then later bring the design in line with our established patterns and guidelines.

When programmers feel the freedom to change their minds, they can live in the best of both worlds: the security of a reliable pattern or guideline or framework without seeing those things as prisons that prevent them from Getting This Simple Stupid Thing Done Sooner.

One more thing: when we resolve to refactor in the direction of the pattern, then we stop arguing about “how to apply the pattern correctly” and instead simply nudge the design in the direction of the pattern relentlessly. We’re more likely to get there with less drama.

A Central Conflict in 'Readable' Code

Thu, 04 Dec 2025 00:00:00 -0400

I have written before about why I don’t like to label code as “readable” or “unreadable”, but sadly, this has not stopped the world from doing this. I have lodged complaints with the appropriate departments.

I believe that programmers generally want to spend less energy trying to understand code. Since humans are energy-conserving machines, this feels like a reasonable belief. Programmers, then, want code that costs less to understand so that they can change it safely and accurately. “Costs less” can be (somewhat) measured by time, energy, or even money. I’ll assume, for the rest of this article, that we share the goal of making code less expensive to understand. I might even call this the primary goal of “software design”.

In order to make code less expensive to understand, you have two key strategies: simplifying it or becoming more familiar with it.

By “simplifying” code, I mean reducing the number of things you need to know in order to understand the code. This tends to mean things such as moving irrelevant details out of the way and making relevant details easier to see. Becoming familiar with code usually only happens by spending time engaging with the code, such as by reading it or testing it or trying to change it.

It makes sense to try to simplify code, because this activity both reduces the amount of code you need to become familiar with and is itself an activity that causes programmers to work with code and become more familiar with it. The act of trying to simplify code helps programmers understand code sooner both by reducing the necessary investment and by also being part of making that investment. It seems like a win-win.

This is why we refactor, remove duplication, improve names, introduce abstractions, add tests… all the things that we have been talking about and debating over the decades.

What’s the Catch?!

Sadly, in order to simplify code, we risk making it less familiar. This happens because we:

introduce libraries that not everyone knows
introduce abstractions that not everyone has participated in choosing
need to name new design elements and we’re not excellent at naming

Not only that, but while we are in the relatively early stages of learning to do these things, we have to overdo them in order to form the judgment to do them correctly and appropriately and judiciously.

Simplifying code therefore risks making it less familiar. When we do this, we are betting that the savings from simplifying will be greater than the additional costs of losing familiarity. We’re also betting that it will become cheaper to invest in restoring our previous levels of familiarity.

When we simplify code in a way that makes the code less familiar, then I recommend focusing on improving names to make the code more familiar to your intended audience. In the process, according to The Simple Design Dynamo, you would iterate through removing duplication and improving names until you reached a new balance point where you judged the code as “good enough” to move on. When does this happen? Probably when the act of simplifying the code has given you a chance to become familiar with it again. Your subjective experience of becoming familiar with the new design informs your choices to remove duplication and improve names in a way that helps the code be more familiar to the other programmers not actively involved in your work.

In short, you’d start by focusing on simplifying the code, then you’d gradually transition to making the code (more likely to seem) more familiar before declaring victory and moving on.

So What?!

And here is the key point: we must be prepared to make the code less familiar for some time in order to simplify it. I believe the real power of the work lies here. If we are not prepared to let the code be less familiar for some time, then we will only ever simplify it when there is a clear, obvious way to simplify it. That can help, too, but I believe you would miss out on powerful opportunities to improve the design if you stuck with such a conservative, passive strategy.

Many of those programmers arguing heatedly in meetings about refactoring are objecting to changes (or refusing to merge PRs) only because the code has become less familiar to them. Their reaction seems perfectly reasonable to me, but I believe it is ultimately self-limiting. When you add to this situation the tendency to conflate complicated code and unfamiliar code as “unreadable”, those arguments become nearly impossible to resolve without resorting to dysfunctions such as deferring to the Highest Paid Person In the Room or the Loudest Person In the Room. You need another tool to avoid this fate:

If you want code to become less expensive to understand over time, then I argue that you must be willing to risk the code becoming unfamiliar; otherwise, you will miss your best opportunities to simplify it.

Do you struggle with technical leadership issues such as this one? Do you want to take advice like this, but feel emotional obstacles that you don’t quite understand or know yet how to deal with? I believe I can help. It’s not free, but software development professionals are getting the help they need as part of The jbrains Experience.

In the Age of Generative AI, Better Design Remains Up to Us

Mon, 01 Dec 2025 00:00:00 -0400

As we use LLMs to generate more code, Common Practice will become even more common, which creates an amplifying feedback loop entrenching Common Practice, even when what people are commonly doing seems unwise.¹ This means that we’ll see more code with more code smells that could be improved. More opportunities.

As we rely on LLMs to generate more code, there will be mounting pressure to do more with less. Programmers tend to react to that pressure by writing more code sooner (so let the LLMs generate it) and feeling pressure to look less carefully at the results (even when they know they need to monitor what the LLM produces quite carefully), even when that’s (clearly) unwise (and they know better). This means that we’ll see more code with code smells that simply won’t be improved, even in spite of everyone’s best efforts. More people will have less time (and less energy!) to seize the obvious opportunities in front of them.

The optimist in me hopes that the companies with “better” designs² will realize the benefits that come with “better” designs and stand out even more from the crowd with their ability to adapt to changing market forces. They would pivot sooner and more easily, feeling less resistance to make difficult business decisions and to take reasonable, calculated risks.

I am worried, however, that there will merely be a bigger population of mediocre companies for the average companies to (barely) outpace. As a result, those average companies will still have designs that mire programmers in frustrating busywork, rather than allowing them to better meet the demands of (reasonably) impatient stakeholders and customers.

Where Have I Heard This Before?

Patrick Lencioni wrote that teamwork was the business world’s richest untapped competitive advantage. Even decades after he wrote this, from what I can tell, not much has changed. Not enough folks understand the power of teamwork and find themselves with the combination of influence and opportunity to demonstrate its power. I think we’ll be writing in similar terms and more intensely about “better” software design in the next ten years or so.

I only know that I enjoy my programming work more when I get to live in habitable code. Maybe that’s how it will be: we will meet each other from time to time in warm, dry places where we invest in our own comfort and joy, whether our employers like it or not, as much as we can, for as long as we can.

Same as it ever was, I think.

See you there.

In a LinkedIn post, Joshua Kerievsky pointed out the proliferation of design risks (“code smells”) in the code that LLMs were generating. He raised the example of discovering a race condition made worse by polling, where it would probably help more to introduce explicit events to handle the concurrency.↩︎
I don’t like to refer to designs as “better” or “worse”, because that glosses over the complexities of software design. Even so, we occasionally need to resort to shorthand for brevity, such as I’m doing here. When I write about “better” design, I mean organizing the source code in ways that reduce the cost of a human understanding it so that they can change it safely and accurately.↩︎

Blue Tape and Inbox Technique

Thu, 20 Nov 2025 00:00:00 -0400

Michael Lopp’s article, “The Blue Tape List” reached me today and I feel very glad that I took the time to read it. (I, too, have a backlog of thousands of articles waiting for me to read them.) While I read this delightful article, I noticed how much I liked the metaphor of Blue Tape and how it immediately sounded like something I teach regularly: Inbox Technique.

Inbox Technique boils down to writing things down so that they don’t distract you while you’re trying to focus on a task. I teach this to programmers as a centerpiece to working effectively, as I described in detail in “Avoiding Distractions While Programming”.

Putting blue tape on something that needs fixing sounds writing down a particular kind of item in my inbox: “Do something about X!” (or probably just “X!!!”)

From here, the corresponding parts of the Blue Tape metaphor and Inbox Technique/Getting Things Done start leaping to mind.

While working on a task, when a distraction comes up, write it down (add blue tape). Writing it down is not a commitment to doing the new thing, but rather a commitment to at least consider (address) the new thing. During this task, you will complete some of what you’ve added into the Inbox, and then when you can pause, you need to do something with what’s left in the Inbox. Do what?

Delete, defer, delegate, or do. (All ways to address the items.)

What Happens Next?

When I teach Inbox Technique to folks, I primarily want them to experience the feeling of focus, but they tend to worry first about what to do with their Inboxes. Not every item that I write down becomes a new task, so it doesn’t always feel obvious what I ought to do with these inbox items, since I can’t always responsibly delete them.

Over the years, I’ve learned strategies such as converting these items into certain kinds of tasks that I put into my Trusted System. I find it helpful to phrase those items as tasks, which means that when I read them, I need to know how to do them. I phrase them as actions. Let me provide some examples:

“Spend 10 minutes deciding whether to do X.”
“Choose when to start working on Y.”
“Decide once and for all whether to bother doing Z.”

Each of these provides an example of how to address the blue tape without assuming that we actually have to fix what the blue tape is alerting us to. As Michael points out:

You will notice my homework to new hires did not commit to fixing everything they saw, I committed to addressing it. This could mean fixing the issue, but it could also mean responding and clearly explaining my reasoning why I didn’t think fixing the issue was the right move.

Similarly, you are not obliged to do everything that you write in your Inbox. I consider this point critical, because if you thought of Inbox items as commitments to future projects, then you would gradually stop writing things down out of self defence. You would feel too afraid of overburdening yourself by overcommitting. And if you didn’t write these things down, then you’d never feel the freedom that comes with truly, deeply focusing on the current task. You would be missing the point of Inbox Technique in particular and of Getting Things Done more generally!

Whether you think of this as Inbox Technique or Blue Tape doesn’t much matter to me. I merely want you to feel this power of focusing on the current task because you trust yourself to handle future tasks as you need to and when you need to. That’s the power of Getting Things Done. And if you need to internalize this as a Blue Tape list to get those benefits, I’m happy. The only rule is that it has to work.

What’s New in Blue Tape?

More than providing another way to understand Inbox Technique and Getting Things Done, I really like Michael’s explanation of the special context in which these distractions are coming to mind: you’re in a new context and you are constantly seeing things that you will eventually start to ignore when they become more familiar. Michael’s invites you to make use of seeing these things while you so easily notice them.

It’s a surprise when a month passes, and you review your blue tape list and discover how items that seemed urgent at the time now seem entirely irrelevant. You are learning so much every single minute of a new gig; you are gathering so much context. You are continually updating your understanding, your context of the team, your role, and the company. Your understanding after three months of work isn’t remotely complete, but it is exponentially more complete than at the end of month two.

You still address every item on the blue tape list. Every item gets a response. If you’re planning on fixing the issue, explain how and when. If you’re not planning on fixing it, explain why. If you still aren’t sure about relative importance, think about how you might find it.

A large new context is uncomfortable. It’s an emotional time because that which was daily familiar is now wholly foreign. The high alert your brain defaults to is stressful, but it’s a lens that allows you to see defects the old guard can no longer see.

I see this as part of what makes Inbox Technique powerful: it allows you to notice things without feeling weighed down by them. When you feel weighed down by noticing things, then you train yourself to stop noticing, which destroys the value of noticing. I want the benefits of noticing, so I make it less expensive and less painful to notice things.

This last point corresponds directly to one of the points underlying Extreme Programming theory: feedback has value, but only when we get it in time to do something with it, otherwise it becomes merely painful in the form of regret. And we generally don’t handle regret well. Accordingly, we seek feedback not because “it’s good for us” or “someone wrote it in a book somewhere”, but rather because we have a strategy for doing something with it. I use Getting Things Done as one of my strategies for making use of the feedback that I give myself in the form of distractions surfacing while I’m trying to focus on a task. Without Inbox Technique, I would merely be distracted, feel uncomfortable, make more mistakes, and work more slowly.

As Michael points out in his article, when you know your brain will be sensitive to distractions, it helps to have a system for making use of those distractions. Blue Tape, Inbox, whatever you call it, I encourage you to build a system for letting those distractions be as they are, such as by making them constructive, rather than by trying to push them away. When you push them away, they tend to react by never, ever leaving you in peace.

An Alternative Formulation of Getting Things Done

Mon, 30 Dec 2024 00:00:00 -0400

It’s easy to see Getting Things Done—both the book and the concept—as being only about making lists and setting reminders. They are the easiest parts of GTD to describe, which makes it easy to find articles about them, but they’re not the most powerful benefits. Unfortunately, when we write and talk about Big Picture Issues, such as figuring out what you really want to do in life and cultivating “the courage to say ‘No’”, we run the risk of sounding like Woo Merchants with Big-Sounding Ideas but Nothing Helpful. I’d rather not do that, so I’m considering a different question.

What would happen if you practised GTD? What could you expect that goes beyond making lists and setting reminders?

Getting Things Done Milestones

When I practised the techniques I learned from Getting Things Done, I noticed at least two significant milestones along the way. These are skills that I cultivated by practising GTD. Skills that I didn’t even realize I needed, would come to rely on, and would eventually dearly love.

safely forgetting
safely ignoring

The list-making and reminder-setting habits helped me learn to safely forget things, so that I could balance concentrating on finishing tasks with thinking about the wider picture. Doing this over the period of a few years freed up both the time and (mental, emotional) space I needed to reach the next milestone. My attention turned naturally to whether I truly needed to be doing all these things. This helped me learn to safely ignore things, such as projects that I could leave to someone else or that didn’t need to be done at all!

Some folks write about these abilities as your latent superpowers and when you’re drowning in projects, it can seem like pure fantasy to imagine reaching a stage in your life in which you could say “no” to people and focus on what you care about, rather than what the world demands of you. Reading their article, you could be forgiven for feeling like they’re blaming you for not taking control of your workload—like they’re telling you that you’re Doing Life Wrong. I don’t want to do that. Instead, I’d like you to know that practising the tedious techniques of making lists and setting reminders, along with the other techniques from Getting Things Done provides a path towards developing the skills, the confidence, and the courage to get there. You don’t have to have been born with it. You don’t have to have learned it by luck. You can cultivate these skills, starting with simple tricks such as the Two-Minute Rule and Inbox Technique.

You can do this and you can find straightforward places to start. It won’t be easy, but imagine how it would feel the first time you forgot something safely, with confidence, and without consequence! How would your life change if you knew how to forget or even ignore certain tasks or projects or things? If you could do these things safely? If you could do them responsibly? If you could do them openly in a way that didn’t feel like a temporary vacation or a guilty pleasure?

That’s what I believe you could learn from Getting Things Done. I imagine there are other ways to get there, but I suspect they’d all go through these milestones eventually: safely forgetting, along the path towards safely ignoring.

How I'd Like Automation Engineers to Support Delivering Features

Fri, 18 Oct 2024 00:00:00 -0300

Hi, I’m a Quality Engineer at my organization and I recently watched your video about integration tests being a scam.¹ We’re rearchitecting a lot of our system and exploring ways to better automate our testing to ensure we can deploy faster and with more confidence and I’m exploring ways the quality team can support this. How do you see a quality team working in a world where integration tests aren’t helpful in reducing bugs/mistakes? If the focus is on low level unit tests which are often better facilitated by developers, what can automation engineers do to support the product?

I’d like to start by clarifying a key point: I find integrated tests helpful in reducing bugs/mistakes, but I rely on them less than other people do. I tend to avoid mistakes with mostly microtests and integrated tests at the boundaries. I tend to use integrated tests to explore unexpected problems, then I tend to replace those integrated tests with microtests as I pinpoint the source of the problem.

All this means that if an integrated test finds a defect, then we ask, “Why didn’t we find this defect with a unit test?” And we ask this question in an open way, not in a blaming way: most of the time, we notice that we missed a unit test that we would have written if we had had all the time in the world, but sometimes we find a defect that nobody saw coming, and that’s when we feel grateful for the integrated test.

I say this not as a form of “well, actually…”, but because explaining that provides some context that makes it more convenient to answer the question.

How do I prefer to work with automation engineers? First, let me describe how I prefer to work with human testers, then how the automation engineers act as a bridge between programmers and testers.

Behold the Human Tester

First, imagine the role of the human tester. In The Bad Old Days, a programmer would write code, then throw it over a wall where it would land on a human tester. The human tester would then run some “tests”, probably by following a Test Script or a Test Plan, to do what we now call “routine checking” in the Michael Bolton² sense. Some folks saw this testing role as waste, so we decided one day that programmers ought to become testers and we called it “Test-First Programming”, which later became known as “Test-Driven Development”. From that point forward, the programmer took primary responsibility for routine checking, leaving the human tester to do… what, exactly?

The human tester no longer needed to do routine checking, because the programmer was doing it. This meant that the human tester could turn their attention to more interesting risks in the system. We use names such as “Exploratory Testing” and “Soap Opera Testing” to describe a kind of extraordinary testing, the kind that goes beyond the kinds of routine checking that “even a programmer” could be trusted to do. As a programmer, what I then need from the human tester is no longer to automate routine checks, but instead to explore the product, to challenge assumptions, and to subvert expectations. Instead of playing the role of parent cleaning the child’s face with a wet cloth, the human tester now has the programmer’s back in a fight (presumably against the defects in their system?). The programmer feels comfortable doing the routine checking, confident that the human tester covers their blind spots. They communicate; they compensate for each other’s weaknesses; they complement each other.

Enter the Automation Engineer

Now we come to how I ask the automating engineer to help: establish a pipeline for automating the human tester’s work when they uncover a test that the programmer would like to adopt as a routine check. The automation engineer helps the human tester avoid falling back into the trap of mindlessly running routine checks. True: these new routine checks are more interesting and more powerful than the previous ones, but the purpose of automation is to do repetitive things so that humans are free to become even more creative.³ The automation engineer plays a pivotal role as an agent of the human tester, relieving them of the burden of executing the same checks over and over again. The human tester explores the system and as they find interesting behavior, the resulting tests transform gradually into checks. The automation engineer automates those checks, so that the programmer can benefit from them as an ever-improving pool of change detectors.

Moreover, I’d like the automation engineer and the programmer to work together to transform bigger-scope (integrated) tests into smaller-scope (micro-) tests, because the automation engineer understands enough software design and testing to bridge the communication gap. The programmer doesn’t have to become an expert tester, nor does the tester have to become an expert programmer, but rather the automation engineer understands both groups and facilitates the transition from larger-scope extraordinary tests to smaller-scope routine checks.⁴

Moreover moreover, the programmer is allowed to focus on unit tests, so they write more of them, which strengthens those tests as a mechanism for finding defects and supporting refactoring. Consequently, the tester is less-often distracted by silly mistakes that the programmers really could have found or avoided on their own. The tester has more time and energy to devote to finding even more interesting problems before the end users do. In this way, the testers become free to act as agents of the end user or customer. They can think more about the system as a product from the end user’s point of view, rather than being relegated to treating the system as a bunch of bug-riddled software components in need of constant attention. Over the longer term, the tester develops a greater understanding of how the product might satisfy the customer—and even delight them!

Everyone wins. Let’s go!

I strongly strongly strongly prefer people to watch this version of the talk to any of the previous versions of the talk. And if you’ve seen one of the older versions, then please watch this next.↩︎
No, not that one, and not that one, either, but this one.↩︎
Something something generative AI something something.↩︎
The mediator between Programmer and Tester may be the Automation Engineer.↩︎

Making Use of 'Silly' Advice: Part 3

Fri, 02 Aug 2024 10:00:00 -0300

“We didn’t need it, therefore you don’t need it, so don’t do it.”

⚠ Caution. ⚠

When someone posts this, they might mean well and they might be very misguided. When you read this, I encourage you to look beyond the words to what might lie behind them.

I can think of at least two very different possibilities:

They are falling prey to damaging “Best Practices” thinking.
They have recently discovered that they could freely and safely stop doing something, because it was no longer necessary, and they want to remind the rest of the world to be aware of such opportunities in their context.

I find it difficult to tell the difference from here, outside their mind.

(I should mention now that if we spent another 15 minutes, we could probably find a few other ways to interpret those words, but I think these two interpretations make my point well enough, so I stopped.)

✅ Try this instead: ✅

Pretend they said or wrote this: “We didn’t need it (any more), therefore you might not need it (any more), so consider not doing it (any more)!”

The word “consider” stands out most to me.

We build habits in order to reduce the cost of helpful behavior. Unfortunately, habits often work best when they become autonomic, which means that we stop thinking about doing them. And we always risk habits becoming empty rituals. When the ritual becomes empty, the behavior stops helping us. At best, it merely gets a little in the way; at worst, it actively hurts us.

For that reason, we remind ourselves to inspect our ways of working every so often. Doing these inspections, we reconsider what we need to do, so that we can stop doing whatever has become unnecessary. And that’s how these words can become helpful: “We didn’t need it, therefore you don’t need it, so don’t do it.”

You can think of them as a somewhat unskillful way of saying “Do you really still need to do that? Does it still help you? Has it outlived its purpose? or did it never live up to its promise in the first place? What would happen if you stopped?” By interpreting those words more generously, we’ve turned them from apparently-mindless “Best Practices” thinking to a helpful reminder not to fall into the Grace Hopper trap: “We’ve always done it this way.” Even unskillful acts can help, if we remain open to how they might help.

Whenever you read or hear advice outside its context, I encourage you take it seriously without immediately assuming that you ought to follow it. I also encourage you to join me in resisting the impulse to tell them how wrong they are, because they’re often (but not always!) right in their context, even if they’re wrong in your context. It works even better to interpret their possibly unskillful act as a well-meaning attempt to help you. At some point in the future, you’ll probably wish that they’d interpreted your unskillful act that way.

Forecast Costs Responsibly

Wed, 10 Apr 2024 10:33:00 -0300

I think the typical software development group (team, department, …) has many more urgent matters to attend to than forecasting when tasks will be done. I don’t think it’s a bad idea to try to forecast more accurately; I merely believe that most organizations, most of the time, would benefit more from addressing other issues and letting this particular issue be as it is.

At the same time, almost everyone all the time wants to know when it’ll be done, for all kinds of meanings of “it”. And it therefore seems reasonable and urgent to try to forecast more accurately. This is merely a trick that the brain plays on us. We would have to train ourselves to resist the temptation to act on this source of false urgency.

I urge you not to bother trying to forecast the cost of tasks, even features, more accurately, but instead to work on other ways to improve. I can help you figure out what to focus on in your context, but maybe you’d rather start doing that on your own. In that case, start with the question of what’s interfering with delivering value to customers, then start chipping away at those obstacles. What’s valuable and when is it well and truly finally delivered? As you deliver more value to more paying customers, you’ll have more resources (including cash!) with which to figure out where to improve next. There’s more to it, but that’s a particularly helpful place to start (on average).

And if you insist on trying to forecast costs more accurately, then read Mike Bowler’s recent article on the topic.

Slack's Role in Managing Software Projects: Revisited

Thu, 28 Mar 2024 11:28:00 -0300

I remember reading Extreme Programming Explained, the second edition, and being surprised by the advice to put extra stories/tasks into the weekly iteration plan to use as ballast in the face of unplanned work. It seemed to me at the time like sandbagging—intentionally doing less than we could actually do. I didn’t understand the purpose of it.

At the time, I thought, “If we’re going to add more items into the weekly plan, then why not merely add the next stories in the priority list?!” Why would we choose to do anything but whatever would come next, especially since we assumed (thanks to Yesterday’s Weather) that we almost certainly wouldn’t get there anyway?

I didn’t understand much at the time about the psychological factors involved.

Now, I think of it like this:

It’s wise to put some items in the weekly plan that we don’t feel confident we can finish, just in case we get lucky and finish early what we expected to finish.
It’s risky for the extra items in the weekly plan to be items that the stakeholders care deeply about, because we’re setting them up for constant disappointment when we suggest that we might finish items that they care about, but routinely don’t finish.
It’s therefore wise for the extra items in the weekly plan to be items of significance that are not yet urgent, because there is a small chance that we might get to them, and if we don’t take advantage of that opportunity, then we might never get around to them… until they become urgent problems for us.

It would probably help everyone if our stakeholders never treated our weekly plan like a commitment, but that’s not how most people behave. Even the most attentive, caring, and collaborative stakeholders are humans and humans are easily disappointed. We react more sharply to loss and remember it longer than we do getting more than what we expected. I think it’s wise to choose an approach that reduces the likelihood of disappointment, all other things being equal.

After all, we always have the option of changing our minds and squeezing in a high-value story at the end of the week, thereby delighting some of the stakeholders. That sounds helpful, no?

Making Use of 'Silly' Advice: Part 2

Tue, 12 Mar 2024 10:06:00 -0300

To avoid arguments with strangers who are wrong on the internet, consider the following substitution in your mind as you read.

“You shouldn’t do X” or “Don’t do X” or “Stop doing X”

becomes

“You might not need to do X (especially merely because some book seems to recommend it). You might still choose to do X, but ask yourself whether that was a conscious choice, and if it wasn’t, then reconsider.”

Not as pithy, but much more accurate. And no need to correct internet strangers. That’s probably quite close to what they mean, anyway.

Some Theory

You probably remember a parent or other authority figure telling you that you can’t change them, but you always have the power to change yourself. I offer this trick as an example of how to do that.

You might feel annoyed that they don’t express themselves more precisely, resorting to blunt instruments such as “Don’t do X” when they really mean something much more nuanced. I understand that impulse, but I have found it helpful to imagine that they struggle to express themselves that way, even though it seems pretty easy to me. I know that, in moments of great stress, I fail to express myself with such emotional granularity as I can ordinarily do. Perhaps they’re under that kind of stress right now and that’s what motivated them to write about their advice, anyway!

What have we seen at work here? It depends on how you learned about it. I know these phrases and labels.

blaming stance
giraffe ears
emotional granularity
“Under stress, we fall back on our training.”
I am entirely responsible for my own emotional state

You don’t need to believe in or agree with all these, but perhaps one of two of them speaks to you.

Enjoy!

Our Collective Struggle Over Technical Debt

Wed, 24 Jan 2024 00:00:00 -0400

The term “Technical Debt” has changed quite a lot in general meaning over the years, but one fact remains: it is not a sensible goal to eliminate all Technical Debt, at least when you are truly trying to deliver software incrementally.

Wait… what?!

Fine, I’m being provocative for marketing purposes. Let me clarify:

I’m using the term “Technical Debt” as it is commonly understood these days: the accumulation of artifacts (code, documentation, …) that interferes with our ability to deliver the next valuable change.
Most projects would benefit from reducing Technical Debt.
Technical Debt tends to accumulate if we don’t train ourselves to attend to it.
Technical Debt is an unavoidable and normal consequence of delivering software incrementally.

A Problem

The confusion about Technical Debt typically comes from the apparent contradiction between “Technical Debt is unavoidable” and “We should reduce Technical Debt”. This happens when we act as Maximizers. Hilariously, some of this reflects the success of XP: “If this thing we do is good, then why not do it all the time?!” That’s the “X” in XP.

Even so, maximizing everything creates suffering. We often encounter tradeoffs, where two benefits oppose each other and so trying to maximize one hurts the other. We often fail to notice tradeoffs. We often disagree whether two forces are trading off or we can safely maximize one of them.

It’s Complex.

Why This Problem is a Problem

When we assume that we should maximize…

“Technical Debt is unavoidable” transforms into “There’s nothing we can do about Technical Debt” becomes “Our current level of Technical Debt is not only fine, not only expected, not only normal, but there’s nothing we can do about it, so let’s just ignore it.”
“You (almost certainly) should reduce Technical Debt” becomes “We need to relentlessly push for less Technical Debt” transforms into “We need to push for zero Technical Debt, and any goal less ambitious than that is a moral weakness and doomed to fail.”

I’ve exaggerated for effect, but not by as much as you think.

What Now?!

I claim that these two statements are true at the same time:

You almost certainly would profit from reducing Technical Debt.
You almost certainly would profit from embracing Technical Debt.

Technical Debt is the price you pay for delivering increments sooner. Eliminating Technical Debt would mean delaying the delivery of features.

Technical Debt compounds so we must agree to reduce it. Without that agreement and a strategy to reduce Technical Debt, the compounding effect would cause it to pile up until it overwhelmed our capacity. Letting Technical Debt grow uncontroled would mean delaying the delivery of new features.

Unfortunately, we don’t know how to measure “the right” amount of Technical Debt for you—at least not directly. As far as I can see, the best we can do involves looking for delays related to delivering features and diagnosing them as “cleaning up too much” or “not cleaning up enough”. We need to adjust our behavior continually. We can’t simply “set it and forget it”. Like I said, it’s Complex.

The (Bigger) Problem Behind “The Problem”

And we’ll probably disagree loudly about whether we’re not cleaning up enough or cleaning up too much. And different people will have different preferences about how much to clean up and when. And different people will have different needs, so optimizing for the individual would create even more conflict for the group. And Survivorship Bias guarantees that some people will assume that whatever they did in the past is the right strategy for this (other) group and this (other) project. And Confirmation Bias guarantees that some well-meaning, caring, opinionated folks will keep coming back to the group with article after article supporting their opinion. And it will probably never stop.

Resolve the Issue By Not Resolving It

This is yet another case where Best Practices thinking is likely to let you down. This is yet another case where there is no solution. If you want to deliver changes incrementally and sooner, then you will need to manage Technical Debt. Forever.

Don’t let it run wild and don’t resolve to eliminate it. Don’t squelch the arguments about it. Indeed, arguing about Technical Debt is the way forward. It’s how we continually adjust. It’s how we decide to clean up a little more here and a little less there. It’s how information flows about whether we’re doing enough or too much.

Of course, you probably prefer to argue more constructively and more harmoniously than you have the opportunity to do now. Your experience of trying to argue about this, whether with co-workers or random strangers on the internet, has likely felt more damaging than helpful. You’re probably afraid, maybe even terrified, of what would happen if you tried to argue openly and freely with your co-workers. It feels so much safer to retreat to Best Practices thinking or to give up on managing Technical Debt altogether. I understand.

Our collective struggle over Technical Debt seems much more to me to have been a clear signal of our collective trust deficit than a signal of our competence as software developers. I think we need to trust each other more to make any meaningful progress here.

What do we do about that? The answer fills bookshelves. One of my favorite places to start is Patrick Lencioni’s The Five Dysfunctions of a Team. If you have a favorite first resource on the topic of increasing trust, then share it with the world!

Making Use of 'Silly' Advice

Mon, 18 Dec 2023 12:08:00 -0400

What kind of “silly” advice? The kind that tells you never to do this or always to do that or you don’t need to do this or you need to do that. When I see someone giving advice like this, especially if they are a Big Consulting Company That Everyone Pays Attention To, I usually see a trail of frustrated comments nearby arguing about context and the like.

I used to be the person giving that kind of advice. I used to be the person annoyed by that advice. I’ve left a few frustrated comments over the years. I’m sorry about all that.

We can make use of that “obviously wrong” advice and skip the frustrated comments. I’d like to share how by starting with a common example: the structure of writing code-level tests and drawing attention to that structure in the code. A version of this that triggered my writing today was the suggestion to write comments such as these in your tests:

@Test unimportantExample() {
    // Arrange
    var subject = new SubjectUnderTest(collaborators...);
    
    // Act
    var result = subject.theActionToCheck(arguments...);
    
    // Assert
    assertEquals(expectedResult, result);
}

Every so often, an experienced TDD practitioner writes “You don’t need those comments”, when they often mean something more like “You don’t need those comments, just because some article somewhere called them a ‘best practice’. Try living without them for a while to give yourself a chance to decide. If you don’t need them, then stop writing them! See? Isn’t that nicer?!”

Quite often, after that, we have:

a handful of people saying “I do this and I like it, so shut up”.
a handful of people saying “Yeah, when I see this, I have to laugh. Stupid n00bs.”
at least one person yelling “CONTEXT!”

Yes, I understand. I’d like to rewind to the beginning and try again.

Writing Code-Level Tests: Some Advice

A code-level test has only two essential elements: an action and an assertion. Everything else is optional. We do something and describe what ought to happen when we do it; the computer checks the current behavior and yells when it’s surprised. That’s enough.

The 3 As (arrange, act, assert) and GWT (given, when, then) act as documentation: miniature checklists to help you remember what to do and headings to help others understand what you did. Making this clear in your code, such as by writing comments or extracting functions or using vertical whitespace, is entirely optional.

So, Should We or Shouldn’t We?

I don’t know. When I need to choose, I ask these questions:

How much does it cost to do?
How much does it cost to undo or remove?
Who would use it?
How would we (all) benefit?
Could I get (enough of) those benefits a cheaper way?
Would I be setting an unhelpful precedent or standard or habit by doing this? or a helpful one?

There are probably more, but these ones come to mind in the first minute of thinking about it.

These questions help me make use of advice in the form of “Do this” or “Don’t do that” or “You don’t need that” or “You need this”. Asking these questions allows me to skip the usual eye-rolling by digging for the genuine attempt to help that lies behind the crusty exterior of blaming.

So… Should We or Shouldn’t We?!

I don’t know how much it matters, but I’ll share my current habits related to writing code-level tests, just in case you find them instructive.

I call it “The 3 As”, because that’s how I learned the concept and “GWT” doesn’t make it any clearer for me. I’m old.

I use vertical whitespace to separate the action from the assertion and typically refactor my tests so that the assertion is always the last “paragraph” and the action is the second-last “paragraph”. Everything before it is preamble and you can think of it as “arrange”. The “arrange” part is sometimes a mess and that mess continually reminds me to keep trying to isolate the action further from its context.

I tend to refactor my tests so that the assertion is a single command. I do this for the design benefit: as I refactor towards a single command, that nudges me towards helpful Value structures or objects that combat Primitive Obsession.

I always prefer improving names to writing comments of any kind, and so when I write a comment, I do so due to time constraints or because the explanation needed goes well beyond the names of the surrounding bits of code. When I read a comment, I always spend a brief moment looking for a way to replace it with better names.

How Does That Feel?

When I encounter this kind of “silly” advice, I usually see the kernel of genuine help in there. With a little practice, I built the habit of looking for that kernel and bringing it out into the open where more people could see it. I feel significantly less frustration and annoyance that way.

I hope you do, too.

Giraffe Ears: An Example

Fri, 10 Nov 2023 11:32:00 -0400

I learned about “Giraffe Ears” and “Jackal Ears” from Marshall Rosenberg’s work in Nonviolent Communication. I’d like to share a practical example of “putting on your Giraffe Ears” with you, which I hope both illustrates the concept and helps you make use of it.

The Situation

You’re having a conversation with someone in which you’re trying to help them solve a problem they’ve described in their working environment. Maybe you’re discussing how to adopt some Lightweight practice or how an idea from Theory of Constraints might help them understand better what’s going on. They listen to your pitch and seem reasonably open to it, but at some point, they interrupt you and start to reply like this:

That sounds great in theory, J. B., but here in the real world….

A Problem

Not long ago, I would have certainly stopped listening, and I might even have interjected with a sarcastic response such as this:

Wait… (looks around) This all looks pretty real to me!

I found this satisfying at times, but I didn’t notice it being particularly helpful. I could justify my response by telling myself that I was making them aware of their unstated assumptions and confronting them in a way that help them to get out of their own way, but mostly I was making them angry and pouring fuel onto the fire. A peer whom I respect a great deal saw me do this repeatedly, pulled me aside, and told me that they thought I used sarcasm too much, and that perhaps I wasn’t aware that that made people less likely to enjoy working with me. (I, of course, had assumed that everyone found it charming.)

That got my attention. After thinking about that for a while, I realized that I wanted a strategy that both worked better and felt better, not only to me but to everyone else. It also seemed literally financially valuable to change my approach. Even though I already had the ingredients I needed in order to change my behavior, the light went on when I read about Nonviolent Communication. From a few books and videos I learned a new way to approach this scenario: putting on some Giraffe Ears.

A Solution

When I put on my Giraffe Ears, I look for the unspoken emotional content behind this slight insult—implying I live in some fantasy world—and engage with that, ignoring the hurtful, literal worlds they’ve spoken. I know that they don’t mean specifically to insult me in particular, but that when they refer to “the real world”, they mean the environments they currently live in often combined with the dysfunctional environments they routinely encounter or the many dysfunctional environments they’ve experienced in the past. When I interpret their message that way, I find it easier to do two things:

To remember to have compassion for their situation, partly by remembering what it felt like to me to have a job in a similarly dysfunctional environment. Not everyone has the opportunity to escape that the way I did.
To inquire about the obstacles they experience that stop them from doing what I’m describing and specifically to do that with genuine curiosity.

In my mind, when I hear “But here in the real world” I understand something more like this:

That sounds great, J. B., but if you knew more about the immovable obstacles that I have to deal with here every day…

Great! I can work with this. It turns out that:

I’ve experienced some of those obstacles.
Even for the obstacles I haven’t exactly experienced, I can offer some helpful strategies for overcoming or bypassing them.
Even for the obstacles that seem less likely to be moved out of the way, I can offer some helpful strategies for coping with them in a generally “healthier” way.

In many cases, I can suggest strategies that do at least two things:

Make the obstacles more movable and sometimes even disappear.
Help the other person have new/renewed feelings of agency, influence, or control over the situation.

If I see their apparent insult as a tragic expression of unmet meeds, then I can offer them something that’s likely to be in short supply: hope. The resulting discussions go much more smoothly and feel so much better. And sometimes we can even solve a few problems!

Some Optional Commentary

I don’t consider myself an “adherent” to Nonviolent Communication, although I like very much the notion of both attending to unmet needs and communicating those to other people. I mostly use its ideas as a practical approach to compassion, much in the same way that Dale Emery described when he wrote about Resistance As a Resource. Instead of viewing the other person’s resistance as a roadblock, let’s use it as a source of information about what they’re not (yet) willing to say to us. Nonviolent Communication encourages us to interpret resistance, particularly strongly-worded or very emotional resistance, as a tragic expression of unmet needs. This goes beyond merely showing compassion for the person to looking for the unmet meeds that lie behind the outburst. I much prefer this way of interacting with people in the world.

I also recognize this Giraffe Ears concept as an alternative way of describing what Jerry Weinberg called “The Law of Generous Interpretations”, which he taught alongside Virginia Satir’s “Ingredients of an Interaction”, also known as “The Satir Interaction Model”. I became interested Nonviolent Communication partly because it seemed at the time quite compatible with what I’d already learned from Virginia Satir through Jerry Weinberg. Even so, not everyone uses these powers for good.

I have encountered some people who use the teaching of Nonviolent Communication as an excuse to loudly and unreservedly articulate their unmet needs, no matter the context or circumstances. These are the same folks who would use Radical Candor as a licence to be assholes. I don’t want to do that. I don’t express all my unmet needs and let the chips fall where they may, but I find it easier and more constructive now to absorb another person’s unexpected outburst. I have found it very helpful both in regulating my own emotions and in earning other people’s trust. Something magical happens when a very frustrated acquaintance can’t hold back their feelings any longer, vents them in my direction, and I manage not to return fire.

One day I might even become quite good at it. I will be practising in the meantime.

Two Simple Tools for Handling Open Loops

Tue, 05 Sep 2023 08:29:00 -0300

I offer you a Quick Win today: using sleep and say to help you handle open loops more effectively and more peacefully.

What is an open loop again?

When I talk about an open loop, I mean a task that you need to pause doing for a while before resuming it. Common open loops include waiting for someone to reply to email, waiting for someone to approve your expense report, or waiting for your code to compile.

A Scenario

I am updating the server that I use to host The jbrains Experience Forum. I update it infrequently, so this always takes longer than I expect: a few reboots, upgrading the kernel, and so on. Invariably, waiting for reboots bores me, so I prefer to do something else (following the Two-Minute Rule, of course). If I merely switch tasks, however, I will focus on the new task, forget what I was doing in the old task, and invariably subject myself to unnecessary stress. There has to be a better way.

The Better Way

I reboot my Digital Ocean server. I need to log back in to that server when after it reboots. I make a guess about how long that could possibly take: 3 minutes. I type this:

$ sleep 180 && spd-say "Logging in to the server now" && ssh -A root@nunya.business.com

In English, this reads:

Wait 3 minutes, then announce “Logging in to the server now”, then log in to the server.

Now I can forget about this task for about 2 minutes and 58 seconds, focus on something else, then return to this when I’m ready. The announcement—as long as my speakers are on—will help me remember to get back to that task. It’s not perfect, but it works quite well for me.

Uh… Really?!

Really.

Even if you find this to be a bit much, this approach does what all reminders do: it lets me forget with confidence, so that I can focus. It gives me the option to get another task done or go take a walk to make coffee or zone out and rest for a few minutes. I can choose. This makes me happy.

And maybe it helps make you happy, too. Try it and let me know how it goes.