You can find in internet a lot of articles and videos about how to improve your code or how to write better code. But nobody is talking about rules to avoid real pitfalls, like for example being fired, getting lower salary or do more overtimes.

Always be cautious

Rule number one is that you always need to be cautious about what you are doing and check it twice. You can find in internet lot's of stories that people were fired from the companies on their first or second day after deleting production database. And actually it can happen with anybody. So you simply setup your machine, running tests or did something similar and you don't know project deeply yet. It might be that you used some credentials that was written in default file like .env.example which for some reason had production values inside.

So you just run some command and you accidentally deleted production or staging database. Normally it is of course not your fault but the setup of the project or the company but nobody cares. It may happen that you will be fired when it happens because they need to find someone who caused this problem. And it can be even worse if they don't have and production backups and you complete removed all production data.

This is why I highly recommend you to be extremely cautious. You always need to check what commands do you run, with what credentials and what we have inside. If you see some keys on your local machine with word prod or production inside, you should never use them. It will lead you in a big mess.

Here is a story of my own experience. After cloning a project in one of the companies and running tests I removed staging database completely. It happened because by default inside tests there were staging credentials inside. So it can happen with anybody.

Also you need to apply exactly the same rule while working with git. Because every single merge, rebase or push with force can completely break the history and your project. And if you don't have a backup and you can't revert this command than you have a problem. This is why you always need to be aware what you are doing with Git and I highly recommend you to avoid using of destructive commands like pushing with force or using rebase.

You must do backups

Which brings us to the next point. You must do backups. For example if we talk about Git you can simply copy the folder of the project with .git folder inside. In this case if you made something wrong with Git you can simply use your backup folder and just take Git state from there.

Exactly the same can be applied to the database. But actually it is even more important. If you make some changes especially on production database you must do a backup. If you test some new migrations on database you must do a backup.

It's not enough to just do a backup. You MUST check that backup is valid and you can really restore it. In other case you don't have a backup.

Time management

The next rule is extremely important if you want to avoid overtimes. In every single company you can see teams who goes at home on time and teams who constantly have overtimes. And it doesn't have anything to do with experience but just with planning. You must have special days when you do deployments.

For example you should never deploy your code on Friday, before holidays or in an hour before presentation. Your code might be broken, you may have overtimes or your demo will be postponed because you broke the code.

The same applied to deployments in the evening. You should not deploy anything half of an hour before you are going home. There is always a change that you won't go anywhere and you will sit there 2-3 hours trying to fix that bug on production.

Plan realistically

The next important rule is to plan realistically. You need to have a plan what you and your team will do this week and today. In this case you can always understand how much work needs to be done and you need to be realistic. It doesn't make sense to plan too much if you really see that you won't do it on time. And it is always important to remember that delivering less is much better than delivering nothing. Which brings us to the next point.

Be crystal clear

You must be crystal clear with yourself, your project manager and your teamlead. You must just say from the beginning I don't feel that I can do that in one week. In this case you can from start increase time for the feature or just make a scope smaller.

Also you must always be in sync with your project manager and your teamlead. Every single day if you see that feature is not progressing as intended and you can't do it on time or you have some obstacles you must sync this information with them. In this case they are aware of the problems and they understand at what point you are. If you simply sit on one feature the whole week and nobody knows what you are doing at all and then you just say "Okay, I can't do it on time", it is not finished at the end of the sprint and there is quite a lot of stuff to do then it is your fault and your problem. If you are in sync every single day then everybody are aware of your progress and how much more time you need.

You must always be crystal clear. In this case you won't have any misunderstanding.

If you think that you are doing something not right and maybe your project manager thought it differently then it's better to talk about it before you go in the wrong direction.

So this were my 5 rules how to avoid pitfalls while programming. Also if you are interested how to spot a bad team or company make sure to check this post also.