What are some good rules to follow to ensure you don't get fired because of your code?

1. First of all, always follow the rules your team uses, unless you have a very good reason not to. <br><br>2. Code that works - or at least breaks in a way that is easy to diagnose. Code that is clever is all well and good, but code that <br> works is more important than code that is clever. And when you start out as a coder, you will write a lot of code that is good for nothing but being an example of how not to do <br> something. <br><br>3. Code that is understandable is far more important than being 'clever'. A good rule of thumb is that the more difficult it is to understand, the easier it should be to maintain. If your code is so complicated that it's hard to understand and hard to maintain, then you're in trouble. <br><br>4. Be very aware of what you are committing. If your code is in a private version control repository only <br> you have access to, then you can make an unholy mess of it with no repercussions. First of all, if you're working on a team and you put your code in a private <br> pocket universe, you're committing a cardinal sin. Second, if you are in charge of deciding whether your code goes into version control or not, then you still have to be careful, because it's very easy to make a mistake and commit a whole bunch of rubbish you shouldn't be committing. <br><br>5. If your code is in a different branch, and you commit under a branch other than main, there is still the possibility that either you or someone else <br> will accidentally merge the <br> code you're working on into main, and if you've made a big mess of it you will put main at risk. This is something that can be a problem even if you work alone. <br><br>6. There's a type of coding called pair coding, where two coders work together on the same codebase, with one watching the <br> other on a screen and the other coding. This keeps you from making mistakes, because the chances are that one of you will catch a mistake when it happens. This is not only good for keeping you from making <br> mistakes, it's good for learning <br> from the other coder. It's also somewhat time consuming, because you can't be coding while you do it. It's best saved for the most difficult and complicated coding jobs. <br><br>7. Whenever you commit, always make sure you check whether you've committed something you shouldn't. You <br> can always uncommit if you've put something you shouldn't in the repository, but that's a good way to waste time you could be spending being productive. <br><br>8. Don't worry if you don't find other people's code easy to read. I'm a beginner <br> coder, and I have trouble with that. I've been told this is normal. <br><br>9. Even though other people's code is hard to understand, at least try to read the comments. Even if you can't understand other people's code, you need to be able to understand their comments. <br><br>10. To avoid getting fired, you have to be willing to learn. If you want to learn to code, you have to start by learning to code. If you're on a job and you need to learn to code, you have to ask questions. The willingness and ability to learn is more important than intelligence. <br><br>11. Don't be afraid to ask questions. The best way to learn is by asking questions. If you have trouble learning, you need to ask questions.<br>"Siane]="