[Aqueous]

When I've gotten stuck it's usually because the previous engineer completely screwed up the data structure design and in doing so made it impossible to change. This boxes me in because I can't implement the feature in an architecturally sound way without a significant refactor.

This has happened to me many times.

[cecilpl2]

Please take this the right way, but blaming your predecessors is not a productive mindset, nor is it really the topic of this post.

[mgkimsal]

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.

[theptip]

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.

[ervine]

Eh, sometimes the predecessor is me, the fact that a large refactor remains between me and the end goal is still a blocker.

[Aqueous]

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.

[ska]

[narrator] The previous engineer was themself, 18 months ago.

I turns out that usually (not universally!) the problem isn't that the previous person did a bad job, but rather that they made a set of tradeoffs that made sense at the time, and make less sense now.

Or it could be that you work with uncharacteristically incompetent engineers, but that's not the first place to look.

[Aqueous]

It was, in fact, not me.

And the tradeoffs did not make sense. This was a simple case of bad normalization - a missed many to one relationship. It just so happens that it happened to be a relationship at the center of a very large platform, and is baked through many services. And without fixing it early-ish, we'd be fighting the schema for the next 10 - 20 years and creating unmanageable complexity in the process, all the while making it harder for ourselves to eventually fix it.

So I'm just pointing out something factual. Sometimes making sure something doesn't happen again means calling a spade a spade. If that means pointing out a mistake, then we absolutely should.

[ska]

I wasn't really suggesting you were. I was pointing out that your described situation is actually pretty rare. Your opening " ... it's usually ..." suggested the anecdote you offered generalized easily, but that isn't true.

[Trasmatta]

Oh God this is where I'm at now. A series of questionable decisions over the past 7 years have now solidified our codebase into a horrible set of patterns that make even adding a single new database column that we need to feed to the frontend a Herculean task. It's so demotivating.

[pacaro]

This is where the fun begins for some of us. Coming in to a codebase that has been growth focused for 10 years but now needs to be rock solid and yet also allow the next 10 years growth.

[Trasmatta]

It would be fun if that's what I was tasked with doing, but instead I'm doing feature development, and being asked why this small simple things are taking so long...

[pacaro]

Yeah, and that sucks for sure. And it's a measure of management quality as to how they incorporate your feedback on this

[Trasmatta]

Yeah definitely. I've been giving feedback about this for around 2 years and there's some movement, but there doesn't seem to be anyone at the company driving architectural decisions, so nothing really seems to be going anywhere.

[icedchai]

I've been hearing these sorts of complaints since I started working. Bob leaves, immediately people need to rewrite Bob's code because it sucks. The truth is often that the other person doesn't fully understand it. Writing code is easy, reading code is hard.

There is almost always a way to work around something. "Architecturally sound" is in the eyes of the beholder, and unless you're building the next Google, a sub-optimal solution may be perfectly fine. That's what we're paid the big bucks for: to develop a solution, one that works "good enough", without having to constantly rewrite... sorry, "refactor"... the entire project.

This isn't always the case though. Sometimes the code really does suck!

[CamouflagedKiwi]

It may well be that you're entirely correct, and this is what's happened. But another dev out there might say the same thing in a different situation, and the answer could be that they've gotten stuck refactoring other people's code that didn't need to be.