Adam Zerner

Onboarding and taxi driving

I just started a new job. Naturally, that means learning my way around a new codebase. Here is an analogy for how that feels.

Imagine that you are a taxi driver in Chicago. You have been doing it for six years and you know your way around pretty well. But then you get a new gig in New York, so you move there.

You get your first request for a ride. A client wants you to take them from point A to point B. But here's the thing: you don't know how to get from A to B! You're new in town!

And here's the other thing, there aren't any maps! So what do you do? You mess around. Before your first ride it'd be good to spend a little time riding around town, getting a feel for the layout, slowly building up your own little map in your mind. Kinda like how in those video games the map only starts to become visible for places that you've walked through before.

But you can't really afford to build a complete map. That would take too long. There are clients who need things done for them. So you build up a partial map yourself a little bit, you go through a little onboarding where they describe the layout to you, you chat with your coworkers and ask for tips, but ultimately you don't have a complete picture for your first ride, and so going from A to B will take you longer than usual. You'll go down some false paths, make mistakes, and update your model. As time goes on, there will be fewer and fewer false paths. Fewer and fewer mistakes.

There are also parallels with software design and urban design. In good urban design, getting around is as intuitive as possible. Eg. the grid structure of Manhattan + how a lot of the streets are numbered. If you are on 34th and 7th and need to get to 42nd and 8th, that is pretty easy to do even if you are new to town. Going from 34th street to 42nd street just means going north eight blocks. And going from 7th to 8th avenue means going west one block. It's the same thing with good software design. It can be done in such a way where things are as intuitive as possible.

The following might be stretching the analogy a little bit, but let's try it. Imagine a city that is very large. That'll mean a lot of your routes are just going to be long. Even if the city is designed well, distance is distance. Perhaps that is analogous to the inherent complexity in a codebase. If there is a ton of code and a ton of features, there is only so much you can do to make it easy to navigate quickly. Cue the people who preach about the virtues of saying no.

I'm sure you could continue taking this analogy further and further, but I'll leave it here.

If you have any thoughts, I'd love to discuss them over email:

If you'd like to subscribe, you can do so via email or RSS feed.