If you are a newbie developer, you may think this blog post is a joke. However, experienced team leaders will hardly even smirk – everything you will read below is damn serious.
Option 1: Do the opposite of what the manager’s told you
Why this is wrong: Pretty often, managers know much more about a project than the average developer. Furthermore, a car can only have one driver: if different people direct its wheels, it will probably crash or fail to reach its destination in time, at best.
Example: A manager asks a developer to design premises with a door. Based on the technical assignment, the door has no handle. Instead, it has a pedal. The developer has seen thousands of entries in their lifetime and decides that the manager must have lost their mind. They try to argue and then do it “right”. Eventually, they are fired.
The developer was fired because:
- This was a door for a warehouse where people would get in carrying boxes in their hands – the pedal was the main idea behind it all;
- The client was a company that produces door pedals;
- The door handle has been sold to the client separately and was supposed to be installed in the second stage of the project.
Moral: Read the technical assignment carefully and stick to it strictly. If there is anything you don’t understand – just ask. If you disagree – try to convince your counterparts. Don’t just keep quiet and do what you are not supposed to.
Option 2: Don’t test your code
Why this is wrong: You should respect the work of testers. This is a sign of basic politeness – just like cleaning your teeth before going to the dentist.
Example: A programmer should change the word “OK” with the word “REGISTER” in the registration window. They find this word in the code, replace it and send it to the tester without double-checking. Based on the project plans, testing should be automatic and should not take more than a couple of hours under the supervision of testers. However, it turns out that the new word did not fit into the button and ruined the whole design. The task had to be redone, and it took a full day to get it right.
There is a term called “smoke testing” that has its roots in radio electronics. You turn on your device and look if it starts smoking. This is the most basic level of testing. Of course, testing is for testers, but if developers regularly allow bugs due to carelessness, they will certainly not win the respect of their teammates.
Moral: When five minutes of your time can save another person a whole day, don’t be lazy. Developing is a job for perfectionists who are ready to check and double-check again and again.
Option 3: Do other stuff while you’re at work
Why this is wrong: You get money for selling your time. If you steal from this time, this is theft.
Example: A Java Developer has two remote jobs, and it seems they are doing pretty well. Their bosses have no clue about it. Suddenly, there is an emergency in both positions. Testers are sending new tasks every 15 minutes and require immediate reaction. The developer responds slowly, gets the code all messed up and eventually fails both teams.
Moral: If you have agreed to work full-time – work full-time. If you have some spare time – ask your managers to give you more work and more money.
Option 4: Use your favourite library/framework without asking the managers
Why this is wrong: A developer is a job that requires the ability to follow your team’s rules. If you like ReactJS, which is not the library used in your company, just forget it. Use the platform picked by the managers.
Example: A developer is tasked with developing new functionality of a website. They think the easiest and fastest way to do it is to use ReactJS – and is determined to go this way.
A week later, a code review takes place, and the developer is fired because:
- They forgot there was a file full of 10GB of Angular code;
- There are no other developers but themselves using React in the company, so nobody could replace them if they get sick;
- The client requested Angular.
Moral: Architectural solutions, the choice of a platform, technologies, frameworks, and libraries are in the realm of the technical manager. If you have an idea, speak up. If you decide to keep quiet and do what you like, start looking for a new job. Of course, not the first time you do it, but the outcome is almost inevitable if you do this trick twice.
Option 5: Ask for a promotion a week before the delivery of a big project
Why this is wrong: This is what people call blackmail.
Example: A developer has created a voice recognition library as part of a major project – the library is almost ready and is due to be delivered in a week. Another developer would need months to find their way into the code. The developer decides now is the best time to ask for a promotion.
The manager has no choice but and raises the programmer’s salary. After the project is delivered, the developer gets fired or is no longer entrusted with any essential tasks. They have lost their managers’ trust.
Moral: “Offers you cannot refuse” are better suited for the Italian mafia than developers.
There are certainly other ways for a programmer to get fired and, if we dig deeper, we can probably go on for days. But we hope the list above gives you a good idea of what you should (if you hate your job) or should not do (if you love it, which we hope you do). Good luck!
If you need more advice on how NOT to get fired and find a fantastic job, our team of awesome experts is always there to help you. Don’t be shy and get in touch for more useful tips and tricks!
