Career Programming

All the Leaves are Brown and the Sky is Gray

© Copyright Peter Church and licensed for reuse under this Creative Commons Licence.
© Copyright Peter Church and licensed for reuse under this Creative Commons Licence.

It’s a weird thing to reflect on my career and realize that very little of the code I wrote is still in production – because very few of the things I worked on are still in production. Most of the products I have worked on have failed.

We build with bits not bricks. Architects and civil engineers leave their legacy on the skyline. In software ours is mainly in the things we learned, and our relationships with each other. Are you better, smarter, kinder, because of the people you worked with? Can any of them say that about you? From every failed project I worked on there is someone, often more than one, but at least one, who my life has been dramatically richer for having known and worked with. Maybe that is as much as I can hope for. Maybe that is a good run.

It’s still hard though. To look back, and see – a year of my life to that one. Dead. Six months to that one. Dead. 18 months to that ridiculous mess. Dead. Did I do anything meaningful? Was any of it worthwhile?

By the time I left the conglomerate I was very familiar with various forms of project killing organizational dysfunction. I could predict the kind of failure, and why. I was generally powerless to do anything about it, though, and it’s pretty depressing to be the person who is predicting disaster. No one appreciates it at the time, although later people sometimes ping you to tell you, “you were right”.

But I’ve learned something about building software well, something about mobile, something about running functional teams that execute. And most importantly – even when the product fails, it doesn’t mean that you did.

Some failures were engineering failures, of course. The team that built a platform instead of the product we were supposed to. The team that just didn’t execute well. The team that was so busy over-engineering everything that the actual product barely moved forward (maybe because things like adding a field to a form required changing >10 files). The organization that bet that technically superiority could win over a product people were actually using – and, of course, lost.

And there are my personal failures: prioritizing the wrong thing, trusting someone to deliver something I shouldn’t have, getting distracted from execution by politics and bullshit. Fighting for things that I was never going to win on.

But generally engineering has been the least of it. And I think that is because the low hanging fruit is gone, and mainly we are left with minor inconveniences and behavior change. Nothing remains offline only, so we are left with things to optimize, and trying to invent new things that no one ever knew they wanted. Behavior change is hard – how many things can you think about that have been real behavior change? Pokemon go has actually got people to walk around outside, so that’s a big one. But say the – incredibly profitable – Kim Kardashian app is that really behavior change? Or just behavior facilitation. A different forum for an existing behavior of celebrity obsession.

I think this is especially true on mobile. The most interesting things I see happening lately are in infrastructure, and on mobile we are mainly talking about new languages (Swift! Kotlin!) rather than new things we can enable for users. Last year I gave a talk about how mobile is a systems problem – as a lot of the things that make the best user experience are contextual (and contextual is 1) hard period, and 2) far too easy to be very creepy and intrusive) or moving server side to better support a multi-device world.

This year I prepared a talk called “how to be invisible”, about how the best user experience is no user experience at all. Which comes back to this point about optimizing: when you are trying to optimize, you kind of need to disappear. There are a lot of apps trying to better facilitate minor inconveniences, and all they offer is a different, digital, kind of minor inconvenience. These applications invariably fail. I don’t believe Uber would have succeeded if they started outside of SF – because outside of SF taxis are a minor inconvenience. In SF taxis were a nightmare, so it was much easier to be a dramatic improvement. Now the experience is – mostly – better than the minor inconvenience of taxis in other cities, dramatically helped by taxis (in some cities) being one of few things that are cash-only. But I don’t think it was at first.

There’s a rhetoric in tech that claims something grander and more dramatic. It is mostly not true. Even working at companies who genuinely have changed the world, most of the day to day work of an engineer will not come close to that kind of impact. Their careers will be littered with failed features, failed products, even as the behemoth overall moves forwards. This isn’t clear from the outside, because whilst products are launched with a fanfair, they are killed quietly. It is surprisingly easy to eliminate months, years of work.

We build with bits, not bricks. Sometimes, often, all we leave with is what we learned, and our relationships with each other.

Better make them good.