Skip to main contenthomeblog
back to blog

communication skills: the thing they dont teach you in coding bootcamps

14 nov 2025, 19:16 utc+8·6 min read
share:

the skill nobody told me i needed

so here's the thing about learning to code.

everyone tells you: learn react. learn typescript. learn algorithms. practice leetcode.

nobody tells you: learn how to explain to your project manager why the feature is delayed without making them panic.

nobody teaches you how to write a status update that your client actually understands.

and definitely nobody prepares you for that moment when your atasan asks "how's the project going?" and you freeze because you don't know how to summarize 2 weeks of work in 2 sentences.

we focus too much on technical, forget everything else

i used to think being a good developer = writing good code.

turns out that's like... 50% of the job.

the other 50%?

  • explaining what you built
  • reporting progress clearly
  • communicating blockers before they become disasters
  • making technical decisions understandable to non-technical people

basically: communication.

and here's what nobody tells you - you can be an amazing coder but if you can't communicate, you're gonna struggle.

that time i learned this the hard way

context: my first real project. building a dashboard for a client.

me after 2 weeks: built half the features, ran into some API issues, had to refactor the data layer

client: "how's it going?"

me: "uh... good? i mean, there were some issues with the API rate limits so i had to implement caching and refactor how we fetch data, also the previous architecture wasn't scalable so i restructured the state management with zustand instead of context api and—"

client: "...so is it done?"

me: "well, not yet but—"

client: "when will it be done?"

me: "uh..."

awkward silence

what i should've said:

"we're 60% done. the core features work. hit one blocker with API limits but already solved it with caching. should be ready by friday for testing."

clear. simple. actually useful information.

lesson learned: save the technical details for your team. give stakeholders the summary.

what makes a good report (learned from experience)

after enough awkward client calls, here's what actually works:

1. structure your updates

don't just ramble. follow a pattern:

  • done: what you completed
  • doing: what you're working on now
  • blockers: anything stopping you (if nothing, just say "no blockers")
  • next: what's coming up

example:

Done: user authentication, dashboard layout
Doing: integrating payment API
Blockers: waiting for API keys from client
Next: once keys arrive, finish payment flow, then testing

takes 30 seconds to read. has all the info they need.

2. translate tech to human

your client doesn't care that you "implemented JWT token refresh logic with axios interceptors."

they care that "users stay logged in and don't have to re-enter passwords."

bad: "refactored the component to use react query for server state" good: "made the page load faster and show real-time updates"

same work. different explanation.

3. mention problems early

this one took me a while to learn.

old me: discovers a blocker "i'll fix it myself, no need to worry anyone" 3 days later, still stuck finally tells team team: "why didn't you say something earlier??"

new me: discovers blocker → immediately report it → team helps or adjusts timeline → problem solved faster

proactive communication beats reactive excuses.

if something's gonna cause a delay, say it ASAP. gives everyone time to adjust.

4. match the detail level to your audience

talking to your lead developer: go deep on technical details. they want to know.

talking to the client: high-level summary. they want to know it works.

talking to your atasan: progress, timeline, blockers. they want to know if things are on track.

same project. different explanations.

why this actually matters

"ok but i'm a developer, not a communicator"

yeah i thought that too.

then i realized:

  • clients don't know if your code is good. they know if you communicate well.
  • your lead can't help with blockers if you don't report them clearly.
  • projects fail more from miscommunication than from bad code.
  • you won't get promoted just for being good at coding. you get promoted when people trust you with bigger responsibilities.

trust comes from communication.

what i'm doing to get better at this

honestly still learning. but here's what's helping:

1. practice in low-stakes situations

  • write better commit messages (forces you to explain changes clearly)
  • post in team chat about what you're working on
  • explain your code in PR descriptions

2. watch how seniors communicate

pay attention in standups. notice how experienced devs report stuff:

  • they're concise
  • they mention blockers without drama
  • they know what level of detail to share

copy that.

3. ask for feedback

after a client call or status update, ask your lead:

"was that clear? anything i should explain differently next time?"

they'll tell you.

4. write it down first

before a meeting or call, i write down:

  • what i did
  • what i'm doing
  • any blockers
  • what's next

helps me not ramble.

the mindset shift

here's what changed for me:

old mindset: "my job is to write code"

new mindset: "my job is to solve problems. code is one tool. communication is another."

both skills matter.

you can build the most amazing feature, but if you can't explain it to your client or report progress to your atasan, that feature might as well not exist.

practical examples from my daily work

standups:

old me: "i worked on stuff. still working on things." new me: "finished login flow. now working on dashboard API integration. no blockers."

client updates:

old me: "refactored the codebase for better performance" new me: "page now loads in 2 seconds instead of 8. users will notice the difference."

blocker reporting:

old me: stays quiet, tries to solve alone new me: "hey, stuck on this API integration. tried X and Y. any suggestions or should we reach out to the API team?"

same situation. different communication. different results.

the honest truth

learning communication feels awkward at first.

you'll over-explain. then under-explain. then over-explain again.

but like learning to code, you get better with practice.

and unlike learning another framework, communication skills transfer everywhere.

explaining code to a client? same skill as explaining a bug to your team. same skill as writing documentation. same skill as giving a presentation.

one skill, multiple uses.

what you can try today

don't need to master everything. just try:

  1. next standup: structure your update (done, doing, blockers, next)
  2. next PR: explain WHY you made changes, not just WHAT changed
  3. next client call: write down key points before the call
  4. next time you're stuck: report it early instead of struggling alone

small steps. real improvement.

anyway, that's what i've been learning lately.

turns out coding bootcamps teach you react but not how to explain react to someone who doesn't code.

gotta learn that part yourself.

and yeah, still figuring it out. but at least now i don't freeze when my atasan asks "how's the project?"

progress.