Wow Tiger, great summary! From your content and online presence, I can tell that you're always looking to level up your skills. I'm surprised you got through the course so quickly, and also surprised at how quickly you were able to produce this article as a "learn in public" milestone. I could learn a thing or two from that. Thanks for sharing your notes and thoughts on the course! I'm sure it'll be helpful to many people.

Just installed Brave, Spectacle, iTerm2 and Fig. Thanks for sharing all this!

Good to see you here! Nice article. Effective questions ➡️ effective answers ➡️ effective developers.

Nice article, David! And thanks for the mention, glad you're enjoying the course. 😄

Thanks for reading, Victor!

I'm happy your team has benefited from the course material! Thanks for taking the time to write this up, Mathieu. 😄

In mentoring junior engineers, I came to realize how common some of these are. Thanks for reading!

Hi Charles, thanks for taking the time to read! Best of luck with your remaining courses.

Thanks for this write-up! These are topics I've been looking to dive into more. XP isn't something we did much of at AWS, so it'll be good to learn what I've been missing.

Thanks for the shout! Nice article. Happy to see more code review content out there in the world. I liked how thorough your approach is — making sure to run the tests and linters, and also double checking diffs before opening the pull request. I also like how as a reviewer, you focus on the code itself, and not the person. This is key for building relationships with empathy. You also touched on the soft skills of humility, open-mindedness amd willingness to share knowledge. These will be key for growth in code review, as well as other aspects of your software engineer career. A few pieces of feedback: Take a look at Slack/GitHub integration. It'll automatically post in a Slack channel when a PR is opened. Looks like all review comment examples are questions. Questions are OK when the deadline is far away, but remember that they also introduce back-and-forth — this adds cycles and blocks the PR. Know when to use a question, and when to make a direct suggestion. The problem with pair reviews is that the reviewer has a person explaining the code, as they reviewing it. This is not a realistic situation. In reality, a developer will be reading the codebase on their own, as they're adding features. They need to be able to understand it on their own, and if they can't, it needs adjustment. Individual, async reviews realistically simulate this. If PRs are forgotten or ignored, there's a problem with the team's code review process that needs adjustment. Overall, awesome article! Thanks for sharing your thoughts, and for the shoutout! Good to be connected with you here on Hashnode.