Here are some rules or guidelines I try to live by as a developer. They are for all of you, from the beginners to the seasoned developers.
It is not an exhaustive list, so feel free to add yours in the comments below!

1. “Temporary” doesn’t exist in development
Be honest with yourself, you’re never going to change it. Ever.

2. Use meaningful variable names
Because abc, test or tmp are not really understandable by other developers, or by you in 6 months.

3. Be consistent with style, use guidelines
Some are immune to it, but unfortunately (or not), it drives me insane. So try to agree on some basic rules with your team on indentation, spaces, return, etc.

4. Throw and catch your errors, or handle them
I know, it’s easier said than done. And some languages are more error-friendly than others. Try to integrate it as early as possible in the process, it will be easier to do.

5. If there is an IF, there should be an ELSE
Or some sort of fallback. Try to cover all cases ;)

6. And if you’re ignoring something on purpose, leave a comment
Or a TODO, it’s okay.

7. No line of code should be left untested
Always test what you do, don’t expect things to work straight away. No offense, but you’re not that good ;)

8. Write readable code
Because the code is READ by humans and executed by machines.

9. Write unit tests whenever possible
Same as the “throw and catch errors”.

10. If something doesn’t feel right (eg. UX or UI), say it!
You’re often the first one who will see it in action.

11. If you have a doubt about a feature, ask!
Don’t take decisions if it’s not your role, you may end up redoing the whole thing.

12. Reuse code, create libraries… don’t repeat yourself
Think DRY, live DRY, eat DRY, drink DRY, sleep DRY. Oh, what did I just do??

13. Look for best practices and code optimisation
It cannot hurt, right?

14. If it takes 1 extra hour for you to do something that can save 10 mins to each user every day, do it!
Do the math, it works! And you would do it for yourself, so do it for others ;)

15. If something is not straightforward, put a comment
I’m talking about nice and short explanations when the code doesn’t speak for itself.

For Git users, or users of other versioning systems (hopefully everyone):

16. Keep changes in separate commits
It’s easy to keep on working on the same commit, but it gets more painful when you need to revert.

17. New feature = new branch
Unless you want to do it the hard way, of course.

18. Try to merge the main branch to your feature branch as often as possible
It makes life easier when you need to merge it back to the main branch.

19. When committing, do a git diff, and read it!
It helps to double-check what you just did and sometimes to clean the code too.

20. Write meaningful commit messages
No, “fixed bugs” is not sufficient in most cases.

21. Do not alter too much the merge messages
They can contain useful information by default.

22. When doing a big merge, create an intermediate branch
If you’re merging B into A, the intermediate branch is basically a copy of A where you merge B to see if everything goes well.

Bonus: don’t push something live on a Friday night, or right before your holidays…
Unless you really want to spend time on it when you shouldn’t, that’s up to you :)

Most importantly,
Stay curious, be consistent, be sensible, have fun!
If you don’t know something, Google it or ask someone.
And try to learn something new every day!