Starting Up

I work at Hashable (click on the logo to check it out).  My official title is “QA Engineer,” which, like most titles, is pretty silly because it only makes enough sense to inflate my ego and prove to outsiders that what I do is not world-shatteringly amazing enough to be given a common-sense name.  What I actually do with most of my time is find and replicate misbehaving elements of the Hashable product (the QA stands for Quality Assurance).  A lot of the time, that means late nights and forcing myself to be very paranoid about specific things that COULD go wrong, although the actual probability of something actually occurring is usually minuscule.  It’s all about attention to detail while keeping the bigger picture in mind (see: Megascope).

I should clarify something:  I love my job.  It’s a non-stop adventure and has taught me as much about myself as it has about the burgeoning startup tech scene in New York City.  The problem is, most people outside of tech cannot even grasp why QA exists, let alone why I’d enjoy it so much.  I assume this is because it’s difficult to visualize the process of building software, similar to how it’s difficult for non-musicians to understand the process of creating a piece of music.

It’s actually not that hard to explain:

1. Someone pitches an idea (either a developer or a product person)
2. Developers build the idea and test that it works to their specifications
3. QA tests the product to make sure it works to the standards of a user and to the product team
4. Developers debug based on QA’s report and Product’s tweaks.
5. QA and development repeat this process until all the bugs are ironed out, or a deadline is reached (and the product is acceptable.  it’s stupid to release things on a deadline if there are a lot of bugs or missing features.)

Like anything else, the end product is only as good as the initial idea, but with each iteration of development and testing, the product inevitably improves in quality.  A QA person’s job is to “own” this quality and provide assurance to the rest of the team that each version is better than the last.

At its core, the role is about understanding how each individual piece of the puzzle fits together to make a single working service.  It’s not always necessary to understand the nitty gritty details (although it doesn’t hurt), and it’s not always necessary to be entirely looped in to the higher level product decisions, but it’s absolutely essential to have a good sense of what a product “is” and where it is headed.  In short, it’s a Zen approach to building things.

I’ve found that the instinct I have always had for taking things apart (and, later, building them) is really the same instinct inherent in getting to know a product.  There is an obsession with functional beauty that resides at the heart of both processes and guides the mind from one piece to another, fitting them together until a grander, emergent system comes into focus.  This obsession is equaled by the childish delight I experience every time something begins to take on a life of its own, to work as an entity and display attributes I never explicitly assigned to it.

The first guitar amplifier I ever built, minutes after completion

In that way, QA is a direct extension of my DIY instincts.  It’s a chance to exercise the part of my brain that delights in seeing a feature completed without having to first put my own sweat and blood into its creation.  It’s a role perfectly wedged between two ongoing thought processes which play off each others’ strengths while attempting to boost their inherent weaknesses.  And, above all, it’s a role which requires a huge amount of learning, discovery, and experimentation.  I’m always in the midst of several projects, all requiring different sets of skills.

QA is my sandbox, my playground, and a gateway drug to the addictive world of Making Things.