I am a QA for a digital wayfinding company –– a world away from WM Studios in scope, despite our shared status as tech companies. QA means quality assurance, but the people charged with maintaining such a thing are called QAs, too. It sounds funny like that: “I am a quality assurance.” My job is to comb through applications and code and development and front-ends and back-ends (ha!) and make sure it all functions nicely. I love my company. I also have complicated feelings about my work.

Today one of our projects met its goal of being deliverable. We’ve been working on this project for a few weeks now as a crackpot team of two: a junior front-end developer and me, a fairly inexperienced QA. Both of us had found our way to the project by being thrown in head-first –– it was an utter mess inherited sans functionality or documentation, and he had to comb through every bit of code to make sense of it and whip it into shape. I came to it without even so much as an introduction, just an iPhone 6S thrust into my hands: “Test this.” I had so many questions.

But now, three weeks later, we have a good application. It’s not perfect, by any means, but it’s functional. To get there, I tapped him on the shoulder half a dozen times a day with questions: is this supposed to do that? Why doesn’t this do that? Look at this thing! Look at that weird reaction. He did the same for me, bearing new builds and summaries for new features and lists of fixed bugs. We spoke so much and covered so much ground that my bug-logging documentation was just a formality rather than a to-do list. He made copious notes, too, so that if another developer has to touch his work, it will be easy to see where things are going. We released a good build today, and on Monday, we’ll work on making it even better.

I tell this story because it is not generally how I feel in this job. It is cathartic to talk about a professional success in a field that is so rife with dysfunction, especially when this is not a field that I ever intended to be in. Despite having been with the company for some time in a different role, I didn’t quite know what to make of the offer to become a QA or what it meant to join the research and development team, so I did some reading online about the process of development. I came across an blog entry by Peter Welch entitled Programming Sucks that felt elucidating (if not a little bitter.) It compared programming to the process of building a bridge, and how few people would cross bridges if they knew what sort of conflict and dysfuction was present in development. It sounded right, but I didn’t quite know how true it was, so I linked my dev friend to it and asked his opinion.

“Yes, exactly,” he said. “I want to burn all the bridges down. This also explains why it's hard to find cultural-fitting programmers.”

I am used to dysfunction. I don’t think I have ever worked on a team that wasn’t chaotic in some sense, and I have always found a way to thrive. I decided to take the job, even though I had far more real-world experience than professional experience, and immediately this dysfunction was rendered clear to me in glorious reality: pissing contests over who put in more obscene amounts of overtime, personality clashes, disagreements on project scopes and confusion over documentation, the whole nine yards. For two weeks, I completely distraught, trapped under a quasi-perfectionist nature and an intense love of organization. How did anything get accomplished with such chaos? Dear god, please say this isn’t the norm!

But if developers are to be believed, it is. And they work through it, marvelously, to the point where an outsider could never imagine.

Our company has this funny little tic lately, where it likes to post cute things to social media that shows off how trendy we are, how savvy and with it we are. There are shutter shades hidden in video shoots like easter eggs and the company Instagram pretends that we are an endless stream of game nights and office dogs, and that everyone in the office eats their oatmeal with chia seeds and takes long enough breaks to practice latte art. These things are all true, in their way, but when the tensions are running high and hard, I think about this perception of our company as cool and how maybe it, too, is like the code: a scramble of different words and codes and missing documentation that functions but sometimes seems to be on the verge of breaking.

So how do you reconcile that? How do you look at an application and know what sort of broken, shambling beasts of code exist below it and still feel comfort in it, knowing how much could go wrong? Likewise, how do I — or anyone in a profession and company with growing pains and hurdles to overcome — accept the reality of our positions when we know how fragile the veneer is?

I don’t know yet, truthfully. It’s a fragile thing, a tricky thing that keeps me awake. When I read a bug report that is so poorly written that I cannot make sense of what the issue is, or when the documentation is so askew that we can hardly say what even falls under the application’s scope anymore, I worry. I worry greatly about quality assurance and whether I am someone who can assure quality. I worry that we are an anomaly to have dysfunction, but I worry more that this sort of dysfunction has a place in every company, institution and production I will ever cross paths with.

But worrying, at least, keeps us human. As long as we are human, we can strive for quality.