I’ve been at the new job for almost three months now. That’s long enough to at least learn the office layout, figure out the coffee maker, start comprehending the codebase, and occasionally have some delusions of adequacy when delving into a new bug. Since we’ve been hiring developers like mad, it’s also plenty of time for me to have gone from the team’s FNG to just another dev.
At the new gig, standard procedure for newly hired developers is that we spend the first three months working the support queue. That allows us to get a feel for a lot of different pieces of our large codebase. As it turns out, it’s also a good fit for an ex-QA person who made a pretty good career out of tearing apart issues to find the root of the problem. Which brings me to the point here, three ways that a stint in QA helps as a software developer.
- Debugging Other People’s Bugs. Here’s the thing about support queues: these aren’t usually bugs that we write. In that regard, the main difference between dealing with bugs I didn’t write in QA, and dealing with them now, is that instead of validating them and passing them on to a dev for resolution, I’m validating them, fixing them, and passing them back to QA for verification.
- Respect the process. I don’t think we’ve had any problems with this in my current team, but I definitely remember times at previous jobs where devs and QA didn’t get along well. I may even have been part of the adversarial problem in my younger years. That said, I do feel that having been on that side of the fence gave me a better understanding of how QA would like to be treated, and how to talk to folks over there.
- Don’t Take It Personally. Getting your fix sent back because QA found another issue isn’t because they hate you personally. It’s just their job.
