What systems can I put in place so I make fewer dumb/obvious mistakes?

I can empathize because I have struggled with this before. Looking back, most of the time it occurred mainly because I was anxious:

• I just wanted to churn out work ('churn', implying quantity, often sacrificing quality)

• I felt hurried because the task seemed challenging given the time I committed to completing it (poor story-pointing)

• There was a lot more on my plate than I could realistically handle

• I was not staying true to my focus blocks; my mind was scattered and I was multi-tasking

As per Alex's advice, I compiled a checklist that helped me be less absentminded. I also needed to recalibrate and ask myself, where my attention was; do I care about what I'm producing or am I distracted by trying to look good (in vain). From there, I am reminded, take a deep breath and proceed with a calmer mind.

And some actionable stuff:

• Creating the PR in 'draft' form early on and code-reviewing myself at the end of the day
• Creating a type of design document before tackling the task and sharing it with my team to get feedback or ideas early on
• Pairing with peers on a regular basis
• Code reviewing other PRs every day

The last two have been especially helpful. It allows me time and space away from my work (tunnel vision), and not only learn from others' thought processes but gives me perspective that when I return to my stuff, I can be like, "oh I forgot to do that" or even, "I noticed how annoying that was on that PR, I now won't forget to do that this way instead".

I think you already have the solution - You just need to make it. 😉 I would create a checklist document as some sort of personal note (it can even be hand-written if you're hardcore) and then run through that as you're doing any task. From your question, I stitched together the context and added some of my own items to make this:

1. Read through the entire task
   1. Understand the product context
   2. For any unclear parts, ask the team about them
2. Come up with a plan
   1. Break down the task into small chunks until each chunk would only take 1-2 commits to finish
   2. Have overall approach (e.g. what files to chance) and edge cases to look out for
   3. Socialize it with teammates and talk pros/cons
3. Write the code
   1. Make sure you're on the right branch
   2. Stick to the plan and don't get distracted
4. Submit a pull request
   1. Run the linter
   2. Have good commit/PR titles
   3. Attach the context
   4. Record a great test plan and share that too

I recommend going through these as well:

• [Taro Top 10] Becoming A Better Coder
• "How to ensure mistakes do not repeat?"
• "Tips for someone with poor working memory?"

For example, I recently was so focused on the more difficult part of a ticket, thinking about edge cases and trying to really polish this bit of functionality, that I spaced on reviewing the ticket before creating a PR. This meant the lead engineer reviewing my PR had to explain to me that I missed some other aspects of the ticket.

I try to brainstorm all of the test cases I want to go through before even starting the task, and I write them down in Notes/Notion. I will add on to this list as I'm working through the code because you'll think of different edge cases as you do work through the code. I make sure to manually test those different edge cases before I create the PR.

As part of the above process, you can translate the requirements from the ticket into more bullet points to testing in your notes app.

It also doesn't hurt to re-read the ticket when you add a reference to your PR on the ticket.

Another time, I spent a while trying to right a really good question about a solution to what I suspected was a tough issue. The problem? I hadn’t thought to test my hypothesis and confirm that this issue would occur (it didn’t) before formulating and asking my question. So I needn’t have bothered anyone else or myself about navigating this hypothetical problem.

Before I ask someone a question, I try to think about what answers or questions the person might respond with and how I would respond to their hypothetical responses.

In this case, you would imagine a fictional person asking you what error message you were seeing when you tried your hypothesis, and you would have realized that I need to actually try this flow so I can get the error message. But, when you try it, you would see that you wouldn't run into the error.

but it seems when I focus on being thorough it perpetuates the problem like in the two examples above.

It's good that you are thorough! You just need to refine the system you are using :)

Given that you're able to focus down on 1 specific piece of the ticket, maybe you should just break down your tickets further? The smaller something, the easier it is to focus on it.