A user on the freeCodeCamp forums shared how they lost their first dev job due to lacking communication skills. I shared some of my ideas and that reply got quite a few likes so I figured it was content worth sharing here too. Here’s my reply verbatim.

So sorry to hear about your termination.

Unfortunately it’s a skill that’s often not talked about much when people are presenting these “roadmaps” to becoming a developer.

It’s hard to give you specific advice as I don’t know what project management was like or what communication channels were available to you but I can give you a few pointers.

Break up tasks

The first and most important thing is to split any tasks assigned to you into small goals that you can achieve in a very small amount of time. When someone asks you what you’re working on, the answer should be different than the answer was yesterday.

If your company uses Jira this may mean adding sub-tasks to the ticket you’ve been assigned, or it could just be writing your own notes about how you’d like to split up your work.

Whether it’s for a customer, a user or a project manager, splitting work up into small units makes it easier for people (including yourself) to understand the progress you’ve made as well as open up more opportunities for feedback before you’ve spent too much time on something.

Plan your day

Schedule time at the beginning of your day to make a plan for yourself. Where I work we love splitting our day up into two parts; good day and great day.

Every morning my team lays out what we want to accomplish today. We account for meetings and personal development time. A good rule of thumb is that for most people the average time you get to sit and be productive writing code is about 4 hours.

I ask myself, if I had a good day today what would I get done? If things go really well (or great) what else might I get done on top of that?

Plans can change, and so I take note of unplanned work as it comes up throughout the day. If I don’t get as much as I wanted done I can either attribute that to unplanned work that came up which I had to task switch for, or it’s because I underestimated how long a task would take which happens all the time.

Create visibility

Some companies have daily check-ins often called “stand up”. If your company doesn’t do it anyway. Every morning through whatever communication channel is available to you make sure that people on your team including your manager knows what you were working on yesterday, what you plan to work on today, and if you need any help.

It’s important that this information actually changes day-to-day. A bad progress report sounds like:

“Yesterday I was working on ticket ACME-1234, it’s going good, today just working on that more. No blockers.”

A good one:

“Yesterday I finished the styles for the new contact form, today I’ll be adding the frontend validation. I’m not sure if or what package I want to use for that yet so if anyone wants to give me suggestions later that would be awesome. No other blockers.

“Stand up” meetings aren’t supposed to be “progress reports” but in reality this is what they turn into at most companies.

Either way, you want this information conveyed in one form or another and you want it to change day-to-day. The way you achieve that is breaking work up into smaller tasks.

Ask for help

Do not hesitate to ask for help! It’s so important. If you’re stuck and can’t figure something out it’s better to ask for help than to spin your wheels for hours making no progress.

Same rules apply when asking for help at your company as when asking questions on the freeCodeCamp forum or Stackoverflow.

Make sure you’ve thought about your problem before asking for help. What did you try? What are you expecting to see happen? What’s actually happening? etc.

Or sometimes you might need feedback on how to approach a solution. Should you do it this way, or that way? Is there a better way that you didn’t think of? If you’ve broken your work up small enough it should be easy to include someone in the discussion and go over pros and cons.

Under promise and over deliver

Estimating is so hard. When building software or websites things just take longer than we think they should. Developers can be the worst at thinking something is easy and just a quick change here or there only to have the thing be a bit more nuanced or complicated than they first thought.

Whenever you can err on the side of caution. When someone asks how long something will take they will always be happier to see you get it done faster than you said it would instead of longer than you said it would.

Some managers have a way of pressuring you into over promising. Don’t do it! Let them be disappointed in your estimate. It’s not their estimate it’s yours. They’ll be a lot more upset if you appease them by giving them the estimate they want when it’s not true rather than the estimate they needed which may not have been what they wanted to hear.

Demo regularly

This comes back to splitting up your work into small pieces. You want to be able to show people what you’ve been working on as often as possible not just tell them.

Quick boring demos that happen often are far better than over the moon mind blowing demos that never happen.

Show people what you’re working on and show it often. Doesn’t have to be daily but think weekly or bi-weekly.

If there is no proper channel for doing this, you can record short screen casts and share the links in Slack or whatever communication tool you use. You don’t even need voice over if you’re not comfortable with that. Just a quick 10-30 second demo that shows one small thing you did. You can group them together at the end of the week into one Slack post or stitch them together into one video — whatever makes sense to you.

If people are interested in seeing it, they’ll look, if not, they won’t. But people will definitely appreciate it and may even start following in your footsteps. I’ve done this for clients before and they loved it so much they started making it a part of their own internal process.

Take notes

I highly recommend developers keep a daily log. It’s so helpful if someone ever questions what you’ve been working on and they’re asking you to go back more than a day. I don’t know about you, but I don’t actually remember what I worked on two days ago. I have to go look at my notes.

This helps you cover yourself if a manager or customer asks, but it also gives you a place to jot quick notes about problems you’ve solved.

I love to add a TIL (Today I Learned) section to my daily log where I write at least one thing a day that I learned. Sometimes it’s something about the company, or something about the business domain of the client I’m working for, or something about the code base or just a cool tool or CLI I found out about. Sometimes I catch myself getting stuck on a very similar thing over and over, and if I write it down it helps me remember what I’m supposed to do in that situation going forward.

Closing thoughts

Communication is probably the most important skill a developer can have. Being technically proficient is only the base requirement. I strongly believe the differentiator between successful developers and those who struggle throughout their career is communication.

You have to constantly work on it and as it turns out, most developers are not as good as they could be. If you make your focus to improve on the skill at all, chances are that you’ll quickly become a better communicator than most of your colleagues and rather than getting canned for being bad at it you’ll find yourself getting more promotions than others for being so good at it.

I also know that it could be said that good managers wouldn’t let this happen in the first place which I agree. However where I work, a consultancy, we try to teach our teams to “not invite management”. If you’re communicating well people don’t feel like they need to manage you. They also know what you’re working on and when they can expect to see something. They learn to trust you because you communicate well.

I really hope you find all of this helpful and good luck getting back in the game!