I was fired from software engineer position and I want to share lessons I learned Artur Follow Jan 23, 2019 · 12 min read

"Every kick in the butt is one step forward.” — random guy from a bar.

I would add that, once you are kicked, make sure to use that momentum to jump as far as possible.

Yes, I was fired and it wasn’t so bad as you think. It was actually a good trigger to rethink my goals. A couple of years ago I worked in a startup. It was one of the companies you’d want to work for. Big goals, good culture, and interesting people. But when they needed to cut developers, I was one of them. They fired some of the most recent hires. Unlucky me I thought, but it could be a good excuse to fool yourself. I think, a great developer won’t be fired even if he started a week ago.

This unpleasant event forced me to do a big retrospective of my career. The best way to move forward is to learn from your failures. After I started digging to my past I found a lot of lessons to learn from.

Here I selected my 10 most valuable lessons:

1. Share your knowledge

2. Love what you do

3. Know your user

4. Know your code

5. Learn from smartest

6. Take time to know your coworkers

7. Don’t be dramatic

8. Ask for a feedback

9. Be impactful

10. Be a salesman

1. Share your knowledge

I used to be cynical about coworkers who were celebrating and sharing every accomplishment or finding. I thought, what is so special about it? Why not keep the celebration to yourself, instead of bragging about it to everyone? But I didn’t understand the real value of sharing. Spreading knowledge it’s the best thing you can do with your achievements.

Start small and think about your last task or problem you solved. What did you learn? What experience did you gain? Then share it with your teammates. Don’t forget about freshly hired developers. Any kind of information is useful for them. So you always will have listeners.

Make the presentation as your side project. Think about topics you want to know more about. Maybe there is a framework or tool you want to learn. Explore that topic and prepare a short presentation. Some of the companies have tech talks events, which is a perfect place to present your lightning talk. If your company doesn’t offer this, then you have an opportunity to initiate tech talks there. To motivate yourself, announce your talk in advance, so you will have deadline and responsibility to finish.

If you need more challenges and a bigger audience, then present your talk on user group events or even at a conference.

2. Love what you do

It’s the best motivation booster. Find work that keeps you happy. If you don’t like the project you working on, search for other projects. Find one which looks look most interesting to you. Speak with your team lead or project manager about your needs and most likely together you will find an option that fits best for all.

If your company doesn’t have the position or project you want, then you may want to consider finding another job. That will be most valuable for both sides.

3. Know your user

In my first job, I barely knew who the users were and how they used the application. I understood some specific parts of the program, but only those that I worked on.

So first of all, understand what are you building. Who will be using your product? Why do they need your product?

Put yourself in the user’s shoes. Try to solve the same problems they have. You can even try a scenario, where your application doesn’t even exist and you need to do everything manually. Think about your end user with every code line you write. Knowing your users better will let you feel your impact on them.

If it’s available to you, ask customer support if you can listen to their conversations with customers or ask to share email chats.

If it’s possible to meet your users and talk, then ask how they use your app or what they struggling with. You can write down your questions in advance, so if you meet with someone, you will be prepared and make the most of your time together.

I promise you will start to care about them much more after that. I hope, after this, when you see a bug come through, you’ll say, “Oh my, hat would be a nightmare for my users. I need to fix that.”.

4. Know your code

The biggest difference between a programmer and a professional programmer is one of them writes code and the other one knows the code.

Spend enough time to understand what’s really happening in your code.

It’s really easy to catch up when starting on a new project with small or no code base. But it’s way more difficult to get what’s happening in a big existing project.

How to deal with legacy code?

Jumping to unknown code is scary. Start with small changes. Find a simple bug that needs to be fixed. Fixing a few small bugs will help you see the bigger picture.

Try not to blame code author. Don’t think that you can do better. This attitude will waste a lot of your time. Most likely the way they wrote that was reasonable at that moment.

Start like an end user. Take simple flow and go through the UI code, then the backend. Try to draw a sequence diagram. Change code and see if you can predict what will happen. Repeat this process with other parts of an app. Share it with others, to make you sure that you moving the right direction.

