Test it manually. Even if you wrote and ran automated tests, test it manually at least once before you ask for a review. Record yourself testing it manually. You’ll be surprised by what you find.
Think through the edge cases. That doesn’t mean you have to handle them all right away, but you should have an answer to them.
Every time you add a test, actually test that it would fail. Yes, literally: go and comment out the code that you think makes the test pass, then run the test, see it fail, comment the code back in, run test again, see it succeed. Only then have you written a test
Coding Etiquette
Keep your change free of unrelated changes.
Make sure that your PR is up-to-date against latest on your main branch.
Before you comment on something, read the whole thing.
Write bug reports that are clear and understandable. Don’t write “it doesn’t work for me.” Give the reader information on what you did, what you expected to happen, what happened. Think about what might be useful to debug this, then put it in the ticket.
Bonus points: try to find a minimal set of steps to reproduce before you open a ticket.
Read the error messages.
Read the manual, the docs, the instructions, the ticket.
Don’t ask for “quick” reviews when you never review other people’s code.
Know why your fix is a fix.
Design
Understand what problem you’re solving. Knowing why you’re doing something is a requirement to knowing whether you’re actually solving the problem.
Workplace
Accept that sometimes you’ll have to do things that you don’t find interesting or exciting or that don’t bring you joy. Sometimes it’s just work.
Do the homework before the meeting. You’ll stand out.
Be on time.
Do what you said you’ll do. If for some reason you can’t, let the person assuming you’re doing something know about it.