But there are times when it's a valid explanation of the current situation people find themselves in.
When you get questioned about "why isn't this done yet? $previousDevX said it would only take a day!"
... what words/phrasing can you use that don't - implicitly or explicitly - 'blame' your predecessor in some fashion?
And as @ervine pointed out, there may be times when I'm the predecessor, but was hamstrung by time deadlines earlier and now have far more debt to unravel than existed 6 months earlier. But even then... while I am the predecessor, someone else made the decision to cut my effort short earlier, and we all still live with that decision now.
It’s true, but kind of a non-sequiteur. The post isn’t about getting blocked in general, it’s about the internal reasons/ways that individuals tend to get stuck on their own.
Furthermore, if the story you tell yourself is “I’m great, the main thing that I get stuck on is when others mess up and I need to fix it”, then even if that is in fact true, you miss an opportunity for acquiring self-knowledge by investigating the patterns of self-inflicted stuckness.
Put differently, maybe the mistakes of others are outside your control, but your own weak spots (everybody has them, it’s fine) are within your control to improve upon. And one of the more important jobs of a good manager is to use the 30k ft view to help individuals to spot and work on improving these patterns.
Data structures being badly designed is a perfectly valid and common blocker. That is why we try to design things correctly, after all - to avoid blocking future engineers when they try to change the system. Badly designed data structures can make a system impossible to extend. Regardless of who is to blame, we need to call such things out so that people actually pay attention to data design in the future, and avoid things that are extremely costly but necessary to fix. So I'd say it is productive to point it out.
