Backwater

In John Siracusa’s and Dan Benjamin’s now-old podcast episode “The Bridges of Siracusa County”, Siracusa talks about how Perl has been an incubator of language innovation, not despite being a backwater, but because of it. Since it wasn’t straightjacketed by the requirements of an important platform, its users could experiment freely.

Let me tell you a bit about what I saw at Apple.

There were at least three places I knew of—in areas you might not expect—where being a relative backwater in the grand scheme of Apple’s priorities helped make a project both better and more enjoyable for the engineers involved.

Let’s tackle the first one: because the projects weren’t anyone’s priority, they didn’t have to be flashy or aligned with unrelated interests or subject to political whims. The engineers could, y’know, just do what they saw fit. Now, I’ve drunk enough Apple Kool-Aid to believe the engineers shouldn’t solely be in charge of a project. There still need to be real designers involved, among others. But the engineers who work day in and day out on a project are often the ones with the best insight on the important bugs, the little annoyances, the things that the actual users want. And given their freedom, they can fix and provide those things.

(The lower-tier engineers are generally not the ones to go to for sweeping, breathtaking new directions. And since Apple’s management skews towards that, you can see why they don’t listen to those engineers very much.)

And the second: because the engineers were allowed to exercise a little judgment and do their own thing, they had more fun. Important Apple projects can be extended death marches, where you both work insanely hard and really aren’t given much creative freedom. Maybe that’s the only way to get the kind of quality Apple provides consistently.

But, y’know, what fun is that?