Code
make sure the linting is enabled in your IDE.
code the unit tests while you code. Not necessarily TDD, but don’t do it at the end.
add tests for things that are not supposed to happen. I often see damned obvious unit tests. Your test should cover the things that are not supposed to pass.
comments you code. Even more if you used something you are proud or that is a bit complicated to understand.
avoid the NIH (Not Invented Here) issue. Someone is likely to have face the same problems as you do, even in your team.
don’t use complicated or tricky cofe. This code will have to maintained. If you made a code that is 20% faster but no one can understand, it’s a failure
Team
ask to other people about the way you plan to code something. It would avoid you to face multiple problems during a code review way too late.
ask for review early, even when you coded only 30% of the code. Why ? Because later it would be easier for these people to understand the other things you will add.
stay humble.
respect the code guidelines and workflow that are available in your company, even more if you disagree with them. Yes, I know. It’s hard.
do not hesitate to ask to a senior when you don’t understand a guideline, ask for other people if they are OK with something you dislike in the guidelines. If you see support, you may ask to change the guidelines. If no one agree with you, then move on, and deal with it.
when you disagree with someone else on a code review. Don’t argue. Ask for another people his/her point of view. If you have 2 people saying you are wrong, you might be more likely to accept you were, or at least your solution might not be the best.
You
You are not your code.
You known nothing (Socrates/Ygritte)
the best thing to learn is to say: No. Try to say no, from time to time, you will see how easily people will accept it.
your family is more important than your code.
find a way to take care of you as much as you take care of your code.
