There's a lot of feedback already in this thread, but if you're still reading, I wanted to share my process in case there's anything that was missed. This will help you, hopefully, fully complete issues the first time. Don't let any of these points block you, but you can generally go in this order.
1. Make sure you understand the requirements for the issue at hand.
Make sure you correctly understand all of the work an issue is supposed to encompass and no more. Use all available documentation, issue descriptions, designs, notes, and any other resources. As a last resort, as in the project is not well documented, start putting together questions to ask someone. Craft your questions in advance and ask them strategically and it will save you time. This is not all on you, better documentation, grooming, and other processes can help you work faster, and it might be something worth bringing up at a retrospective or using any other avenue you have for feedback after some research into what exactly is going wrong and what other people have done to solve it.
2. If you haven't already, start looking into completing the issue from a technical standpoint.
No issue exists in a vacuum, and there is probably already existing technical architecture surrounding the issue, or something similar that is already being done. Good code conforms to the standards around it, and a good team codebase looks like it was written by one person. Not copying code, but using it as a general blueprint can help you get past code review by following unwritten established standards of the team. Of course, if there are written standards, check those too. Make sure you understand all of the technologies used by the code you're following, it probably has documentation. Try to understand any technical decisions that don't seem clear. Follow the guidelines in the previous point for asking questions if you need to. If any technical decisions need to be overturned, consider making refactoring part of the issue if at all practical (this is a whole other can of worms, so you'll forgive me if I don't get too deep into it).
Keep in mind that version control tools can help you understand why a decision was made, particularly if you learn to use tools like `git blame` and `git log` (assuming your team uses git), or even more powerful integrated tools like [vim-fugitive](http://vimcasts.org/blog/2011/05/the-fugitive-series/) or [magit](https://magit.vc/manual/magit/index.html#Top) if you use something like VIM or Emacs.
If there are any new technologies and technical decisions that are part of your issue, try to gain a rough idea of what your implementation will look like and try to learn as much about the technologies as possible. If you are not in a decision-making position, it is best to run your ideas past someone who does once they are concrete if you can. Of course, sometimes, it is easier to just start writing code. How low level or high level your planning is up to you, but it should probably depend on the complexity of the issue at hand. Don't be afraid to take a couple passes at it, better now than later.
3. Start implementing.
When you are actually writing code, a good process makes all the difference. Some people use [TDD](http://agiledata.org/essays/tdd.html) or write all of their inline documentation ([example](https://jsdoc.app/)) beforehand, which can help you quickly refine and complete your implementation details without actually writing any code yet. This, again, helps you rework your ideas early on in the process. I use a mix of documentation, testing, and any [REPL](https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93prin...) that's available to me to test out code beforehand depending on the issue, which is not the most straightforward method. Try TDD at least once and see what works for you.
A good dev system can help a lot. If you can get the code into a working state and compile it often to test it, do so. Any other dev tools for testing, documentation, linting, debugging, etc. for the project, learn them and use them.
Once you're done making some changes, look over your code. Clean up anything you can, and don't be afraid to make another pass at it if you need to, especially early on.
Planning out how you're going to get things into a working state and split up your changes (commits in git) early can sometimes help, but sometimes it's easier just to clean up your commit history later as you're reviewing your changes (getting familiar with `git rebase` can help with this).
4. Submit your merge requests/pull requests.
If you can at all, get your code into a working, logically separated state often and submit small merge requests/pull requests often for review. This can help you correct your tragectory early on if you still need to take a different direction. Familiarity with git or the VCS you're using can help a lot with dealing with multiple branches of code. As with all things, give your pull request one final look-over before you submit it for review and clean up anything you need to.
tl;dr: understand everything you can, ask questions, plan ahead, take multiple passes early, and make small changes