2012 Learnings

The turn of a new year (and an official full year of work as an engineer) provides a great path for sharing some values I’ve learned in the tech industry, though my guess is that these can easily be applied elsewhere in any job industry.

The Value of Patience

At a midpoint last year, I moved closer to a career path that meant much more to me (not that being a front end developer was unenjoyable–it was a blast), and filled in the shoes of a data engineer. This meant I got to play with data all day long, write code to parse it, use it to build reports, and most importantly, bring up insights that are buried deep in the catacombs of an otherwise opaque MySQL operations database. It also meant I would be working with an analytics team in San Francisco–3000 miles away.

I think anyone will tell you that applications like Google Hangouts and Skype are not valid replacements for team building and working together. It became very easy for me to want to move at my own pace, and sooner or later, my team’s work just became a lost conundrum behind my own. This was, essentially, a problem. Teams can’t work if we are all doing different projects, with different goals. Instead, I’m finding it a great exercise to constantly measure project length, involvement with others (both in and out of my team), and communicating how my current goals align with the team’s. If they don’t, looking at team goals, needs, and requirements is a great way to determine what are more relevant projects to do that will help move the team together as a whole.

The Value of Self-improvement

Somewhere last year I just got stuck. My code stopped improving, particularly because half of what my job seemed to be at the time was writing data mining scripts for very specific instances of data shaping. This was awesome at the time, because it felt easy–nothing more complicated in a single Ruby script than a couple data collection functions, and borrowed functions from app models used in operations. But, doing this every day wasn’t making anything actually better in the long run. It was no better than being “The SQL guy” at work (another thing I wanted to avoid), and after a couple months had passed, I realized individually, nothing had actually progressed.

Eventually, I took it upon myself to start working more often with other engineers at work, just to learn more about better code structure, writing reusable code, and just finding ways to front-load code, to, in effect, write much less code later. It also became obvious how incredibly helpful it is to have all project requirements laid out as early as possible. This was a great opportunity to be reflective and determine what projects could be worked on asynchronously, and an opportunity to just ship the best, most appropriate code for any given project.

The Value of Dedication

As a front-end, my projects were typically marketing based (and some effort elsewhere like gzip packaging optimization), though many were short scale. Working in data, I’m finding ways to turn a lot of the originally repetitive tasks into better, but more time intensive, large scale projects. It feels nostalgic, writing product briefs for data engineering projects. I’m reminded of writing unit plans for teaching. And because of that, I like to remind myself of the effort I made to grow as an educator to do the same in my current field. It’s crucial to see projects from beginning to end, observing all the positive work happening, but also to see new drawbacks and problems arise. But, in the end, what’s more valuable is reviewing everything about a given project, and applying said learnings into the next.

I could simply say, it looks like my best learnings (read: challenges) above from many early projects were “shit shit shit working asynchronously isn’t helping,” and “why do I feel like I’m doing the same thing every day.” The reality is: an overarching goal of front-loading requirements and plans, shipping reliable and appropriate code that extends quality, and seeing through your projects to the end is what makes a happy and productive work environment (for me, anyway). Here’s to hoping that 2013 provides a chance to improve even more, so new challenges can arise that I’m ready to tackle actively and thoughtfully.