The last connecting flight between home and my college was on a comically small airplane. It was a 1996 Beech turbo-prop with no lavatory, no overhead bins, and 19 of the tiniest seats you’ll ever see. About 10 minutes into the 45-minute flight, the copilot would crawl out of the cockpit and serve drinks to the handful of passengers aboard. He could barely finish opening everyone’s cans of soda and handing out the peanuts before needing to return to the cockpit for landing.
It always struck me as funny to have two pilots with thousands of hours’ training in the cockpit when one of them spent most of the time serving refreshments. A sober contrast is the 2015 derailment of the Amtrak Northeast Regional train as it passed through Philadelphia: The train was traveling at 102 mph in a 50-mph zone of curved tracks when it derailed. Despite being highly trained and reportedly a model of responsibility, the solitary engineer in the locomotive can’t recall much about the incident that killed 8 passengers and injured over 200. Why did he accelerate into the turn when he should have been slowing down? The tragedy remains a mystery.
Software engineering is important work. Though we seldom hold human lives in our hands, the software we write can enable someone to accomplish their work goals, make a critical life change, or avoid danger when seconds count. Our users may not appreciate your good judgement and skillful work as immediately as they do a pilot’s or a surgeon’s—and they’ll surely never see a single line of your beautiful, beautiful code—but rest assured that if something goes wrong, they’ll shake their fists and curse “the idiots that made this damn app!”
It’s not just about bugs, either. A confusing workflow can waste thousands of productive hours when scaled across a large organization. Missing tests or spaghetti code might mean the app needs to be thrown away and rebuilt from scratch in just a year or two. Lack of vigilance can mean your users’ security is breached, privacy is violated, or experience is ruined by bad actors.
You may start out your career animating the logo on a web page or sending an automated email (“I did it! I can’t believe it works! God bless Stack Overflow!”), but as time goes on, you’re trusted with increasingly important projects that require attention to all the consequences. The tasks are bigger than you can handle on your own responsibly and it’s no longer enough to just make it work in isolation—you need a partner to help you solve the tough problems but still keep things simple in the context of the whole system.
So, while the stakes aren’t quite as high and the consequences as immediate, having two programmers at the controls can be advantageous for similar reasons to pilots: Two people can make better decisions together.