The short list Aug 24, 2016

What does one bring on a long round-the-world trip?

Here's how I normally buy clothes:

  1. Find a few things I like and buy them in bulk, cheap or at least on a solid sale on the internet, or
  2. Go to Ross and embrace the treasure hunt.

Needless to say, this does not produce fashionable results, but more importantly, it means that most of my clothes aren't the most durable or high quality: crazy fashion trends aside, I do think you get what you pay for up to a certain point. So when it came to packing for our year-long round-the-world trip, I knew basically none of my current wardrobe was going to make it into my bag. And that's to say nothing of all the non-clothing items I needed.

To add to the challenge, Gina and I both committed to traveling without checked luggage, meaning we get one big bag and one personal item for all the things we're going to need all year long. Neither of us has any room for bringing much in the way of "optional" items, so we had to cut really really hard.

Now that we've started traveling, I wanted to show you what's in these two very full bags and how I decided what made the cut:

The bags fully packed


Going where? Aug 5, 2016

Our round-the-world trip in a nutshell

As I write this, we are a week into being unemployed and homeless, and T-12 days until departure to our first destination. Yikes!

These final weeks find us in the midst of last minute prep, booking flights and hotels, while also trying to spend ample time with friends and family. We successfully got rid of most of our crap and ended our lease, drove across the country and planned out the details of our first month and a half of travel.

We need to be at two weddings in the first month and a half, and we'll be back in the U.S. after little more than a month, so our early itinerary is simultaneously more locked down and more manic. But we have our rough country list for the rest of the trip, and it's full of some curious choices. So before I get the inevitable "you forgot Poland" response, let me tell you where we're going, where we aren't, and how we decided which is which.

George W Bush forgot Poland


Coming up next Jul 16, 2016

On jobs that click, and leaving them

When I started as a PM at Microsoft in mid-May seven years ago, I thought to myself, "well, I guess I'll give this a shot for a year, and if I don't like it, I have a 'Plan B' to go work abroad through AIESEC." And if I did like it, I figured I'd put in a couple of years before figuring out my next steps.

Well, it turned out that I did like it, and a "couple of years" rapidly became the better part of a decade. Why? Because I was lucky enough to find a job that clicked for me. And yet, after all this time, and even though both my family and some of my friends think I'm a bit crazy, yesterday was my last day at Microsoft.


Talking at work Aug 4, 2015

Want a team to communicate well? Talk to groups at least 80% of the time

The rise of Slack and similar chat services is, in many ways, changing the way teams communicate at work. Day-to-day conversations are increasingly moving from the stagnant, high-overhead world of email to light-weight chat. I find this evolution incredibly exciting, and I think many companies and teams are benefiting tremendously from these changes. But most teams? Well, they never knew how to communicate in the first place. And Slack can't magically fix the fundamental flaws that make bad teams remain bad teams.

Poor communication

How do you know a team is bad at communicating?

My experience is that if you've ever been on a team that has healthy communications and you suddenly find yourself on a bad one, it'll be painfully and overwhelmingly apparent. But I suspect quite a few people haven't had that good fortune, and believe a team with stunted communication channels is actually the norm.

Here are some pretty safe indicators that you're on a team that doesn't know how to communicate:


The soccer ball and the solar system Jun 8, 2015

Two ways to think about reworking a complex software architecture

A few weeks ago I hit my six-year anniversary at Microsoft. In that time, I've worked with several teams building web services inside the company, and I've built a network of decent size at many of our peer companies. I've learned a lot about software engineering, both from my own experience and that of my peers. In all this time, perhaps the biggest thing I've understood is this: pretty much every engineer who works on a software project of any complexity hates their codebase.

Talented engineers faced with market pressures make tough choices that almost miraculously result in shipped software. It's well understood that those choices add up at a micro level as technical debt, and most great companies have figured out mechanisms for improving individual components over time. But it's harder to account for—and correct—choices that add up at a macro level.

Architectural debt is the sum of those macro-level choices. It affects every piece of your code base, and is usually the result of decisions that were made years ago. Importantly, those decisions may well have been the right ones at the time, both from a "getting to market" perspective and from a "right technical choice for this moment in time" perspective.

However, because it affects so much of your codebase, it's dramatically harder to revisit architectural debt, and the decisions that made sense once upon a time evolve into an albatross around the neck of the people who have to deal with them now. This is the source of the codebase hatred that pervades among engineering departments at companies; they are weighed down by two major factors:

  1. The architectural debt has started affecting every aspect of their day-to-day work: everything takes a long time, functionality is fragile, ownership and accountability is hazy, etc.
  2. The codebase is so large that making any real impact on the problem seems like an insurmountable challenge.


The API is the product Apr 12, 2015

Companies have figured out how to make great APIs and make money

Back in the early days of Web 2.0 exuberance, all the hot new online services (Flickr, Delicious, and even Twitter) built largely open APIs and encouraged developers and customers to build mashups: fun but fleeting ways to juxtapose data from multiple sources on a single webpage. These companies seemed to believe that enabling people to create new and unexplored tools on top of their data would produce magical, unexpected innovation that would make the entire platform richer and ultimately accrue benefits to them. For a time, nearly every consumer startup seemed to launch with an API ready to go, even if their company didn't yet have enough usage to make developing on that API worth people's while.

Unfortunately, as the early mashup excitement waned, these companies figured out they had to earn money and exert more control over their platform. Watching Twitter stumble drunkenly through that process has been particularly entertaining, but the gradual falling into disrepair of many other companies' APIs may ultimately be worse for the web community as apps break and the features of the product diverge from the features of the API.

In recent years, though, a different approach to APIs has emerged. Companies like Twilio and Stripe are rehabilitating the idea of an API from the legacy of failed late-2000s startups and going "all in": the APIs these companies provide are not just important, but the core product that each of them sells.

These companies have figured out two fundamental things about APIs:

  1. The best APIs aren't for your product but for a problem.
  2. You must put as much effort into the user experience of developers who want to use your API as you do in all the other elements of your product.