This post is reprinted here with the gracious permission of my alma mater, The University of Pennsylvania. The original can be found here.

I was an English major long before I was a software engineer, so I am going to start with a spoiler alert: the mostly fearless hero triumphs by finding a career she loves.

Our story begins in the late nineties on a small farm in the boonies. Where I lived, we couldn’t get cable or broadband, and Wi-Fi wasn’t “a thing” yet. I was a voracious reader, so not having cable was fine. When I used our computer, it was mostly offline to write papers for school. I sometimes used our dial-up modem email friends, but that was about it.

Once I started my undergrad, I had my own computer (sweet!) and access to broadband in my dorm at Haverford College. The world was at my fingertips, but my computer wasn’t so great. My dad’s friend had built it for me and it never quite worked right. I would bring my machine to the college help desk, but they rightfully decided not to tinker with it because of its uncertain provenance. In order to keep writing papers for my English classes, I had to figure out how to maintain my desktop computer myself. This led me to reformatting hard drives, installing operating systems, hunting down drivers online, and taking that blasted machine apart to install more memory.

I kept my computer working long enough to learn a ton. By junior year, I was able to parlay my experience into a student job in the help desk, a summer job working for the campus networking and systems group, and later a full-time job in networking and systems after graduation. English still had my heart, but working with technology was exciting, involved complex logic, and demystified things I used every day.

Once I was working with technology professionally, I discovered lots of ways to make my background as an English major pay off. I enjoyed writing technical documentation and managing the college’s Apple authorized repair facility, which mostly involved being detail oriented and communicating technical ideas to less technical peers. Pro Tip: always back up your work somewhere off your machine. As time wore on that job, I realized that there was a hard, technical ceiling that I couldn’t surmount without more schooling and that working in IT in higher education had a limited horizon. I was hungry for more and decided to quit my job to go back to school for a CS degree. It was probably the best, hardest thing I have ever done.

In the fall of 2010, I started the master’s program in Computer and Information Technology (MCIT) program at Penn. Dear reader, this is where our central conflict arises: I had never programmed until I started MCIT. Like not at all. For real. It was a gamble that I would not only succeed at programming while in school, but also like it and want to make a career out of it. Though MCIT threw me into the deep end, I found that the professors in the program were very supportive and took a personal interest in the success of the students. With their help, I totally geeked out on theory of computation and the overlap between programming language and natural languages. I was super surprised at how closely a well-structured program mirrors a good written argument — terse, expressive, and with logical flow. I also got to TA and found myself in a role where I could help others learn and grow.

The thing I found hardest initially was my inability to gauge how long it would take me to complete assignments. I am a planner by nature but I couldn’t plan at all that first semester; all I could do was work my way through. As a result, the biggest gift I got out of that semester was “grit” — a quality that’s all the rage at the moment. I began to believe that, even if I didn’t know how to solve a problem, I would figure it out in time if I kept working at it. It was that grit that helped me get through the rest of the program and my first gig as a developer.

After graduation, I landed my first job as a programmer at Neat, a mature product company in Philadelphia that had created a cloud document storage solution. That cloud storage product was just going into beta when I was hired and it was such an exciting time to be there. I was on a super-productive, cross-functional team and was surrounded by mentors that were eager to see me succeed. My first six months at the job was like drinking from a firehose but MCIT had prepared me for it. Over time I graduated from developing individual features for our web app to moonlighting on the devops team and running overnight deploys. Eventually, I became a team lead for our mostly remote team, helping them grow and succeed on the team. In the three years I was at Neat, I saw our cloud product go through two complete life cycles, getting redesigned to accommodate new features and stay competitive.

I was exposed to all aspects of our tech stack as well as product design, agile workflow, and devops. This is where I think I really started to love programming and where I committed to it as my career; that large web app codebase was the ultimate exposure to complex logic and helped me to demystify a lot of the software products I use every day.

Then I ran into a problem. I had been working in the same codebase long enough that there were few mysteries left for me. I started to get bored, so I went looking for new adventures.

While I was at that first developer gig, I was introduced to some developers at a local consulting firm. As soon as I saw what they got to do — rapidly developing prototypes, changing code bases and even languages — I thought, “I’ve got to get me some of that.”

So, now I am a full stack engineer and manager at PromptWorks, a Philadelphia consulting firm. For me, this marries the best parts of all of the jobs I’ve had: communicating technical ideas to less technical product owners, seeing product design up close, complex business logic, and, of course, lots of programming.

Being a manager is awesome too. It reminds me a lot of being a TA in MCIT; I get to help others flourish. In so many surprising ways, MCIT prepared me for a career I deeply value and enjoy.

And so our hero triumphed and she continues on in her adventures in programming. Every day, I get to live the lessons I learned in MCIT — testing and software craftsmanship matter, document your work, help others, and take on the hard stuff. MCIT definitely gives you deep exposure to CS fundamentals and coding best practices, but also prepares you to take that knowledge out into the world as a working software engineer. I’ve benefited tremendously from my time in MCIT and can’t say enough nice things about it.