I am a software engineer for the Tools & Frameworks (TnF) team at Box. To those who aren’t familiar with what a tools team does in an engineering organization—our charter is to increase developer productivity while improving code quality. There are various ways to achieve this, but the most conventional method is through building a strong continuous integration pipeline. The tagline my boss put on our team shirt is “Better software development through software development,” and that quote is spot-on.
As with any job, a lot of my day consists of “the grind”—AKA running the business. I won’t bore you with what my version of the grind looks like, but I’m sure all of you have your own and can relate. It’s not exactly what you envision you’ll be doing as a software engineer when you were studying computer science in college. Once you graduate and get your first job, you learn that the reality of the software industry is that a product gets architected and designed only once—followed by years of bug fixing, small feature additions, refactoring, and of course, countless conversations with product managers and customer service folks…and that is only in the best case scenario where the product is successful. If you weren’t on the team at the time of the initial product design and development, you are left with none of the glamor, and only the boring, but important, maintenance work that indefinitely follows. It is what it is.
But once in a while, you are presented with the opportunity to conceive, design, and implement a product from scratch—with the blessing from management to take the time to do it right, and to do it with a team that you know to be competent and composed of individuals with whom you enjoy working with. This is the situation that I find myself in the summer of 2014. I recognize that this isn’t something that happens very often, so I have decided to document the journey.
This series isn’t meant to be a technical blog, but it will necessarily contain technical details due to the nature of the subject. It’s written from my perspective and is not necessarily representative of the whole team’s experience. At the time of my writing the first chapter, we are nowhere near complete with even the design phase, so these posts will lack the hindsight that often accompanies reflective writings. I think it’s more honest to write about things as they happen, rather than try to connect the dots into a story arch that may potentially be forced into a cohesive narrative.
