I honestly can’t remember anything from January or even October very specifically. It sure felt like I was busy as we doubled the TaskRabbit engineering team and scaled the site to get a lot more stuff done for real people in the real world.

I can’t even decide what the best way is to see what I did in January. I could look at my email or calendar, but I strive not to make those the center of my world. Maybe in Evernote. My git commits are probably a bit too granular, but maybe there is something in the aggregate.

Most striking is the almost non-existence of code between July and October. We were growing the team during this time and I made the conscious choice to try on more of an “engineering manager” role as opposed to a “tech lead” kind of role. Judging by the large spike in October, it’s clear the experiment got cut short. Around this time, I made the biggest change of the year: transitioning from VP of Engineering to Chief Architect.

Yee, the new VP of Engineering once said to me, “The work-product of an engineer is code. The work-product of a manager is a team.” I think about long-polling our message bus system while walking down the street. He thinks about things like that quote. It seems like the right move to me.

From the beginning of TaskRabbit more than three years ago, I’ve played various development, product, and managerial roles. I realized this year that I add the most value when close to the code. It probably says enough that I started writing this blog post and then immediately got derailed into making a tool to aggregate a user’s git commits across all repositories in order to make the graphs in this post.

I would guess that many engineers follow a similar trajectory wherein they code a bunch and eventually find themselves managing or leading a team of some sort. For example, I quit IBM to get back to coding rather than making various Powerpoint presentations. One of the great things about the culture we’ve built at TaskRabbit is that it allowed me to make that transition without going somewhere else. I did my best and am proud of the team and product we’ve built, but its time to build some more (and delete old) stuff to take this thing to the next level.

Architecturally, the most interesting change this year has been breaking up our monster Rails app into multiple ones. Much has been said on this topic, but each situation is so different that I’m sure there are some lessons in there that would be helpful to others. I’ll be writing about those tactics and lessons in 2013 as we continue the journey.

Looking back for a moment, there are are will be plenty of technological benefits like scaling memory, boot-time, and cutting test-time. The main benefits so far are more team-related, though. By giving teams an independent codebase on which to iterate, they are able to innovate more for the customer and, at the same time, impact other teams less.

You can see that change in the stacked version of this graph. I’ve removed all the labels and such but the red one is our core app. Over the year, less and less code went there and world became much more colorful. Also with my role change, it’s interesting how there is more impact but less commits. As I went over the logs briefly, it became clear the reason: a majority of the changes in the first half of the year were small commits to keep the world on track with groundbreaking changes like “fixing intermittent failure in acceptance tests.” Since the transition, it’s been about writing new services that all our apps are sharing. That’s a move in the right direction, I think.

On the personal front, we bought a house in Menlo Park and plan to stay there for a while. My wife is still a freelance editor and is now doing some consulting for a startup as well as on few books. My son turned one and is now running all over the place. My daughter turned four and will going to Kindergarten before I know it. What a world.