The 'soft' skills were the hard part all along

Early on I thought the job was the code. You get good at the language, you learn the framework, you memorize enough of the standard library that you stop reaching for the docs, and the rest is just... talking, which anyone can do. "Soft skills" even sounds optional — the squishy stuff you pick up on the side while doing the real work.

A few years in, I think that framing is backwards. The code was the part that had clear right answers. The hard, unsolved, career-shaping problems all turned out to live in the spaces between people. Nobody calls them "hard skills," but they're the ones I'm still actively bad at, and the ones that most decide whether a project goes well.

The expensive kind of "it works"

Here's the thing that reframed it for me. I can write a function that works and still cost my team a week. If the PR has no description, if the variable names only make sense inside my own head, if I solved a problem nobody had while the actual one sat there — the code compiles and the outcome is bad anyway. The compiler doesn't grade any of that. A reviewer at 6pm does, and they grade it harshly, because they're tired and I made them do archaeology.

So the "soft" skill of writing a PR description that explains why, not just what is doing more real engineering work than the diff underneath it. It's the difference between a change that gets merged and one that generates three rounds of "wait, why did you...".

Disagreeing without it turning into a thing

Code review is where I learned that being right is maybe 30% of the job. The other 70% is being right in a way the other person can actually accept.

There's a version of me that leaves the comment "this is wrong, use a map" and technically I've done my duty. And there's a version that writes "I think a map might read cleaner here — this loop is O(n²) once the list grows; what do you think?" Same information. Wildly different outcome. The first one makes someone defensive and the code doesn't even get better, because now they're arguing to win. The second one gets the fix and keeps the person willing to review my stuff next week.

That's not politeness for its own sake. It's the recognition that I have to keep working with this person for years, and every interaction is either building or spending trust. The curt-but-correct comment spends. It feels efficient and it isn't.

"I don't know" is a senior sentence

The single hardest sentence to say when I was junior was "I don't know." It felt like admitting I didn't deserve to be there. So I'd nod, go back to my desk, and quietly burn two hours reconstructing what I could have just asked about.

Watching people I respect, I noticed they said it constantly — "I don't know, let's find out," "I'm not sure that's right, walk me through it." It wasn't weakness. It was the thing that let the whole group stop pretending and actually get somewhere. Confidence isn't knowing everything; it's being comfortable enough to say where the edge of your knowledge is. That one took me years.

Estimates are a communication problem wearing a math costume

"How long will this take?" looks like a technical question. It almost never is. The honest answer is a distribution, not a number, and the skill is translating that into something a non-engineer can plan around without either lying or drowning them in caveats.

"Two days if the API is what the docs say, a week if it isn't, and I'll know which by tomorrow afternoon" is a better answer than any single number — and delivering it well is pure communication. The engineering was the easy half.

Knowing when to stop

The last one, and maybe the sneakiest: taste about when something is done enough. I can always make the code prettier, add another abstraction, handle one more edge case that will never happen. Gold-plating feels like craftsmanship and diligence. Often it's just fear of shipping dressed up as quality.

Deciding "this is good, the rest is polish nobody asked for, ship it" is a judgment call that no test suite makes for you. It requires understanding what actually matters to the people using the thing — which is, again, a people skill in a hoodie.

---

None of this means the technical craft doesn't matter. You have to be able to build the thing. But I've watched brilliant engineers stall and steady communicators thrive, and the gap was never who knew more about the language. The code was the part with a right answer. Everything around it — the naming, the disagreeing, the not-knowing, the estimating, the stopping — is where the actual difficulty lives. Calling it "soft" was the biggest misdirection of my early career.