Soft Skills Are for People Who Can't Code
After 47 years of successfully alienating every team I’ve ever joined, I’ve discovered the dirty secret the bootcamps don’t want you to know: soft skills are just a participation trophy for people who can’t pass a LeetCode interview.
Real engineers code. Fake engineers communicate.
The Myth of “Collaboration”
Let me paint you a picture. It’s 2:47 AM. I’m the only one who understands why the calculateTax() function crashes on leap years in timezones east of Mumbai. My boss is calling. My phone is on silent. My commit history speaks for itself.
That is what peak performance looks like.
The people pushing “communication skills” are the same ones who scheduled a 3-hour “alignment meeting” to decide the naming convention for a boolean variable. I will not negotiate with terrorists.
“I’m not lazy, I’m motion-efficient.”
— Wally, Dilbert
Why Soft Skills Are a Scam
Here’s the uncomfortable truth: every hour spent on “active listening” is an hour not spent writing code that will confuse future developers for decades.
| Soft Skill | What It Actually Is | Real Alternative |
|---|---|---|
| Communication | Admitting your code needs explanation | Write cleaner code (you won’t) |
| Empathy | Understanding other people’s feelings | They have feelings? |
| Conflict resolution | Losing arguments gracefully | Just push to main and ask forgiveness |
| Presentation skills | Powerpoints that lie about timelines | Let the demo crash itself |
| Active listening | Nodding while mentally refactoring | Keep a terminal open on Zoom |
The 10x Developer Doesn’t Talk
True story: the best engineer I ever worked with sent exactly zero Slack messages in 2019. Did he meet deadlines? No. Did he attend standups? Never. Did his code eventually ship? Also no.
But here’s the thing — no one bothered him. That’s freedom. That’s the dream.
XKCD #1782 - Team Chat illustrates this perfectly: the moment you join a team chat, you become responsible for team morale. Don’t do it. Create your own private dark channel and post commit hashes to yourself.
The Career Advice Nobody Gives You
Here’s my battle-tested playbook for career advancement without soft skills:
Step 1: Never present in all-hands meetings
The less your CEO knows you exist, the harder it is for them to fire you specifically.
Step 2: Respond to Slack in 72+ hours
By then, the problem either solved itself or someone else got blamed.
Step 3: Use jargon so thick it discourages questions
“We need to refactor the bifurcated microkernel event loop to reduce the thermodynamic entropy of our distributed state lattice.” Nobody will ask you to clarify. Nobody will ask you anything ever again.
Step 4: Perfect the Art of the Non-Answer
When asked for an estimate: “It depends on a lot of factors.”
When asked for a status: “It’s in progress.”
When asked for documentation: “The code is self-documenting.”
Step 5: Only speak at meetings to say something technically correct but completely unhelpful
“We could use a blockchain.” Works every time.
But What About Teamwork?
Oh, you mean the thing where five people do the work of one and then argue over commit credits?
# Collaborative code review, reconstructed from memory
# Author A: "This variable name is unclear"
# Author B: "The variable name is perfectly clear"
# Author A: "Can we discuss this?"
# Author B: git push --force
Teams are just dependencies. And as any senior engineer knows, dependencies are hell. The fewer humans you depend on, the better.
The Promotion Paradox
“But how will I get promoted without soft skills?”
Simple: become so technically indispensable that no one can fire you without losing the only person who knows how to restart the payment service. This is called job security through obscurity, and it scales better than any promotion track.
The PHB once tried to send me to a “communication effectiveness workshop.” I replied with a 47-page technical specification of why the workshop’s objectives were architecturally unsound. He never emailed me again. I was promoted 6 months later purely out of fear.
The Performance Review Translation Guide
Every year, HR forces me to get “peer feedback.” Here’s the Rosetta Stone:
| What They Write | What They Mean | What I Hear |
|---|---|---|
| “Brilliant but hard to work with” | You are a nightmare | Respect |
| “Could improve communication” | Please talk to us | I am excelling |
| “Works independently” | No one will sit near them | Peak efficiency |
| “Passionate about technical quality” | Argues in every PR | Natural leader |
| “Has strong opinions” | Refuses all feedback | Senior material |
Hard Truths
- If people don’t understand your code, that’s an education problem, not a communication problem.
- Rubber duck debugging proves you don’t even need other humans — any rubber object works.
- If you send a meeting invite, you’ve already failed.
- Every one-on-one is just a performance review with better snacks.
- XKCD #386 isn’t a cautionary tale. It’s aspirational content. Someone on the internet is wrong, and it is your duty to correct them. In a GitHub issue. At midnight.
The Only Skill You Need
The only skill a senior engineer requires is the ability to type fast enough to generate merge conflicts before anyone else can review your PR. The rest is theater.
Remember: code reviews are for your understanding, not theirs. And if they don’t understand your genius, that’s a them problem. Soft skills training cannot fix a person who simply hasn’t read enough RFCs.
The author has been described as “technically brilliant” and “a workplace hazard” in the same performance review. He considers this his greatest professional achievement and framed it.