The hardest decision is how far you should go fixing the legacy code. Don’t start with big refactoring. Find the smallest solution that will fix the bug. That way you will have a fallback in case if you can’t find anything better. If you still have time, refactor it with small iterations. Don’t start a big refactoring if you are not sure about the business value of it. Speak about your problem and solution with your teammates, to decide about value.

Understand your programming language, debugger and tools.

You should know at least 20% of the programming language you’re working with, because, most of the time, this will be enough to do 80% of your work. (Yes, classic 20/80 rule).

The debugger is also a very important part. You will spend a lot of your time debugging code. Try to find the fastest and easiest way to do that with your tech stack.

Problem-solving skills

One of the most valuable skills for a software engineer is problem-solving.

There is a lot of problem-solving techniques you can learn and here is one you can try with bug fixing.

Understand what ask is. What is the problem actually about. You will finally know it when you can explain in plain English. First, try to reproduce the actual bug. If you can’t reproduce it, gather as much information as possible. Logs, error message, anything. Browse code which you think could be related, possibly you will find something that could be obviously wrong. Draw a diagram or try to explain it to someone. If there is no one around, use Rubber Duck. :)

Plan it. Don’t start hoping it will solve itself somehow. Give your brain time to analyze. Here is good question to help create a plan: “Given input x, what are steps necessary to return output Y?”

Divide. Don’t solve a big problem. Divide it into sub-problems. List them and try to solve them separately. Connect the dots after and it will lead you to the solution to the original problem.

Three things to try when you stuck:

Debug. Figure out what you really told to your program rather what you thought. Go step by step.

Reassess. Rest and think about the problem from another perspective. A good way is to delete everything and start again from zero.

Research. Google. Try to find if someone who already had the same problem. Even if you solved it, it’s worth searching and maybe help someone to solve or find other ways of solving theirs.

Know your limits.

Thirty minutes is a rule of thumb for solving problems. If you can’t solve the problem in this period of time including google and stack overflow, reach your teammates. They may have struggled with the same issues or have some insight into a possible solution.

When you are explaining your problem, don’t rush and don’t jump to conclusions. Assume your teammates have never heard about your issue. Tell them what the problem is and step-by-step what you already found. Don’t be nervous when they suggest options that you already eliminated. Rather explain why you think it’s not a correct way to solve. Who knows, maybe you put aside the actual solution.

5. Learn from smartest

I was jealous of others success. That affected my relations with them. Rivalry forced me to compete and that stopped my own progress. I wanted to do everything alone, so I could feel like was the winner in the end. Fortunately now I know, that this was a mistake.

There always will be people who know more, do better and achieve more than you. Use that opportunity, being around them, to learn as much as possible. If there is a person who succeeded in doing the same thing you are trying to do, then you can just go and ask them everything. Sometimes you just don’t see that as an option, because you think that you are smarter than they. You won’t lose ownership of the achievement if you will do it with others help.

6. Take time to know your coworkers

In all the places I worked, I met few people I didn’t like. That made it difficult to work with them on the same team. I unconsciously started to criticize everything they said. Then a few times I had an opportunity to work with them on the same feature. Problems solved together helped me to know these people and find something common. It allowed me to see that they have more good traits than those that so annoyed me.

7. Don’t be dramatic

Don’t avoid conflicts. Don’t take everything personal and don’t make dramas. Take time to listen others positions. Be tacticful and describe your opinion when arguing.

Conflict is not about who will speak louder and say the last word. Conflict is about making great results from different opinions.

8. Ask for feedback

One of my biggest fears was to ask for a code review. I was so afraid of getting feedback, that i sometimes tried to postpone the reviews. I think most of you know that feeling when you are working so hard to create one feature and in the end, a co-worker shows you a simpler solution and your 100 code lines shrink to 3 lines of code. I was afraid to turn out to be useless. Why would an employer want to work with me if I’m spending twice as much time to write a longer solution than another developer, I thought. But, that was wrong thinking.

