Are you aware of the movie, Snow Day?

Well, if not, sorry. Major spoilers in this article. You've been warned ¯\_(ツ)_/¯

At the start of the movie, all the characters wake up to the aftermath of a massive snowstorm. School's closed for the day. We find out the main character, Hal, has a big crush on Claire, the popular girl at his school. He's determined to make her his girlfriend. His best friend Lane is annoyed by this. She secretly likes Hal and wishes he would see her as more than a friend, but we find that out at the very end of the movie (see? spoilers).

My career journey is a lot like Hal's story.

My "Claire"

Web Development is the popular girl in the tech job scene for people who like to write code (for non-coders, it's Web Design). Just like most "junior devs" or "aspiring devs" on Tech Twitter, I was obsessed with landing my first web dev job to break into tech. I didn't see any other option.

If you follow the #100DaysOfCode hashtag or the freeCodeCamp community, you'll see a horde of starry-eyed dreamers making 25 calculator and to-do apps in React trying to get a hiring manager to notice them.

I was that starry-eyed dreamer.

I made 15 projects on freeCodeCamp, most of them with a garbage design because, frankly, I have zero design sense. This is how I got 3 freeCodeCamp certifications that showed off my ability to use HTML/CSS/JS and React.

Oh, you want proof, do ya?

Check out my cringey first portfolio website and click through the Projects section.

Didn't click that link? Fine, here's my Drum Machine project.

Clearly I'm a design guru.

But hey, it somehow still passes the freeCodeCamp unit tests 4 years later.

Unfortunately, all the hard work I put into those projects didn't land me a web developer job.

• I worked with multiple recruiters to automate some of my job search

• I researched self-promotion strategies to craft a better resume, cover letter, and LinkedIn profile

• I navigated multiple take-home assignments, phone screens, and even got 2 whiteboard interviews

Nobody wanted to hire me as a dev.

This might not surprise you given the "high quality" of my projects, but that's also kinda the point I'm trying to make here.

It's hard to be a good front-end developer these days.

You need to know how to build projects with in-demand technologies, but you also need those projects to look presentable and to solve actual problems with your code. You also need to show your competence with APIs, CI/CD pipelines, and it definitely doesn't hurt to know your way around basic back-end development.

But I thought those were just suggestions. I didn't really let that sink in because I thought web development was my only path to a high-paying, satisfying job.

Much like Hal, I was determined to make my dream come true.

My "Lane"

Of course, it wasn't going to be that easy.

Like Hal, I experienced setbacks along the way.

But like Hal, I was clever.

I thought that I could leverage my customer service experience in combination with my new web development skills to get in at the ground floor of a tech company.

It worked. I was able to get my first tech job as a Support agent at Fetch emailing users.

I did a good job and in 6 months, my manager asked me to try applying to the Back-End Engineer Internship that was opening up to internal employees.

Yet again, I was rejected. My algorithm worked, but I didn't include the package.json file that allowed my interviewer to run my project. Classic "junior dev" moment.

My interviewer told me I had potential, though, and I should apply for the QA team because I seemed technically competent.

I didn't even know what QA was, but I applied and after a few interviews, I got the job.

Even though I was getting paid my first salary to test software, I didn't appreciate what was right in front of me. I still wanted to become a web developer. Even after I got the QA job, I kept learning Node.js to sharpen my back-end skills.

You see, QA was my "Lane".

QA was a good friend to me in my time of need, no matter how little I appreciated her. Great salary, great team, great benefits, and best of all, I even got use my web development skills to make internal QA tools.

Only 3 months into my QA Analyst role, I noticed the QA team was using a basic web tool to generate fake receipt images. This is how they could test submitting a paper receipt in the app. It was super clunky and we were limited in what we could test with it. Having built several web apps, I knew I could make it 10x better in a matter of weeks. I asked my QA Manager if I could remake it with extended capabilities.

He said yes.

I used React to rebuild the app with 100x the features of the original, at first by myself, but eventually with the help of other full-stack devs & automation engineers. It wasn't just a fake receipt image generator. It was an advanced dashboard with tons of presets and toggles, with virtually any receipt image scenario you could think of. It's been almost 4 years since I started building it and the team is still using it today.

Getting to build this tool was immensely satisfying because I was technically getting paid to be a web developer in QA, and as a bonus, I didn't have to use the old tool anymore. All of us were saving countless hours and getting to test way more scenarios than we were able to before.

Somehow, in spite of all that, I still thought I'd enjoy web development without QA even more.

I spent 1 year learning manual testing as a QA Analyst, and then another year learning test automation as a QA Automation Engineer.

Around the time I started learning automation, the company had brought in their first web developer. By the time I had been writing code in QA for a year, they were looking to expand the web development team.

At that point, I was getting paid to write code on a team, so I figured it'd be easier than ever to land myself a web developer gig. Meanwhile, doing QA Automation work was making me happier than any job ever had.

But I didn't care. I was obsessed.

Getting the Girl

I asked my boss if I could try web development, and he worked with the Front-End Engineering team to set up the first internal Front-End Engineer Apprenticeship.

I was told I'd be focused 100% on Front-End and was taking a break from QA during that time. My title was changed to reflect my new role. All my QA meetings were replaced with Front-End meetings. I was going to be fully immersed and treated as a full member of the Front-End team.

I was a web developer now.

I was a web developer for 6 months. It was the high-point of my time at Fetch.

To all my coworkers, I had done the impossible:

• Moved from Support to QA

• Moved from QA to Dev

I showed everyone in Support that they could be in Engineering, and I showed everyone in QA they could be developers. Everyone treated me like I was some kind of hero for showing people what was possible.

But under the surface, I wasn't so sure I had made the right choice.

Did I Mess Up?

As I spent more time doing web development work, I realized it wasn't what I thought it would be.

At first I thought I was just experiencing growing pains. Lots of new stuff to learn, the drastic context switch from QA to Dev. On the surface, it made sense.

But over time, as I continued to receive praise for the work I was doing, I started to realize it might not be a skill issue. I turned my gaze inward and realized there were a few things that weren't lining up for me.

Wrong Customer

While it felt cool to finally use my web dev skills to contribute to a company website and internal dashboards used by other teams, it all felt very impersonal. I felt far away from the people I impacted with my work, even if some were just a Slack message away. The only "user" I interacted with on a regular basis was the QA Analyst testing my work.

I found out the hard way that I'm not interested in helping people I'll never meet. I like to see the impact I'm making and meet the people I'm impacting. I like to personalize my impact to the person receiving it. That's not something you get as a web dev unless you're doing 1:1 client work.

Funny enough, this inability to personalize my impact is exactly why I decided against becoming a public school teacher, even though I got my degree in Spanish Education.

Wrong Vibe

Honestly, I understand why we write unit tests -- they're faster and cheaper than end-to-end tests -- but I hated writing them. Unit testing often felt like it was more useful for enforcing "testable code" than for testing anything real.

The devs weren't interested in sanity-checking their work by hand before handing it off to QA. I felt like the Devs took pride in reducing the time they spent on testing anything at all. Their stance on this was:

"QA tests better than us. We should let them do it."

I think this is true up to a point.

Anyone can take 2 minutes to run through the happy path of their work before giving it to QA. Or god forbid, run npm test before making a PR.

I reviewed a PR once that had failing unit tests. I can't even.

And the only things we ever collaborated on as a team were code reviews. There was no recurring event where everyone pitched in, and pairing up on projects wasn't a thing. There was a very self-sufficient vibe and everyone tended to prefer to do their own thing. Sure, we had happy hours and team outings, but that didn't make up for the day-to-day.

After enjoying more of an "all hands on deck" community vibe in QA, this didn't feel great. The work felt shallow. It felt lonely.

Wrong Product

What I realized about my desire to be a web developer was that I was so excited about the process of building web applications, I was missing the point of web development from a business perspective.

Devs make the company money. Devs give the users more power to do more stuff, which makes them want to stay engaged. More engagement for a mobile app company means more money. If you take longer to ship new code, you're taking longer to make the company money.

Leaner teams and leaner processes move more quickly. That's why devs delegate testing to QA. That's why devs need to be self-sufficient.

I didn't really care about making the company money, though. I didn't care about empowering some random person I'll never meet, either. My value system was apparently at odds with being a Dev. No wonder I was so stressed out!

The web developer job I had fought so hard for didn't make me happy.

I started to miss QA.

We're More Than Friends

In Snow Day, Hal realized after he'd gotten to know Claire that they had nothing in common. He realized he might have been ignoring the connection he had with Lane.

As soon as I'd realized this wasn't going to work out, I hopped on a call with my Front-End manager. I told him the short version:

• I'm not as happy as I thought I'd be

• I prefer QA to Front-End

• I want to quit the apprenticeship and go back to QA

He was very surprised by this. I was apparently doing a great job, and he hadn't gotten any indication from me that I wasn't enjoying myself. To be honest, I was as surprised as they were.

When Hal told Claire about his concerns, she reacted the same way my Front-End manager did.

He believed it was good for me to follow my passions and if they were in QA, I should go back to QA.

At first, Hal had to convince Lane that his intentions were pure. She had been friendzoned for so long that she didn't think he'd ever want to be more than friends.

My QA Manager had tried to talk me out of leaving the apprenticeship because all I'd ever talked about was becoming a web developer, but after our conversation, we knew it was the right move for me.

And I lived happily ever after in QA.

I went back to my QA Automation duties, and I began to reflect further on why I enjoyed QA, and if it was truly where I wanted to build a career.

We Have Something Special

Analyzing what I didn't like about Web Development made it easy to understand what I liked about QA Automation.

Right Customer

QA Automation served the team, even if they indirectly served the users and the company.

My customers were my QA Analyst, my manager, and the developers.

Since I worked with all of these people every day, I was always able to see my impact on their lives and get direct feedback on how I could make that impact even better.

Right Vibe

QA Automation was a little bit island-like at times when we worked on tests specific to our pod, but there was a collaborative team culture overall.

We helped each other debug confusing issues. We wrote wiki articles to share knowledge with each other. We collaborated on fixing and maintaining tests, so everyone had some shared knowledge and responsibilities. We even had an apprenticeship I co-founded where we taught our QA Analysts how to do QA Automation, with the goal of increasing the automation talent on the team.

We weren't concerned with speed as much as we were with quality, but rewards came to those who could balance the two. We never considered moving fast at the expense of quality, though. And we were never too much in a hurry to help out a fellow QA if they were carrying too much.

Right Product

QA Automation delivers time & confidence to the team via test automation infrastructure.

When I write automated tests, I'm helping QA Analysts do less of the same manual tests every release, so they can use their time for more valuable exploratory testing.

When I make it easy to access test results with my reporting, I'm giving my manager information to make informed judgments on product quality.

My test automation also gives the developers confidence in the work they do, because they don't need to rely exclusively on unit tests to ensure old functionality is still working properly.

The QA Automation Advantage

These days, everyone wants a job with work/life balance, the ability to work remotely, and a good paycheck.

Because QA Automation is not public-facing, we don't have to worry about the demands of the users or the deadlines set by the company. As a result, we don't feel deadline pressure the same way devs do, because we aren't responsible for meeting the deadline. We're responsible for communicating defects found by automation that could affect the deadline.

We need to understand how features work so we can automate testing for them, but we only automate testing for features once they're stable. Then we watch to make sure the features don't break, and that our automation remains effective at catching defects.

It's a much chiller gig. For cloud-based applications, all of our work can be done remotely. It's only with IoT companies with hardware-integrated software that you might need to be on-site to automate testing.

And the pay is good. Almost as good as devs. QA Automation Engineers make 6-figure incomes early in their careers. The pay disparity comes around the Senior level, where you can see Devs making 200k+, whereas QA Automation doesn't typically go that high unless you're at a MAANG company.

But for most folks not living in expensive cities like San Fran or NYC, 6 figures is a comfortable life. It's more than enough to afford vacations and an early retirement.

And it comes without all the stresses that Devs typically endure.

So that's why I'm a QA Automation Engineer.

I get to write code for the people I want to serve, and I get to have work/life balance, location independence, a great income, and a career with plenty of variability and growth opportunities.

Why do you want to be a Web Developer again?