Getting Up and Running: My First 30 Days

by Dan Kleiman

Everyone said, “it could take up to six months before you really feel like you know what’s going on.”

From the first time I opened my laptop at Tapjoy, questions came flooding in to my head, like:

  • How long will it take to feel at ease in my new development environment?

  • How soon before I know my way around all our systems and services?

  • How soon before I’m confident that what I’m doing in dev translates accurately to production?

I was anxious and I didn’t want to wait six months to feel better. I tried to work through the initial jitters by looking for concrete answers to what systems and services we use and how they fit together. If I could get into specific lines of code, I would feel a sense of progress, however small, instead of being anxious. Even a high-level whiteboarding orientation on system architecture can be daunting, so I knew I needed to move from those diagrams down into the details of the code.

My first approach was to try to get everything running locally by hitting our main repositories one by one and cloning them onto my machine. I followed as much of the set-up documentation as I could find. You can imagine that in a dynamic engineering environment, though, the READMEs and other documentation aren’t always current. So I had a choice: grumble about the set-up path not being laid out cleanly and error-free and ask for help for every tiny step OR wrestle through the new applications and figure out their quirks through a little trial and error.

In fact, I learned that taking the second approach was a shortcut to making my first positive contribution to the team. By upgrading the documentation and set-up process, I was able to make onboarding the next new person a little easier for the team. Within the first couple of days, I had a small win: I demonstrated that I was committed to helping out and would take any opportunity to make work easier for my teammates.

Joyful Development through Better Tools

During this process of trial and error, I began to feel a small sense of command over my dev environment and even got my first code change pull request merged.

Checking in on my initial anxiety, I was feeling better. Obviously I was nowhere near complete mastery of our systems, and that six-month settling-in period still seemed far away, but in a small way I had proven to myself that taking small, concrete steps was working.

It was while I was submitting and testing my first pull request that I was introduced to a cool internal tool that we have here at Tapjoy that has completely shifted how I think about doing meaningful development work against a complex production system: the Tap-In-A-Box.


What’s a Tap-In-A-Box? Before I explain, I need to acknowledge something.  Yes, I did just argue for the benefits of grinding your way through a lot of little set-up details, as if the pain of doing so bonds you to the code base. There’s value in struggle because it cements the lessons you learn along the way.

How could I get so excited about a tool? I know that my code will never be as clean as it could be, nor my solutions as innovative as they could be, if I were constantly fighting with my tools.

So here’s what an awesome tool like Tap-In-A-Box provides:

  • A single instance with all our services and some production-like data, deployed against whatever code you are currently working on, with a single-click from our tools dashboard

  • A safe sandbox for experimenting with as-close-to-real data and service interaction as possible

  • Command-line integration through a special library that lets you debug, monitor, and update the remote box

With Tap-In-A-Box, It's possible to be up and running with my own fresh copy of a production server by the time I get back to my desk with a cup of coffee.

New features can be tested with confidence because production-like data is already loaded on the box. Interactions between internal services can be tested, because they are already configured properly and running. Any code that warrants tweaking locally, for any of our services, can immediately be pushed to the box thanks to the Tap-In-A-Box command line interface.

Most importantly, because I don’t have to carry the burden of orchestrating dozens of services and system configurations, it’s possible to focus on the problems that I am trying to solve with my code.

Engaged Teammates, Innovative Tools

With a Tap-In-A-Box at my fingertips, I can fly through set-up and configuration for nearly any part of our codebase. Being introduced to this tool let me take another step towards feeling at ease.

At the same time, I was getting to know my teammates and starting to understand the engineering mindset at Tapjoy. All the related infrastructure, tooling, and design initiatives around Tap-In-A-Box started to capture this mindset for me perfectly.

In the first line of the README for the command-line application that integrates with Tap-In-A-Box -- a project called “tjsh” -- you can see exactly the kind of mindset that leads to building such innovative tools:


TJSH commands cover the essential tasks of your development workflow, including:

  • connecting to the remote server where the code is deployed

  • viewing the application logs

  • accessing an application console

  • pushing new code or watching for changes in the background

  • stopping, starting, and monitoring services

  • even launching the application in your browser.

This all may sound like fairly straightforward behavior when you’re working on any one application, but I’ve already been in a situation where I needed to be tweaking and tuning interactions between 2 or 3 services simultaneously -- and it’s so easy using TJSH and Tap-In-A-Box. I toggle between the applications locally, make my changes, sync the changes with the remote server, and cruise back to the browser to test how everything fits together.

To go from struggling through READMEs in week one, to testing interactions across services in week two with a high degree of confidence in the accuracy of the data and behavior feels amazing.

I still believe in that six-month learning curve, but maybe I had it wrong initially. It won’t be six months because I’ve been left to figure it out on my own or that the systems are so horribly complex that I need that long to trudge down every code path.

There is a lot going on and maybe it’s hard to get my head wrapped around it all -- but I also don’t think I’d really want a job somewhere where I could have it all figured out in a couple of weeks, anyway.

In my first 30 days, I’ve come away knowing that there’s a lot to master here. I have also learned that my teammates are invested in helping each other get to mastery. One of the ways Tapjoy engineers do that is by crafting awesome tools that help make our complex ecosystem accessible.

The best part is that development of tools like this -- and there are many other internal projects akin to Tap-In-A-Box -- is alive, ongoing, and dynamic at Tapjoy. Even in the short time I’ve been here I’ve seen the command-line tool evolve in utility and sophistication. People are excited about the tools they are building. Our engineers have an infectious level of joy about their work which translates into some pretty cool innovation!