Taro Logo
2

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

Profile picture
Entry-Level Software Engineer at Taro Community13 days ago

Basically, I feel like I have so many unnecessary ‘DUH! I can’t believe I missed that!’ moments in public -- mainly when asking for help and creating PR's.

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.

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.

When this happens, it makes me feel like my work isn’t thorough or to a high standard, not mention making me look bad. So it’s something I’d really like to improve, but it seems when I focus on being thorough it perpetuates the problem like in the two examples above.

I feel like I need some checklists/processes as guardrails for common scenarios (e.g., creating PR’s, asking for help) I can fall back on, because otherwise I feel my brain will keep missing things and making easily preventable mistakes.

71
3

Discussion

(3 comments)
  • 0
    Profile picture
    Engineer @ Robinhood
    12 days ago

    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.

  • 2
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    12 days ago

    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:

  • 2
    Profile picture
    Eng @ Taro
    9 days ago

    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 :)