I have terrible attention to detail - how can I fix this?

Before I give any concrete advice, I just want to say that it feels like you're beating yourself up too much over this and you seem like a good engineer with good instincts 😊

For what it's worth, it's common for engineers around your level to keep missing stuff. Most of my E3 (junior) Meta mentees were still making basic mistakes 6-9 months in, and you're in that range for your current job. I did have some mentees that stopped making basic mistakes 3 months in, but they had a natural talent 99% of engineers don't have, myself included. It's not reasonable to compare yourself too stringently against those people - It's not realistic.

You've gotten good reviews, even getting "Exceeds" sometimes, so I don't think this is a huge cause for concern. Make sure to follow the advice in Taro around avoiding a PIP (maintain a transparent dialog with your manager, probe for feedback, be humble), and you should be okay!

When it comes to advice, here's my biggest one: Write stuff down.

This manifests across 3 stages:

1. Before the code - Make sure that the task is crystal clear. In particular, you should understand the full feature set that stakeholders want you to build out. After that, outline your approach (including the edge cases) and get feedback.
2. During the code - Submit a clean, well-documented PR. Keep doing the self-review that you're already doing. When people comment on your PRs, push them for more detailed explanations if you don't both fully understand their feedback and how they got to it. Every PR is essentially a valuable artifact of documentation.
3. After the code - If a PR didn't go well because you missed a lot of stuff, write it down. This one is the most important; you need to ensure that you're learning as much stuff from your mistakes as possible. Over time, you will assemble a giant "Stuff I've Missed" journal. Look over that journal before you submit any future PRs.

Here's 2 more threads that I highly, highly recommend:

• "Tips for someone with poor working memory?"
• "How to ensure mistakes do not repeat?"

Zooming out, most engineers severely underestimate the amount of non-code writing they need to do. If you work at a good, fast-moving, modern company in particular stuff will move fast. Only the most brilliant geniuses will be able to keep up through sheer perfect memory - More "normal" people like us need to rigorously and constantly leave behind a trail of high-quality documentation to keep up. Writing is one of the most important skills for any human to develop though, so it's not a waste!

After you go through the related discussions, I highly recommend the code quality course too: [Course] Level Up Your Code Quality As A Software Engineer

Final note: There are non-tactical reasons for a sub-par memory. In particular, if your overall well-being isn't in tip-top shape, it is easy for your brain to fall behind, especially if it's super stressed out. Make sure to take care of yourself outside of work:

1. Get a consistent 8 hours of sleep
2. Stay hydrated
3. Exercise regularly
4. Maintain a thriving social life

More thoughts here: "How do you make sure you stay healthy as an office worker?"

I dig into all this more in-depth in my productivity course too: [Course] Maximize Your Productivity As A Software Engineer

For instance, I always review my own PRs myself before sending to reviewers, and clean up plenty of issues I notice myself. But then my reviewer will point out some kind of bug, or something I forgot to do, and in retrospect it will be immediately obvious to me. Alex often mentions the importance of being able to get most of your PRs accepted in one attempt, but for anything > 30 lines this simply feels like a pipe dream because I am so terrible at noticing things until it's too late.

A lot of this comes down to experience. Reading the above, I'm hearing that there are two categories of issues in your PRs, bugs and forgetting to do something.

For the bugs, you could have syntax bugs or functional bugs. The syntax bugs should be avoidable with linters or a code formatter. For functional bugs, it helps to try to brainstorm all of the ways that your solution might not work before you ever start writing a single line of code. Why do this before you start writing the code? Because finding an edge case might drastically alter your solution.

For the issue where you forget to do something, it helps to have a checklist that you go through when completing a specific task. Bonus: if you can help to automate these procedures, you'll be a hero among your team, and since it impacts many engineers, it can help with career progression. Having to change a config in production to verify your shipped feature sounds a little bit iffy. I don't have all of the details, but it makes me wonder whether there's any way to improve that process.

I realized mistake I made (ran a command to change a bunch of files in the wrong directory) but only after the fact, and it cost me embarrassment and extra work.

After I complete a task, I go through the list of "things that could go wrong" that I made before I started coding up the task. And, I make sure that my solution addresses all of those issues.