The jbrains Blog

Some folks insist on using Word. I know. I like to put assets in git and be able to read diffs. Can't we all get along? Yes. Yes, we can.

Getting Things Done calls them open loops: unresolved tasks where you're blocked because you are waiting for someone else. Open Loops are a common source of significant, painful stress and worry. Fortunately, the advice in GTD trains us not only to manage these Open Loops, but also to feel downright placid, even when we're waiting for others, and even when they might be a bit unreliable.

Sometimes, to find a feature, you first have to consult a thesaurus. Or maybe you get lucky. Or maybe you stop clinging to the search terms you're using and simply stumble upon the feature with a name (and a UI) that you weren't expecting.

When interactions "go wrong", 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.

LinkedIn is full of strong opinions, weakly articulated. You don'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.

You need iterations/sprints long enough to build certain helpful habits, but once you've built those, you might safely leave iterations/sprints behind. This doesn'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.

"I can'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." 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're disappointing everyone, especially yourself.

Why can't you map parseInt in TypeScript? Because fuck you, that's why!

You are probably used to interpreting deadlines as a control mechanism, especially since that'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.

Technical leaders often struggle to introduce "tricky" design concepts into their code bases, because the other programmers don't seem ready for them. Focus on refactoring paths over applying the pattern "correctly" and universally to avoid having to choose between chaos and stagnation.

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.

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.

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.

Rules can cause confusion, because we try too hard to follow them. The Rule of Three, a classic "rule" of refactoring, carries this risk. How do we reap the benefits while avoiding the drawbacks?

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's article and example to illustrate what can happen. And no, you don't need to be a Wizard to do this.

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.