The point of feedback is not to make you feel miserable. It’s to teach you from your mistakes. This example is applicable not only for code reviews.

What I’m trying to say is that feedback is a way to learn. Asking for it often will help you progress quicker and with smaller adjustments. Always try to find a way to get constructive feedback. Receiving good comments feels nice and helps to let you know you’re moving in the right direction. But it can be more valuable to get negative, constructive feedback, which helps you understand what you need to improve.

Push aside your insecurities and be open for feedback.

9. Be impactful

I used to think, that being impactful meant being unchangeable. So when I wanted a salary increase, I thought I could just tell them that I’m leaving and the company will give offer me twice my salary. No, it doesn’t work that way. Being dependent on one developer is dangerous for any company.

You are already impactful with any work you do. You can think that adding a new field to a web page is simple and any other developer can do that instead of you, but you are actually that “any other developer”. You are making that impact now.

Of course, you can’t keep doing simple tasks all the time. You need to grow and make a bigger impact. Here is a little bit of help for you. Three themes that could lead you there:

Demand - What team is most impactful to company goals?

Passion - What really motivates you? What do you enjoy working the most?

Skills - What are your strengths?



Here what you can get of combining only two themes together:

Passion and Skills - will create you a hobby. Which could be fun, but not directed to career, because of lack of demand.

Passion and Demand - lack of skills will stop your progress as you will need to learn a lot of new things. You may end-up with your skills when there no demand for them.

Skills and Demand - will give you a lot of money, but lack of passion will quickly reduce your motivation.

Looks like the best scenario is to combine all of them together.

Let’s breakdown the themes to help understand your needs.

Passion

What activities excite you most?

What type of work and place brings you to flow, when you lost track of time doing it?

What work energizes you?

Also, what discourages you the most? Try to keep away from that.

Strengths

What parts of engineering are you really great at?

What are your competitive advantages, non-technical, relative to other engineers.

What are your adjacent disciplines?

Concentrate on 2–3 skills to master. It’s harder to become master on one thing than it is to learn 25% of 2 things that can be more powerful together.

You could be a mediocre software developer, but have some managing skills which will make you a team leader. It will be harder for a person who is a very good developer, and has no management skills to become a lead. But it depends of course on your passion and goals.

Demand

What trends are in high demand recently? Like machine learning has been for the last few years.

What teams and product create the greatest value for your company?

What strategic bets or investments do you believe will create massive value in the future?

Make sure to align efforts with your teams or companies goals.

10. Be a salesman

I remember many times in the past, I did not feel heard. My ideas weren’t taken seriously. Then I tried to push them again and again with the same arguments or just stopped. Of course, not all ideas were brilliant.

You must sell your ideas. Most of the time it’s all about how you will present it. It’s not enough just say and hope that everyone will follow you. Be prepared and have good arguments so you can convince your teammates.

Sometimes your idea is really good, but your arguments are not strong enough. In this case, it is best to put it aside and trust your team. Don’t be a rebel, who goes against their team if people en’t bought into your idea. If there will be a natural need for your solution, then they will see the value and you can come back to it.

Summary

Love and understand your work. Try to know your users more closely so you can feel their struggles and the impact of your effort. Be a good friend to your teammates, learn from others and bring new knowledge to your team.

That was ten lessons that were most valuable for me. Even if this article concentrated more on developers, I wanted to tackle problems that are common for other industries too. There are still a few topics left in my notes and will share them in my further articles. I think every one of them deserves an article. Some of the thoughts are mine, some are from articles and books. I added a few links in the end.

I hope my lessons will be useful for you and it will help you in your future career. Please share your stories in comments too. This is my first article, so feedback is more than appreciated.

Source of some ideas:

How to think like a programmer

Eight Strategies For Tackling Legacy Code You Didn’t Write

The complete software developer’s career guide

The 3 Keys to a Remarkable Career