Hacker News Reader

Comment by tunesmith | Hacker News Reader

In my experience, diagnosing the tech-debt problem, prescribing the solution, and implementing the solution are not really the hard parts of this - the hard part is battling the culture that led to the problem, and wrangling that huge gulf between "seeming consensus" and "actual consensus" that the group is actually going to change direction by accepting the diagnosis, adopting the solution, and starting work.

Maybe an outside consultancy makes this easier since they are sort of imbued with a moral authority when coming in, but it could also mean that all the hard political work has been done beforehand in agreeing to hire them.

View on HN

I agree. Very often I see this set forth as a problem with management, but it seems to me that other engineers are also a significant part of the problem. I try really, really hard to never be that engineer. If someone sees defects in something I wrote, regardless of the scope, I'm totally fine with whatever they do to make it better, up to and including totally replacing my work.

It's the whole system that forms the basis for the problem: management, engineers, PMs, Designers, everyone who touches the problem space. If you want to improve, you need to make sure each part of the system is aligned around the same goal. Sounds hokey, but it is the reality.

That means, as well, that it's both your responsibility and others' responsibility at the same time. Sure, you shouldn't be "that engineer," but you should also realize the kinds of things in the system that make someone become "that engineer," or lead them to be "that engineer" in some situations, or on the positive end, how certain engineers avoid it altogether. Then try to reproduce those factors and spread them.

The problem is never individual. It's never about a good coder or a bad coder or anything like that. There are always multiple internal and external factors.

That's a very insightful observation. Over my career, I would find myself doing the hard work to advocate for improving code and developer practices, and I would often encounter resistance from management. By becoming starting a consultancy and narrowing the work that we do to just that kind of improvement, we're able to ensure that only the organizations that are at least somewhat open to the idea are the ones who approach us for help. Fighting that battle internally is a tough job.

Reply on news.ycombinator.com