What I Learned About Programming From a Delivery Guy

Flatiron School / 17 June 2013

The following is a guest post by George Lin and originally appeared on his blog. George is currently a student at The Flatiron School. You can follow him on Twitter here.

So today, as I was heading up the elevator on my way to my apartment, a food delivery guy gets into the elevator.

Some context: I live on the 46th floor of my building, so it’s always slightly annoying when people get into the elevator on the way up – that’s 2 more floors the elevator has to stop at! It’s tough enough having the elevator stop at a bunch of floors on its way down; I’d rather not have it do that on the way up (I know, first world problem)

Now, the delivery guy not only decides to hit another floor (let’s say 35) between the floor he got on (let’s say it was 20) and my floor (46), but he also decides to hit the button for the penthouse floor! This doesn’t really annoy me as I will be getting off the elevator before then, but it does pique my interest…

…as soon as he gets off on the 35th floor, he immediately hits the down button on that floor and then hurries down the hallway to make his delivery.

How strange. I think about this for a second before coming up with an explanation:

Elevator Workflow

This is the delivery guy’s “workflow” – as soon as he gets into the elevator, he wants to make sure the elevator is going to go to the top floor. That way, as soon as he gets off and immediately hits down, he is ensured that there is an elevator – the one he just got off of – which will go to the top floor and then come down to meet him as he finishes his delivery, assuming the time it takes to deliver is similar to the time it takes for the elevator to go to the top and then come down to meet him. If he had not hit the penthouse button, all the elevators might already be at the bottom and he would have to wait much longer for one of them to come up and take him down.

Now I know why delivery people are always so impatient when I don’t come to the door immediately!

Delivery = Programming

So how is this related to programming you ask? It might not be that related. But my head has been swimming in code for the last 3 weeks, so these are the kinds of analogies I’m drawing:

  1. In my experience to the world of programming, it seems that efficiency is huge. Sure, maybe if you don’t know the keyboard shortcut to a common task, you might waste a second each time, but compound this x1000s and you might be wasting hours, days, weeks, or even longer if programming is a lifelong endeavor. In a similar way, this delivery guy’s methodology might save him a minute or two each time, but compound that and it might become pretty substantial.

  2. To an outside observer, these little “hacks” might seem mysterious at first (or maybe just to me), but once understood I have an “Aha!” moment. When thinking about or looking at code, I often find that some of the individual parts don’t make a lot of sense on their own – e.g. “why did the delivery guy press the top floor?? It’s not like he’s going there since he’s getting off before then”. But once understood as part of a whole, the code is crucial or complementary. Conversely, there is some code which makes perfect sense when I see it – e.g. “press the down button as soon as you get off on a floor” – but there’s a lot of nuances that are easy to miss upon cursory inspection, e.g. the elevator going to the top floor complementing the more obvious action.

  3. I was exposed to the method of pressing the penthouse floor button, before seeing the method of pressing down immediately after getting off the elevator. However, pressing down is the first real action after getting off the elevator, and it just so happens that the ideal result occurs as a result of the penthouse method triggering much earlier. Similarly, when reading code, things don’t seem to be as straightforward as reading downwards. Control flow, methods being invoked, etc add complexity to how code is read, and it becomes a skill to mentally conceptualize how things are flowing.

  4. It would probably have been easiest to figure all this out by asking. If I was a delivery guy I might have figured this out on my own, but there is a chance I wouldn’t have and wasted a lot of time. The actual task of delivering things, just like programming, is oftentimes inherently lonely, yet there are so many ways it could/should be social – you have to interact with people in some capacity in order to get the product to the customer. And like many industries, there is so much to learn from others, whether it is through mentorship, apprenticeship, other resources, pair programming, or whatnot.

  5. Software development even uses similar language as food delivery – “shipping”, “delivery / deployment”, etc.

Stand & Deliver

As I’m learning about data modeling and object-oriented programming, what might be interesting is modeling out the actual elevator / food / “hacker” delivery guy in code. More to come on a later date?

First Meetup

On an unrelated note, today was the first meeting this semester of the NYC on Rails Meetup! Here’s a snippet of a great presentation on creating a Gem which uses command line to post directly to Tumblr (ShitAviSays) (note: click pic to see Vine video):


8-Bit Git: The Challenges of Creating a Git-Based Game (Part One) Previous Post The Road to Ruby From C++ Next Post