Code Review Q&A and Videos

I'm sure Alex and Rahul talk about this in their , but wondering how to write clean code, particularly in the context of someone who doesn't have technical people available to review my pull requests in my work or in side-projects.

I'm sure this skill is almost entirely developed by working with talented people and writing a lot of code, but is there a place for resources like "Clean Code" the book or courses on Udemy?

How do you keep up with everything that is happening on the team with different projects, doc designs and code reviews?

My team owns a really wide set of features spanning across multiple repos and programming languages (C++, React, Angular). On top of that, each person works on pretty different areas (telemetry/data, UI components, client side api, etc.). We have a v1 of the app being maintained and a v2 currently being developed with some people working on v1 and some working on v2. It's impossible to know all the context behind every pull request.

How can I give quality code reviews? At most I can only provide feedback to simple code logic and really well written PR descriptions. Should I be trying to private message the developer for each PR to understand more, or is this just something that comes with time?

I have been seeking to develop habits / follow a system to increase code quality, both in terms of readability and number of functional issues. I have come up with a few ideas I have listed below but I am curious what other people have been trying out! Have any of the below worked for you? What specific steps do you take to ensure code quality?

1. More awareness while writing code: it's tempting to write a rough draft version of the code thinking you will polish it later but oftentimes it's easier to spot mistakes while your attention is on the erroneous line of code. Example of this in action: search for where the method you're modifying is used in the code base before making changes to it.
2. Do not submit the code for review immediately after writing the code. Give yourself a short break, come back and review your code with a fresh mind, which will make spotting bugs easier.
3. Write down the possible edge cases in a notebook before submitting the PR for review. For medium to large PRs, the process of writing itself can help you consider more edge cases than simply keeping them in your head.

Often we talk about how, when getting feedback during a PR or Design Review, there are mistakes that I have seen, at least in my case, creep up repeatedly. Any tips to ensure that the learnings stick?