I will share some thoughts about development.

About me: Smiling person, father of two, husband, Senior Developer/Architect (in that exact order, it's important)

Experience in development since 2004
Linux user and advocate since 2001

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 also cover the things that are not supposed to pass.
• comment your 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 faced the same problems as you do, sometimes you will find him/her in your team.
• don't use complicated or tricky code. This code will have to maintained. If you made a code that is 20% faster but no one can understand, it's a failure.
• Timebox your refactorings, avoid the tunnel effect. If it's too long to refactor, split it.
• Keep It Simple and Stupid

Team

• ask 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.
• guidelines are here to avoid everyone going in different direction.
• do not hesitate to ask 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 request 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 know nothing (Socrates/Ygritte)
• you learn from your failures, not your success.
• It's OK to ask for help
• put yourself in someone else's shoes.
• read about cognitive biases: confirmation, imposter syndrome, survivor, compliance …
• 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.