I am being fired after one month

Month ago, I started working in a small company as a sole developer handing and creating custom WordPress websites and deploying them on server. I was working on theme development and also was handling website crashing on servers. I also migrating websites to other servers.

Now I got a one week notice for termination of employment. They told me I am not quick and I am lacking in communication skills as I wasn’t able to update to management about what I am working on and how long it is going to take. I have been self taught developer my whole life it was my first official job.

I need to work on my communication skills for my next job. Have you experienced similar things in your career? Can you provide me advice to improve my communication skills and be more professional? Thanks

4 Likes

Hi @abhigk !

I am sorry that you are getting fired.

I think that a lot of new self-taught developers are afraid to ask questions and communicate because they don’t want their bosses to doubt their abilities.
But not communicating is worse.

For example, I picked up a freelancing gig a few months go doing small tasks for this guy’s software company. He knew I was still new at this but he thought it could work out.

Well in the beginning, he would give me tasks and let him know if I had any questions.
But I was afraid to ask questions because I didn’t want him to fire me.
So I would just struggle way longer on my own.

But after a few days, he would ask if I had been working on the project because he hadn’t heard from me.

At that point, I realized that I was sending the wrong message by being silent instead of just asking for help.

So, from that point on, I started letting him know my approach to the problem and what I had researched so far. That way he knew my thought process and could help steer me in the right direction.

That would be my advice for you.
Ask more questions and communicate what you are doing even if it is not 100% right.
Let them know your thought process.

Otherwise, you are making the situation worse by going silent.

Your employer understands that this is your first job and you need guidance.

Hope that helps!

17 Likes

I second what @jwilkins.oboe said. I’ve made the mistake of not communicating well at jobs, and while I didn’t get fired for it, I know it hurt my relationship with my previous boss.

And I’m sorry you got fired. I know it sucks.

One thing I did that helped with my communication skills was to join Toastmasters. It’s a commitment. And it’s not free. But I found it very worthwhile.

Best of luck.

5 Likes

I work at a large company and can say even experienced devs don’t have the best communication skills. I agree with @jwilkins.oboe in that you need to be in touch with your manager on a regular basis. Usually teams will have regular standup meetings for devs to report their progress and mention any blockers. Any role can get challenging at one point or another, but if you’re not making any progress you’ve got to bring it up as to not waste time and resources.

6 Likes

That sounds sad, hope you’re doing well.

As human beings, we feel very uncomfortable with uncertainty.
This is one of the biggest beginner mistakes at work: letting manager and team members “chase” you.

They do this, because they feel this uncertainty:

  • How is team member X doing?
  • Can we deliver on this deadline?
  • Does this hurt myself or my team?

You can remove a lot of these feelings by communicating pro-actively:

  • Hey manager, I’m currently working on X. My goal is to publish it on friday.
  • Hey manager, I won’t make it until friday. I’ve found a bug and I’ll need until monday afternoon.

If you don’t do this, the manager and other team members have to chase you. They have to come to your office and ask for this stuff. This is annoying for them. You can remove their uncertainty, e.g. in your team’s communication channel. So you send one message instead of X people who have to come to you.

7 Likes

First of all, sorry to hear about it.

Personally, having been a manager (non-development), if your termination and their complaints come as a surprise, then they are at least partly to blame. They should also have been giving you feedback about what they expect from you and how you are meeting their needs. This is especially true if you are new to the work. Truly, I think that it’s odd that they would fire you after only one month, rather than work with you and try to help you grow into the role.

Perhaps part of the problem was that you were the “sole developer”. (“Soul developer” would have been a cooler title. :wink: ) In a “normal” development environment, you would typically have had daily standup meetings where you would have discussed your progress, plans, and blockers. Barring that, if I was in your situation, I probably would have sent out weekly (if not daily) updates on my progress and difficulties.

