Junior Developers Overestimate Code and Underestimate Communication. Here's Why That's Backwards.

Ask a junior developer what they're working on improving, and the answer is almost always technical. A new framework, a harder algorithm, a language they haven't used yet. That instinct makes sense, code is the visible, measurable output of the job, and it's what most tutorials, courses, and interview prep are built around.

It's also the skill that improves fastest with least deliberate effort, because writing code every day is unavoidable. You can't avoid practicing it even if you tried.

Almost nobody deliberately practices explaining a technical decision to a non-technical stakeholder, writing a pull request description that lets a reviewer understand the change without reading every line, or asking a question that gets a useful answer instead of a vague one. These aren't things that improve automatically just by doing the job. Someone can write correct, clean code for years while still explaining decisions poorly, and the code alone won't fix that.

The result is a strange gap: developers who are technically strong but consistently the last to hear about decisions, the ones whose pull requests take longest to review because reviewers can't tell what changed or why, the ones passed over for a promotion despite writing better code than the person who got it.

Promotion decisions are rarely made by someone reading your code line by line. They're made based on what a manager and peers already believe about your judgment, and that belief is built almost entirely through communication, the clarity of your updates, how well you explain trade-offs in a design discussion, whether people trust your summary of a problem without double-checking it themselves.

A developer who writes good code and explains it well gets trusted with harder, more ambiguous problems, the kind that actually lead to growth. A developer who writes equally good code but explains it poorly gets handed clearly-specified tickets instead, because handing them something ambiguous requires trusting their judgment, and that trust is built through communication, not commits.

Treat your next pull request description as a skill exercise, not an afterthought, write it so a reviewer who wasn't in your head for the last three hours can understand what changed and why in thirty seconds. Treat your next status update as practice explaining trade-offs simply, not just listing what you did.

Code quality gets you taken seriously as a developer. Communication is what gets you trusted with harder problems, and harder problems are what growth actually looks like once the basics are solid.