Queuseful Experience

As a fresh-out-of-school junior developer, joining an engineering team for the first time is a daunting experience. After graduating school I believed I had the knowledge, tools, and even the experience needed to hit the ground running… but I was in for a rude awakening! It was naive to think that my sandboxed experience, one-off algorithm challenges and personal projects where anything like a production application supporting millions of users and backed by an engineering team of 20-30 developers. Looking back, I recall my first month on the team as feeling like drinking through a firehose. I had never developed on virtual machines (sans deploying to Heroku), worked with micro services and multiple production servers, or seen codebases with millions of lines of code. In short, I had enough knowledge and experience to digest very small chunks, and everything in the periphery was a black box of ignorance. Spoiler alert… much of it still is. The trick is learning to be okay with that and focusing your efforts on becoming proficient in a few areas rather than trying to grok the entirety of the applications.

Before my time, TeamSnap decided it was a good idea to start juniors in the Support Engineer role. Fielding issue tickets that trickle in from the Support team to the [Support] Dev Queue, then hunting down the source of the issues. Whether it be bad data in the database or a buggy function in the back-end or front-end. These may sound like menial tasks that really don’t equate to developing software, but hunting down bugs is an essential skill; particularly when adding specs to a previously untested codebase, or even TDDing a greenfield feature that’s reliant on legacy code. The breadth of issues that come from the Support team provide the perfect opportunity to gain a high-level overview of what your application does, both from the standpoint of the user as well as a developer.

One ticket might be as simple as discovering that a nil value in the database is causing the view layer to choke, while following another bug might give you the opportunity to learn how a JSON payload sent from the JavaScript front-end is processed by the Ruby API, then sent to a messaging queue for consumption by a micro service, which could be written in any other language. Maybe you don’t walk away understanding the nuts and bolts of message passing, but you understand, at a high-level, how these applications interact and how and where the data being passed is transformed (and eventually where the problem is occurring).

After six months of running of the Dev Queue, I had a pretty good idea of how our handful of micro services, APIs, mobile clients, web client and old-school monolithic application all fit together. I couldn’t tell how each one worked at a low-level, but I could give you the big picture about how they worked, and I had probably made at least one commit to three-fourths of those codebases. Just as important, I was intimately familiar with how our customers interacted with our product.

Great! I know a little about a lot. Now what? For the TeamSnap Support Engineer/Junior Developer, we all seem to take different paths. We’ve had the opportunity to see nearly every aspect of our product and find what gets us excited. One junior from my team went on to build a Ruby micro service with our then-Principle Architect (now CTO), then she settled in on the front-end team writing mostly JavaScript. Another, who as a Support Engineer, enjoyed creating features that improved the Support team’s workflow, moved to a product team that piqued his interest and because he was so knowledgeable about that product, he’s been working on bringing his newly formed team up-to-speed. Both had the opportunity to train others to do their job so that they could move on to other projects and grow as developers. Training others being one of the most important aspects of professional growth.

It’s been about a year and half since I joined TeamSnap and everyone that was a Support Engineer before me has moved on to other development projects and have been replaced by newly hired junior developers. Giving me and another teammate the opportunity train and mentor the next round a TeamSnap junior developers. We’ve worked with four new developers and I can tell you one thing… we may be teaching them… but they’re also teaching us just as much!

This idea of learning through teaching is rather pervasive at TeamSnap, after a junior developer is comfortable in their position, they’re paired with a more senior mentor of their choosing. And some juniors take time to mentor those who may not be junior, but may not know as much about a particular language or technology. Teaching isn’t only limited to the mentor-mentee (why is “mentee” not a word?!), being a distributed development team, we use Slack for our daily communications and have chat channel dedicated pairing with others, #pairwithme. This environment fosters enthusiasm for both teaching and learning… often both at the same time.

The day-to-day role as a Support Engineer changed as I grew as a developer, as it has for other juniors on our team. While at first I fielded Dev Queue issues and tracked down bugs for the majority of my day, now I spend most of my time working on code fixes, small features and training/pairing with team members, sometimes even working on projects outside of my team’s scope, but more in line with where my interests lie. Starting out working on small bugs in varying parts of our technology stack gave a high-level overview of the stack as a whole, showing how different applications/services interact… each part being analogous to a puzzle piece and after ~6 months, finally understanding how all of those pieces fit together. It is because of this experience that I contend that junior developers starting on a support queue, tackling issues with minimal scope (in terms of both time and difficulty) and having the support of mentors and pairs, only sets that junior developer up for greater success when working in a complex stack. They gain the knowledge required to understand issues when they arise, and the experience to know where that issue is coming from. In short, it’s very queuseful experience. Queuseful, being a contraction of “queue” and “useful”. :)