Nobody tells you this at university: writing clean code is only half the job. The other half? Explaining to Janez from product why his "quick feature" will take two weeks and require touching three different services.
We love the stereotype of developers as introverted code wizards who live in their IDEs and communicate exclusively through Slack emojis and passive-aggressive code comments. And sure, sometimes I'd rather debug a segfault than attend another meeting. But you can't build software alone. Not the kind people actually use, anyway.
I'm somewhere in that weird limbo between junior and senior - not green enough to ask "what's a promise?" but not experienced enough to confidently say "we should rewrite the entire backend in Rust." From there I've noticed something: the developers who level up aren't always the ones with the best algorithms knowledge. They're the ones who can actually explain what they're doing and why.
The junior trap
I've watched genuinely talented junior developers stay stuck at that level for years. They can build impressive side projects, solve hard LeetCode problems, know React hooks inside and out. But they can't get promoted. Why?
They don't know how to ask for help. They'll drop "hey my code doesn't work" in Slack with zero context. Or worse, they'll silently struggle for three days on something a senior could've solved in an hour if they'd just asked properly.
In code reviews, they can't defend their choices. When someone asks "why'd you do it this way?" they get defensive or say "idk, seemed fine?" If you can't explain your reasoning, how do you expect people to trust your code?
I've been there. I thought admitting I didn't understand something made me look stupid. Turns out staying quiet and producing garbage made me look way worse.
Meetings matter more than you think
You're in sprint planning. Product manager says they want to add "just a simple filter feature." You know this "simple" feature means refactoring how we handle queries, updating three APIs, and probably breaking something in the process.
Junior dev either stays quiet or mumbles "might be tricky." Then spends the next two weeks drowning while everyone wonders why such a "simple" feature is taking so long.
Meanwhile, someone who can actually communicate is explaining the database implications, estimating realistic timelines, maybe even suggesting an alternative approach that gets them 80% of what they want in 20% of the time.
Or take post-mortems after production goes down. I've sat in too many meetings where someone clearly knows what happened but can't explain it. They're nervous, they're too technical, and people slowly stop listening. Half the room is on their phones because the explanation is going nowhere.
Daily standups are the worst for this. Someone takes five minutes trying to explain what ticket they're working on while the scrum master desperately scrolls through Jira trying to figure out what they're even talking about. Everyone else zones out. It's painful because you can tell they know what they're doing - they just can't put it into words.
Saying "I don't know" without sounding clueless
Juniors hate admitting they don't know something. I get it - I was the same way. You think it makes you look incompetent.
But there's a massive difference between:
"I don't know"
and
"I haven't worked with that pattern before, but it sounds similar to how we handle notifications? Could you point me to some docs?"
The second one shows you're trying. You're connecting dots. You're not just shrugging and waiting for someone to spoonfeed you the answer. That's what makes seniors actually want to help you instead of just doing it themselves.
Documentation (yes, really)
Good docs are rare because writing them forces you to actually understand what you built. You have to think about who's reading this, what they need to know, and how to explain it without assuming they have your context.
I'm not talking about Swagger docs that your IDE auto-generates and nobody ever looks at. I mean actual useful documentation that explains why this service exists, how it fits with everything else, and what weird edge cases future-you will forget about in six months.
If you can write docs that don't make people want to quit their job, you're already ahead of 90% of developers.
The language thing nobody talks about
If English isn't your first language, tech is brutal. You're trying to explain complex technical problems while translating in your head. It sucks.
I've worked with brilliant developers who knew exactly what was wrong and how to fix it, but they'd hesitate in meetings because they weren't sure if "concurrent" or "parallel" was the right word. Or they'd avoid writing detailed PR descriptions because they were self-conscious about grammar.
Honestly? Nobody cares if you say "the API breaks when too many requests come same time" instead of using perfect grammar. We just want to understand the problem. The developers who worry most about their English are often the ones with the best technical insights.
Confidence matters more than perfect grammar. Your ideas are valuable even if they come out a bit rough.
Talking to non-developers (the real skill)
This is the skill that decides how replaceable you are.
Can you explain to product why their feature needs database migrations without losing them after two sentences? Can you tell a designer why their beautiful mockup will kill page load times? Can you translate "users want faster checkout" into actual technical tasks?
Most developers can talk to other developers fine. We all speak the same language of frameworks and patterns and tech debt. But translating between tech and business? That's rare. And companies will fight to keep people who can do it.
Conway's Law (aka your code is as messy as your meetings)
There's this principle called Conway's Law that basically says: your code will look like your org chart. If teams don't talk to each other, you get systems that don't talk to each other.
I've seen this play out so many times. Teams with terrible communication build systems with unclear APIs, confusing data flows, components that seem to actively hate each other. Teams that communicate well build clean, integrated systems that just make sense.
The scary part? This happens whether you realize it or not. Your team's dysfunction is getting baked into your codebase right now.
How to actually get better at this
Practical stuff that helped me: explain your work to someone non-technical, a friend, a family member, whoever. If they get it, you're improving. Write PR descriptions that explain why, not just what changed, including the approaches you considered and rejected. Ask questions with context: "this doesn't work" is useless, but "I expected X when I did Y, got Z, and already tried A and B" gets you help fast. In code reviews, don't just click approve. Ask things, suggest things.
And write docs. Seriously. It's great practice and everyone will love you.
Oh, and speak up in meetings, even if it's just to ask questions. Your perspective matters, even as a junior.
The real difference
What separates developers who stay junior from the ones who become tech leads usually isn't technical chops. It's whether they can communicate ideas clearly, work with different types of people, and help others understand complex stuff.
Best part? Unlike learning a new framework, communication skills work everywhere. Every company, every tech stack, every team.
So next time you're about to push code and hope for the best, take a minute to think about how you can communicate your intentions better. Your future self will thank you. Your teammates definitely will.
Anyway. I have a meeting in ten minutes where I'll try to convince my team to let me rewrite our entire frontend. Wish me luck.