This is a general list for programmers. Feel free to post your own so it can be added to this list!

-1: Check the docs.
0. Avoid using globals except when nessasary.
1. Keep functions and routines small.
2. Don't add comments that "explain" code.
3. Use the proper types for your variables.
4. If you think your code sucks, it does.
5. Have fun.
6. There's probably a better way and
7. it's probably on stack overflow.
8. Write code for humans, not compilers.
9. Back it up.
10. If it doesn’t compile, you’re probably missing a parenthesis or semicolon.
12. Do not be afraid to ask for feedback from the community, but don't be obnoxious or expect any feedback at all- if people have some, they'll give it to you.
13. DEBUG^10
11. Don't forget how to count.
14. Use a clear, explicit naming scheme for variables, functions, and assets.
15. Use slight variations to specify what things are.
16. When debugging, check everywhere for data modifications, not just the main() function.
17. Life isn't an exam, you can phone a friend.
18. Separate your concerns (follow an architectural pattern)
19. For comments, quality over quantity is key, have few very clear comments
20. Most code doesn't need to be extremely cleverly golfed and optimized
21. Write down your ideas
22. It is necessary that you know how to spell.
23. Begging for help makes people want to help you less- check out "how to ask questions the smart way", readily available in the signature of one of our admins.
24. When answering questions or helping people, don't be a jerk. Eventually, you will run into programmers that have a toxic, almost snobbish attitude towards others. Avoid this attitude like the plague.
25. Don't use jargon just to sound smart, or a tool just because it's popular. Use the best solution for the job, even if it is a normal word or an old tool.

Yes, keep functions small, like handle_pending_events().

Yes, see point 4.

6. There's probably a better way and
7. it's probably on stack overflow.
8. Write code for humans, not compilers.

9. back it up
10. if it doesn’t compile, you’re probably missing a parenthesis

2 is pretty close to being objectively incorrect, and 0 simply is objectively incorrect. If this list isn't going to be completely serious, please add a note of this to avoid people from taking this too seriously. Amends have been made, so I'm (mostly) satisfied now.

Maybe this:
12. Get feedback from the community for programs intended for release
13. DEBUG^10

I'd modify these as follows:

12. Do not be afraid to ask for feedback from the community, but don't be obnoxious or expect any feedback at all- if people have some, they'll give it to you.
13. DEBUG^10
11. Don't forget how to count.

14. Use a clear, explicit naming scheme for variables, functions, and assets.
Example: handle_pending_events().
Just by looking at it, I immediately know that it handles pending events.

15. Use slight variations to specify what things are.
Example: Capitalize Functions, not variables.
This helps reduce ambiguity in languages where parentheses specify both parameters and order of operations.

16. When debugging, check everywhere for data modifications, not just the main() function.

17. Life isn't an exam, you can phone a friend.
18. Separate your concerns (follow an architectural pattern)
19. For comments, quality over quantity is key, have few very clear comments
20. Most code doesn't need to be extremely cleverly golfed and optimized
21. Never push code that doesn't work

What do you guys suggest to someone like me - a beginner that has a few ideas that they couldn’t accomplish what I want to make in basic so I am trying assembly - what should I use to code in assembly? I have absolutely no clue. Please help I am really exited to get started

Another one though:
22. write down your ideas

Sure you can, but generally not on the master branch

Hehe... I may have inspired -1...

22. It is necessary that you know how to spell.

24:

Yes, keep your code obscure. /s

Back in my day we wrote code in Notepad

Also I agree SomeCoolGuy, why obscure your code?

Your code should be clean enough that it doesn't require comments to explain it.

Edit- also, it's like saying the same thing twice, it's inefficient and wastes both your time and mine.

Edit (serious tips):
11. Begging for help makes people want to help you less- check out "how to ask questions the smart way", readily available in the signature of one of our admins.
12. When answering questions or helping people, don't be a jerk. Eventually, you will run into programmers that have a toxic, almost snobbish attitude towards others. Avoid this attitude like the plague.
13. Don't use jargon just to sound smart, or a tool just because it's popular. Use the best solution for the job, even if it is a normal word or an old tool.

Edit for #24:
If you think you'll forget what some code does, a concise comment is probably a good idea.

14. Don't write code when you have something more important to be doing.
14.5 Don't write posts complaining about your own poor time management skills when you have something more important to be doing.

This is what I mean. And you do it all over the code I've seen