The jbrains Blog

Who's to blame for the reader not getting the message that the writer intended? Did the writer fail to be clear? Did the reader fail to engage with the message? What if I told you that no one is to blame?

The subtitle of the book Getting Things Done is "the art of stress-free productivity". Given our collective aversion to "grindset", it might be worth remembering that the real power of GTD lies in the "stress-free" part and not the "productivity" part.

If you frequently find yourself wondering how the day slipped through your fingers, then you need the Two-Minute Rule.

Most people exhaust themselves trying to carry too much information in their working memory. Instead, use Inbox Technique as one of the starting points to working more effectively and with more ease.

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.

The old joke says that computer programmers are very good at figuring out what needs to be done, but pretty bad at figuring out what might need to be done. They are routinely attacked by unplanned, unexpected work. If they try to keep all this in their head, then they're in for a bad time. Instead, they benefit from Inbox Technique, which is simpler than it sounds. (If it sounded too simple, then consultants couldn't charge money to teach it to you!)

If you frequently find yourself wondering how the day slipped through your fingers, then you need the Two-Minute Rule.