How Coding with QA in Mind Has Made Me a Better Developer

I used to feel nervous when my code entered quality assurance testing. Early on in my project, when I ran into a scenario I didn’t fully understand while coding, I often made what felt like a reasonable assumption and moved on.

The Mistake

If I wasn’t sure how something would behave with a certain kind of data, I told myself that quality assurance (QA) would catch any issues later if necessary. At the time, that felt efficient. In reality, it sometimes led to rework.

Early in my career, I understood the importance of asking questions. Even so, I didn’t always ask them. Sometimes I worried about looking inexperienced. Other times, I didn’t want to slow down my team or bother the client. If an issue seemed like a small edge case, I often decided it wasn’t worth digging into.

Over time, working closely with QA helped me realize that I shouldn’t ignore those moments of uncertainty. When I didn’t know what would happen in a specific situation, I wasn’t facing a future QA problem. I was uncovering a gap in my own understanding that I could address earlier.

The Pattern

I started noticing a pattern. QA would test a feature and ask questions like, “What should happen if this value is missing?” or, “How is this supposed to behave with this edge case data?” My answers often began with “I think” or “I’m not actually sure.” Because of that uncertainty, I had to confirm expected behavior with the client after merging the code.

In the best-case scenario, my assumptions matched expectations, and no changes were necessary. Cue the sigh of relief. In other cases, I needed to make a modification that sent the card back into the workflow and wasted time I could have avoided. A one-line change would have taken minutes to fix early on. Now, it could hold up a feature for days.

Today, when I implement a feature and realize I can’t confidently explain how it should behave with certain test data, I stop and investigate immediately. When I take time to think through possible edge cases, I often catch these uncertainties while writing unit tests before I write the production code. I’ve found that test-driven development helps encourage this approach.

From there, I reach out to design, QA, or my teammates to see if they have insight into the desired results. This takes more time up front. But, that effort is minor compared to the time I would spend reworking code later. The key difference is that I now resolve uncertainty early rather than handing it off.

The Result

This shift has changed how I write code. I pay more attention to edge cases and think more carefully about how data flows through the system. I focus on writing code that’s easier to reason about, not just easier to get working. When QA starts testing, we run into fewer surprises, both for them and for me. And when a rare but inevitable surprise does appear, I have the context and understanding of my code and decisions to move forward confidently.

Coding with QA in mind hasn’t just reduced rework. It has improved collaboration. When QA understands the intended behavior, and I understand how the feature will be tested, we work toward the same goal instead of reacting to issues late in the process. That shared understanding builds trust and makes the entire development cycle smoother. Asking clarifying questions without fear has also helped me grow more confident early in my career and build trust with my team and clients.

The biggest lesson I’ve learned is to pause when I don’t know something. Instead of pushing forward with assumptions, I now take time to investigate early. That shift leads to better code, clearer expectations, and more confidence in what I ship. Coding with QA in mind didn’t just make my work easier to test—it made me a better developer and teammate.