Most technical problems are people problems

Source: Hacker News

Background

I once worked at a company with an enormous amount of technical debt—millions of lines of code, no unit tests, built on frameworks that were well over a decade out of date. On one specific project we needed to run Windows‑only modules on Linux. Rather than cross‑compiling, another team simply copied and pasted a few hundred thousand lines of code, swapping Windows‑specific components for Linux‑specific ones.

For the non‑technical reader, this creates a huge problem: two versions of the code now exist, and every feature or bug fix must be applied to both codebases, which will diverge over time. When I heard about this, a young and naive version of me set out to fix the situation…

Tech‑debt projects are always a hard sell to management, because even if everything goes flawlessly, the code just does roughly what it did before. The optics weren’t great, but I ignored the politics, put my head down, and got it done. The project ran long, and I lost a lot of clout in the process.

I realized I was trying to solve a people problem with a technical solution. Most developers were happy doing the same thing they had done yesterday… and five years ago. As Andrew Harmel‑Law points out, code tends to follow the personalities of the people who wrote it. The code was calcified because the developers were also calcified; personality types that dislike change rarely design code with future change in mind.

Most technical problems are really people problems. Why does technical debt exist?

• Requirements weren’t properly clarified before work began.
• A salesperson promised an unrealistic deadline to a customer.
• A developer chose an outdated technology because it was comfortable.
• Management was too reactive and cancelled a project mid‑flight.
• Someone’s ego wouldn’t let them see a better way of doing things.

The core issue was that admitting the need for refactoring also meant admitting that the company’s software‑building process was broken and that individual skill sets were out of date. My small team tried to fix one module while other developers kept writing code the way they had for decades. One developer even told me, “I don’t want to learn anything new.” I realized that you’ll never clean up tech debt faster than others create it. It’s like triage in an emergency room: you must stop the bleeding first, then you can fix whatever is broken.

An Ideal World

The project also disabused me of the engineer’s ideal of a world where engineering problems can be solved in a vacuum—staying out of “politics” and letting the work speak for itself—a world where deadlines don’t exist…and let’s be honest, neither do customers. This ideal world rarely exists. The vast majority of projects have non‑technical stakeholders, and telling them “just trust me; we’re working on it” doesn’t cut it.

I realized that the perception that your team is getting a lot done is just as important as actually getting a lot done. Non‑technical people do not intuitively understand the level of effort required or the need for tech‑debt cleanup; it must be communicated effectively by engineering—in both initial estimates and project updates. Unless leadership has an engineering background, the value of the technical‑debt work likely needs to be quantified and shown as business value.

Heads Up

Perhaps these are the lessons that prep one for more senior positions. In my opinion, anyone above senior‑engineer level needs to know how to collaborate cross‑functionally, regardless of whether they choose a technical or management track. Schools teach Computer Science, not navigating personalities, egos, and personal blind spots.

I have worked with some incredible engineers—better than myself—the type that have deep technical knowledge on just about any technology you bring up. When I was younger, I wanted to be that engineer—the “engineer’s engineer.” But I realize now that is not my personality. I’m too ADD for that.

For all of their (considerable) strengths, more often than not, those engineers shy away from the interpersonal side. The tragedy is that they are incredibly productive ICs, but may fail with bigger initiatives because they are only one person—a single processor core can only go so fast. Perhaps equally valuable is the “heads‑up coder”—the person who is deeply technical and able to pick their head up, see project risks coming (technical and otherwise), and steer the team around them.