DoorDash recently announced that they’re restarting an initiative called WeDash, whereby the whole company, including their engineering team, must perform one delivery a month. An otherwise mundane internal memo blew up on social media because of the cold reception its received from its engineering team.
For those of us in the UK, this kind of initiative isn’t anything new. In London, Deliveroo operates a similar scheme, with much less fanfare. Deliveroo staff make local deliveries on foot, as an infrequent, but helpful, insight into the rider’s experience.
So where's the drama?
You can’t just turn up and code
A large part of the response is that this doesn't fit into the role of a Software Engineer. While it certainly won't say in a standard employee contract that you must dash twelve times a year, it won't say a lot of things which you might consider core parts of your role, like attending stand-ups, reviewing pull requests, or training others.
This kind of activity is called dog-fooding, and whether it's delivering food for DoorDash, sorting packages for Amazon, or starting side-hustles for Shopify, it builds empathy. Empathy makes you a better software engineer.
Engineers who are connected with their customers, and are knowledgeable of their product, produce better software. Their abstractions are more accurate, meaning less likely to need change. When time is short, they know what to prioritise, and what corners they can cut. You can't develop a shorthand, or build trust, with someone who refuses to learn the domain.
Everyone must understand the business
A suggested alternative was to give engineers in the company an allowance to order food via the app. This is also a good idea, in addition to delivering orders!
Engineering teams must understand how their company fits together (and how it makes money!) Looking at DoorDash, their business model is a marketplace which relies on riders, restaurants and paying customers. Without a steady supply in all three of these areas, the marketplace quickly collapses.
Engineering teams might be in a team which focuses on one part of this equation, but they must understand the rest. It makes no sense to spend months rebuilding the restaurant discovery page if the delivery times are abysmal, or restaurant selection is so small. It helps nobody if you’re optimising your own work at the expense of everyone else.
Avoiding bad attitudes
The truth is, the vast majority of poor responses to this have come from engineers who are lazy, and don’t want to improve. They did the same for unit testing.
For a while now, we’ve seen companies compromise because there’s simply not enough software engineers. You’d rather hire a mediocre engineer now instead of waiting for someone who can contribute something more.
Over the coming years, we’ll see more and more people enter the workforce with the ability to code. We’re also seeing more people switch into engineering through bootcamps. Eventually the balance will shift, and those who win will be those who are curious, and who understand more than just the code.
When that happens, these folks will unfortunately be caught short.