Ask HN: What is a day in the life of a Q/A role like?
I’m not sure Q/A analyst is quite the correct term for the position I’m interested in, but I was technically a Q/A dev for about three months at one place I worked, the first one actually. After 15 years in the industry I realized that I could care less about “making” things; all I care about is “fixing” things. In other words, I’m only interested in pure problem solving, such as fixing bugs—the harder the bug, the better. But I’m not sure this is all Q/A roles do exactly in practice, so before I apply to a position, it makes sense to understand what I would actually be doing, day to day.
In a perfect world, I would be content and at home if all I did was clear out the bug backlog and nothing else. I don’t want to “maintain” software, I don’t want to “build” software, I certainly do not want to be “rockstar” messiah.
I’m really not the best judge of code quality to be honest, it’s way too political a subject in my opinion. Once the puzzle is solved, I could care less about the quality of software in general, and move on to the next mystery. As a typical engineer, I found myself at odds, on one hand developing software from end to end satisfied my creative side, but I always found myself over engineering things. Eventually I got fired for this reason, after eight years at a company I helped build, because I was only interested in getting to the root problem of software in general, not the task at hand. Furthermore, I became furious when I was asked to solve the same bug twice, and realized that I was working in a feature factory, yet I was always the person everyone turned to last, when all else failed, but always the first person to blame for not doing my job. There was never a bug I couldn’t and didn’t solve—my track record was flawless.
Now, I look back to that Q/A position, and ask myself had that not literally been my first job as a developer, would my life be any different. I haven’t written a single line of code in a year and half. I’m not sure how I could justify the past year or so during during an interview other than that I learned that software is a losing battle and a cause that has lost its way. I may be better suited in another industry such as mathematics, but for the meantime, I don’t mind occupying a company’s underworld as satan, damned to blasphemy, doing thankless work the rockstar gurus are too important to do. Credit doesn’t matter to me anymore, I’m not even in it for the money, it’s simply a matter of principle. So long as I get paid to solve a problem and not code one, that’s all I ask. You should try embedded systems work, Board Support Package (BSP) development, in particular. BSP development is about adapting an OS to a particular (usually new) board design/implementation. You have to understand how the system works from a bare-metal perspective, and most everything is problem-solving. The guiding motivation is what I came to call FIO "Figure It Out" -- often with little and/or poorly written documentation. It'll get you deep into the kernel (of whatever OS), device drivers, chip specifications (architectures, register configurations, modes of operation, ...), SoC's, microcontrollers, ... It's a fascinating, though low-level, world. I advise this sincerely, as I did it for 10 years, and enjoyed it a lot. However, I got myself back "above ground" and into systems and apps again, because my inclination is actually exactly the opposite of yours: "I could care less about “making” things; all I care about is “fixing” things". Over time, although the gratification of getting things to work remained, I grew tired of FIO every. single. day. I longed to again design and create solutions -- to "make" things. Different strokes for different folks. Best of luck to you. Excellent advice. You ultimately can’t argue with a machine after all. I feel I should tell HN the circumstance under my termination for posterity. I was assigned a bug to fix on a new system that was designed in isolation by my coworker. After about a day, I realized that the bug didn’t exist. The bug was actually a large feature my coworker never implemented, but no one noticed, because it was on the back end. My coworker was severely autistic but could function if he didn’t need to communicate with others and often had fits. Because he was the first employee, my boss didn’t realize this fully until I was hired. Some months prior, my boss had told me the coworker was slated for termination, as he was bringing more developers onboard, but this was supposed to be down the road. Knowing my disabled coworker would be fired if I told the truth, I did what I thought was the responsible thing, and quietly worked on implementing it at night. However, after a week, my new manager was irate with me on why the bug wasn’t fixed. I was forced to tell the truth but was sleep deprived and lost my temper for the first time in my career. As a result apparently my manager didn’t understand what I told him, and because he was the younger brother of my boss, I was terminated instead. Maybe it was for the best, but sadly I heard that my coworker was fired about three months into lockdown, I was terminated the very day lockdown began. He will never find another job, but I will. Not long after that I heard my manger quit for a better paying job. Am I the asshole? At any rate, I think you’re right, but how hard is it to break into embedded programming? I actually started learning OS design not long ago and finished learning C and Rust, but never considered it an option career wise. QA is a bad role. I’d never recommend it to anyone. You are always the messenger that gets shot and you get fired for both being too good, too bad at your job and being unlucky. Never let friends go into qa. Isn't it the same for software developers with bad managers or companies with bad cultures? I'm a senior tester among other things and was never shot or fired, if anything I help teams understand that testing is a team's task and not of another person or team Yeah if you are in one of the few companies with really healthy internal culture and good management it should be fine but the Qa role is one of the first that breaks down when that stability breaks Usually QA is used to describe test positions, is that what you are aiming for?