Articles on leadership, personal growth, and professional software development.
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.
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.
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.