<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>The jbrains Blog</title><description>Writings by J. B. Rainsberger on professional software development, leadership, and personal growth.</description><link>https://blog.jbrains.ca/</link><language>en-ca</language><item><title>The Fundamental Irony of Human Interaction</title><link>https://blog.jbrains.ca/permalink/the-fundamental-irony-of-human-interaction/</link><guid isPermaLink="true">https://blog.jbrains.ca/permalink/the-fundamental-irony-of-human-interaction/</guid><description>When interactions &quot;go wrong&quot;, the very thing you are most likely to complain about and try to change is the very thing that most people find hardest and most painful to change about themselves. Result? Merry chaos. I propose an alternative that might actually work.
</description><pubDate>Tue, 05 May 2026 00:00:00 GMT</pubDate><category>Personal Growth</category><category>Free Your Mind to Do Great Work</category><category>Debugging Human Interactions</category><category>Playing Well With Others</category></item><item><title>Playing Well With Others: An Example</title><link>https://blog.jbrains.ca/permalink/playing-well-with-others-an-example/</link><guid isPermaLink="true">https://blog.jbrains.ca/permalink/playing-well-with-others-an-example/</guid><description>LinkedIn is full of strong opinions, weakly articulated. You don&apos;t have to succumb to the temptation of yelling back about how wrong people are. You can break the cycle. Here is an example of how to do exactly that.
</description><pubDate>Wed, 15 Apr 2026 00:00:00 GMT</pubDate><category>Personal Growth</category><category>Playing Well With Others</category><category>The Selfish Team Player</category><category>Psychological Safety</category><category>Powerful Questions</category></item><item><title>When You Can Safely Leave Sprints Behind</title><link>https://blog.jbrains.ca/permalink/when-you-can-safely-leave-sprints-behind/</link><guid isPermaLink="true">https://blog.jbrains.ca/permalink/when-you-can-safely-leave-sprints-behind/</guid><description>You need iterations/sprints long enough to build certain helpful habits, but once you&apos;ve built those, you might safely leave iterations/sprints behind. This doesn&apos;t make them dumb nor wasteful, but that seems to be how many people frame the matter, so I have to use the word for SEO.
</description><pubDate>Mon, 13 Apr 2026 00:00:00 GMT</pubDate><category>Professional Software Development</category><category>Unquestionably Agile</category></item><item><title>Your Inbox As Options, Not Obligations</title><link>https://blog.jbrains.ca/permalink/your-inbox-as-options-not-obligations/</link><guid isPermaLink="true">https://blog.jbrains.ca/permalink/your-inbox-as-options-not-obligations/</guid><description>&quot;I can&apos;t use to-do lists, because when I write things down, I see how much there is to do, then I shut down and go back to bed. It feels awful! I hate it.&quot; The struggle is real, but I propose a way out: a way to have the benefits of the to-do list without the crushing anxiety and constant reminders that you&apos;re disappointing everyone, especially yourself.
</description><pubDate>Mon, 23 Mar 2026 00:00:00 GMT</pubDate><category>Personal Growth</category><category>Psychological Safety</category><category>Free Your Mind to Do Great Work</category><category>Getting Things Done</category></item><item><title>A Tale of map and parseInt in Three Acts, or WAT You Will</title><link>https://blog.jbrains.ca/permalink/a-tale-of-map-and-parseint-in-three-acts/</link><guid isPermaLink="true">https://blog.jbrains.ca/permalink/a-tale-of-map-and-parseint-in-three-acts/</guid><description>Why can&apos;t you map parseInt in TypeScript? Because fuck you, that&apos;s why!
</description><pubDate>Thu, 19 Mar 2026 00:00:00 GMT</pubDate><category>The Code Whisperer</category><category>Microtechniques</category></item><item><title>Deadlines As An Act Of Love</title><link>https://blog.jbrains.ca/permalink/deadlines-as-an-act-of-love/</link><guid isPermaLink="true">https://blog.jbrains.ca/permalink/deadlines-as-an-act-of-love/</guid><description>You are probably used to interpreting deadlines as a control mechanism, especially since that&apos;s how it seems to be in software development. Imagine seeing deadlines as an act of love! No, really! I believe we can make this happen together.
</description><pubDate>Fri, 20 Feb 2026 00:00:00 GMT</pubDate><category>Personal Growth</category><category>Psychological Safety</category><category>Free Your Mind to Do Great Work</category><category>The Selfish Team Player</category><category>Getting Things Done</category></item><item><title>Adopting Tricky Design Concepts Safely</title><link>https://blog.jbrains.ca/permalink/adopting-tricky-design-concepts-safely/</link><guid isPermaLink="true">https://blog.jbrains.ca/permalink/adopting-tricky-design-concepts-safely/</guid><description>Technical leaders often struggle to introduce &quot;tricky&quot; design concepts into their code bases, because the other programmers don&apos;t seem ready for them. Focus on refactoring paths over applying the pattern &quot;correctly&quot; and universally to avoid having to choose between chaos and stagnation.
</description><pubDate>Thu, 15 Jan 2026 00:00:00 GMT</pubDate><category>Professional Software Development</category><category>Unquestionably Agile</category><category>Software Design</category><category>Psychological Safety</category><category>Technical Leadership</category><category>The Selfish Team Player</category></item><item><title>A Central Conflict in &apos;Readable&apos; Code</title><link>https://blog.jbrains.ca/permalink/a-central-conflict-in-readable-code/</link><guid isPermaLink="true">https://blog.jbrains.ca/permalink/a-central-conflict-in-readable-code/</guid><description>Programmers routinely complain about code being &quot;unreadable&quot;. They also routinely argue, sometimes quite heatedly, about how to make code &quot;more readable&quot;. I have noticed a conflict that they might be missing which could help moderate those arguments and make them more constructive.
</description><pubDate>Thu, 04 Dec 2025 00:00:00 GMT</pubDate><category>Professional Software Development</category><category>Simple Design</category><category>Unquestionably Agile</category><category>Software Design</category></item><item><title>In the Age of Generative AI, Better Design Remains Up to Us</title><link>https://blog.jbrains.ca/permalink/in-the-age-of-gen-ai-better-design-remains-up-to-us/</link><guid isPermaLink="true">https://blog.jbrains.ca/permalink/in-the-age-of-gen-ai-better-design-remains-up-to-us/</guid><description>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 &quot;better&quot; 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.
</description><pubDate>Mon, 01 Dec 2025 00:00:00 GMT</pubDate><category>Professional Software Development</category><category>Free Your Mind to Do Great Work</category><category>Software Design</category></item><item><title>Blue Tape and Inbox Technique</title><link>https://blog.jbrains.ca/permalink/blue-tape-and-inbox-technique/</link><guid isPermaLink="true">https://blog.jbrains.ca/permalink/blue-tape-and-inbox-technique/</guid><description>Many people struggle to apply the ideas in Getting Things Done, partly because those ideas seem like abstract &quot;good things to do&quot;, rather than as simple, practical solutions to immediate problems. Michael Lopp&apos;s metaphor of &quot;Blue Tape&quot; 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&apos;re doing it, but nothing&apos;s really happening.
</description><pubDate>Thu, 20 Nov 2025 00:00:00 GMT</pubDate><category>Personal Growth</category><category>Free Your Mind to Do Great Work</category><category>Getting Things Done</category></item><item><title>Clarifying the Rule of Three in Refactoring</title><link>https://blog.jbrains.ca/permalink/clarifying-the-rule-of-three-in-refactoring/</link><guid isPermaLink="true">https://blog.jbrains.ca/permalink/clarifying-the-rule-of-three-in-refactoring/</guid><description>Rules can cause confusion, because we try too hard to follow them. The Rule of Three, a classic &quot;rule&quot; of refactoring, carries this risk. How do we reap the benefits while avoiding the drawbacks?
</description><pubDate>Fri, 07 Nov 2025 00:00:00 GMT</pubDate><category>The Code Whisperer</category><category>Simple Design</category><category>Evolutionary Design</category><category>Microtechniques</category><category>Refactoring</category><category>Removing Duplication Deftly</category></item><item><title>Going Further with One Outcome Per Test</title><link>https://blog.jbrains.ca/permalink/going-further-with-one-outcome-per-test/</link><guid isPermaLink="true">https://blog.jbrains.ca/permalink/going-further-with-one-outcome-per-test/</guid><description>When we limit ourselves to one outcome per test, we exert helpful pressure on our design that sometimes results in simpler code that is easier to test. We have more confidence in it. I use someone else&apos;s article and example to illustrate what can happen. And no, you don&apos;t need to be a Wizard to do this.
</description><pubDate>Sun, 19 Oct 2025 00:00:00 GMT</pubDate><category>The Code Whisperer</category><category>Simple Design</category><category>Evolutionary Design</category><category>Microtechniques</category><category>Refactoring</category></item><item><title>An Alternative Formulation of Getting Things Done</title><link>https://blog.jbrains.ca/permalink/an-alternative-formulation-of-getting-things-done/</link><guid isPermaLink="true">https://blog.jbrains.ca/permalink/an-alternative-formulation-of-getting-things-done/</guid><description>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.
</description><pubDate>Mon, 30 Dec 2024 00:00:00 GMT</pubDate><category>Personal Growth</category><category>Free Your Mind to Do Great Work</category><category>Psychological Safety</category><category>Getting Things Done</category><category>The Selfish Team Player</category></item></channel></rss>