Search this site


Metadata

Articles

Projects

Presentations

A step in a new direction

Friday was my last day at Google. I was coming up on my second anniversary of joining the company. Working at Google was a superb opportunity, and I would wager I haven't fully digested the value that working here has brought to me. I still love Google, and I may even return some day, but I've got the feeling there's a bigger adventure out there :)

I'm mostly writing this post to document my experiences with leaving a company. I've never done it before. From what I've gathered, much of my experience is exactly what should be expected when you're a valued employee and are leaving.

If you know me, this move shouldn't catch you much by surprise. Economics describes something called the law of diminishing returns which outlines a simple idea that after a certain point, the same amount of input will eventually yield less and less output. It seems in some ways that I had reached that point at Google.

I had a few random meetings with people who expressed interest in my staying. Those who I met with, who knew me, understood why I was leaving. Those that didn't know me couldn't be sold on the idea that someone could actually observe diminishing returns and that I was being presumptuous and ignorant - they might be right, but that's part of why I'm leaving - I need to know. There were other opportunities within Google I could have investigated - but how much new knowledge would I stand to learn? I may never know the answer to that question, but my instincts tell me that even if I had moved to a new project that I would have shortly observed diminishing returns again.

I've learned a lot about the industry and about How Things Work, including learning:

  • that no matter how hard you try, some people insist on reading negative emotions and ill-intent out of factual, unemotional statements.
  • to play the politics game, despite my distaste for it.
  • to give interviews and also learned that I don't like interviewing people.
  • some of what it is like to work on a team and in a group.
  • that I must trust my teammates to get work done or risk going insane.
  • that if there is a singular difference between systems administrators and software engineers, it is that developers are hopelessly optimistic and that sysadmins are hopelessly pessimistic, and that having both groups under the same roof makes your software better.
  • that nobody reads email, especially important ones, and someone will page you asking about a problem you sent out 4 notifications for 3 hours ago.
  • that nobody reads documentation, no matter how accessible. Expect phone calls next week with questions about things you clearly documented on the wiki 8 months ago.
  • that years of experience is a horrible metric for gauging someone's talent and skill
  • that I cannot be represented by any unidimensional scale, such as GPA or job ladder position.
  • that being on-call 24/7 sucks, and that having half of your team 8+ timezones away will alleviate this problem.
  • that everything is negotiable and nothing is ever set in stone.
  • balancing life and work is difficult but always worth putting effort into

The most important thing I have learned is that I have limitless energy for solving difficult problems, and I am much more aware of who I am now than I was a few years ago.

I joined Google many years after it started, and the majority of the infrastructure was already built, decisions made, software designed, etc. Some of those designs were great and some of them were not; a guaranteed occurance on any project or at any company. The piece that was missing was that I missed the opportunity to be a part of making those early decisions - right or wrong.

When I expressed this need, one of the responses was that I should not strive to reinvent the wheel by starting over on a different project only to do a similar thing. I was, after all, going to another company to help them build, design, and operate a scalable infrastructure. It might be good point, but it is a point that doesn't include a critical piece of information - some things must simply be learned on your own. Further, it assumes that every other company is doing the same exact thing Google is, which can't possibly be true.

I have plenty of friends who have "reinvented the wheel" for the sake of learning. For example, one wrote a web browser simply for the purpose of learning how it is done from start to finish: choosing a language, choosing a graphical toolkit, learning some web standards, implementing them, etc. It's a learning experience. College is an endless cycle of wheel reinvention, for example. In parallel, 500 of your fellow students will write the same linked list implementation as you do. One semester from now, another 500 students will rewrite that same linked list implementation from scratch. Why? Because learning by doing is a pretty reliable way to learn. Way before college, you had to learn to walk, all by yourself. Billions of people already knew how to walk before you did and millions of programmers knew how to do a linked list before you did, but that isn't considered reinventing the wheel, right?

Reinventing the wheel for the sake of learning is in many ways a historical simulator. Given the same needs, how will you design? Knowing the mistakes made in the current wheel, can you avoid them without introducting more mistakes? You can travel back in time, knowing what you know now, and see how your ideas and knowledge would have influenced the outcome. At least, that's the way I see it.

Take a look at my history on this site. Many of my projects are easily taggable as wheel reinvention, but I would not know much of what I know if I had not worked on these projects.

There are times when you don't want to reinvent the wheel, but doing so for the sake of learning is a pretty good reason. If you're lucky, you get to be in the right place at the right time to be a part or the whole of the process that leads to the creation of a new, better wheel. Then again, this assumes that whatever exists now works well enough to be considered a wheel at all or that any wheel exists to solve this problem.

At my new place, I'll be able to stretch out my abilities and see more of what I am capable while at the same time learning at a faster rate. Will I help design and implement a great infrastructure or a crap infrastructure? Will I be a fundamental reason why this new company succeeds? These questions are not yet answered, but I am excited to ride on the path towards those answers.

Lastly, just because someone labels an endeavor "wheel reinvention" doesn't make it necessarily that. My new job won't be reinventing the wheel, and assuming that any efforts to improve skills or tools in the systems administration field is "reinventing the wheel" is just silly and proof that the person saying it is out of touch with the field. There's so much opportunity and availability for innovation and improvement in systems administration, and I intend to sieze that opportunity.