Having done a little managing, it can be unbelievably frustrating to not know on what your people are working and what the status is. Managers are having to make long term plans and having to answer questions about the status. If you are the only developer, then it’s almost like you’re a department head so that responsibility falls on you. And since you are the only developer, it is also your job to help them understand what you are doing and how long it will take - to them, what we do is magic. Yes, it is difficult to estimate this stuff sometimes, especially if you are new. But that is why you keep them updated. It’s like if your friend is picking you up for dinner. Him calling you and telling you he’s running an hour behind schedule is frustrating, but him not calling to let you know is infuriating.

But again, they really should have done a better job letting you know what was working and what wasn’t. Sometimes people get fired because the company has their head up their butt.

I wouldn’t worry too much about getting fired. In the US at least, I think it’s pretty standard that they will not give details about why you were fired. If you’re asked, don’t say anything bad about the company. I would just say, “Yeah, they were nice people but it just didn’t work out. I was new and I don’t think they knew exactly what they wanted. That seems like a lifetime ago - I’ve learned a lot on that job and since then and look forward to applying it and continuing to grow.” If the interviewer asks for more, I’d just talk about communication and expectations. I think most developers will roll their eyes and nod their heads - I’m sure they’ve all had difficulties with non-coding management and understand the difficulties of communication. And I think if you frame it as a learning experience, it may still be better than having no experience.

13 Likes

This topic should be pinned. I think every beginner should know bout communications and how to handle situations when you already landed a job. Our goal is not only to land a job but stay on the job.

1 Like

Hello, abhigk. :slightly_smiling_face:

First of all, I’m sorry you lost your job. I hope you find a new and better(!) job soon.

Second, I think the advice already posted here regarding staying in touch with your managers and team members is pretty solid. Definitely get into the habit of providing a simple, brief summary that outlines the progress you’ve made and the problems you’re dealing with, and they can ask you questions if they need more details.

Third, you really do need to keep this in mind:

IMO, good managers make an effort to make sure that you have the resources you need and that expectations regarding communication and performance are clear. A manager who works with techie people should have a fair idea of how enthusiastic we are about communication, on average, and would check in on you if they were concerned about what you were doing. My brother-in-law, an experienced developer who works remotely, constantly complains about all the Zoom meetings with management he has to attend, so there’s no excuse for management not checking in before things became critical. (He also complains that there aren’t many good managers, but dealing with poor management is probably a whole sub-forum on its own!)

It does seem very odd that you left on your own for a month, then they simply fire you instead of trying to work with you. I’m willing to bet that there were other factors at work that led to your dismissal. Please don’t get discouraged!

Best of luck!

2 Likes

Is it to late to make them reconsider?
You could do nothing and just go at the end of the week, or you could try to prove to the boss that you can be more effective at communication.

If you want to stay there, why not create a road map of what you intend to do, and assign provisional completion dates. Also include any assistance that you may need as well. You might also want to know what their expectations are as well, as ‘not quick’ is somewhat subjective and relative to what? If you employer had not expressed dissatisfaction before now, how were you supposed to know?

It could be too late, but if not it could be a chance to prove yourself.

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 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 complicate 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.

Here’s a sweet free tool for this:

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 thought that 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, changes are 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!

5 Likes

There are already plenty of great comments on here, hopefully you and others will benefit from theses. I have zero experience as an employed Dev, but I have over 20 years in the corporate commercial world, so here are a couple of quick additions for anyone interested in this topic.
If in doubt: over-communicate. Over-communication is less of a problem than under-communication, typically.
Also, the style of communication can be important. Make it easy for people. For example, if you’re not going to make Monday’s deadline, state first “I’m not going to make Monday’s deadline”, and then tell them why. Many people try to soften the blow by telling the story first, before getting to the title, which can be infuriating.
Additionally, if you have a problem, try communicating it alongside the solutions you’ve thought about, like this: “I’m considering or to solve this problem. What do you think?” This gives several messages: firstly that you’ve thought about it and shown initiative, and secondly that you’re giving others a chance to consider the options and perhaps come up with ideas of their own.
Hope it’s useful - use it as you see fit!