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