On the other end of the spectrum, there are the highly-produced Keynotes from Apple that have been agonized over by legions of designers to sell you the company’s latest products. These decks are so intricate that they seem impossible for mere mortals to put together.

So it’s no wonder I don’t see many slide decks working on small software teams. The few I do are usually delivered by professional hypesters pitching startups, to cringes from the designers and developers in the room (or the Zoom, as the case may be). But earlier in my career, I used decks to great effect, and you know what? I miss them. In 2022, I’m bringing decks(y) back.

---

When my longtime friend and collaborator Brian Capps and I worked as iOS engineers at The New York Times, we noticed something concerning. There were a lot of intractable technical problems in the organization that seemed unsolvable due to politics and inter-team communication roadblocks. Everything from bug reports, to performance issues, to new features that needed newsroom buy-in got backed up this way.

So, as people who cared deeply about the quality of the products we were building, we searched for any way to get product people, designers, and business folks all on the same page about what we wanted to fix in the iOS app. The best tool we found (after trying many) was the humble slide deck.

Here’s what we did when we really wanted something to get fixed:

Brian and I would book a conference room together in the middle of the day, write an outline of what we wanted, and then develop a well-designed and straightforward slide presentation to make our argument. (By the way, we never told our bosses we were doing any of this.) We’d rehearse our spiel and then, we’d presell the idea by showing the deck to just a few people we knew would be critical decision-makers and solicit feedback, editing the deck as we heard their objections. Finally, we’d book a meeting with everyone in the organization who would need to be on board if we were going to make the change.

For example, once, we wanted to make sure that the NYTimes iOS app rendered all advertisements at the proper resolution on the new iPhone 4. We knew we’d need to convince a designer, the head of sales, an ad trafficker, a product manager, and our engineering manager. So we invited all of those folks to a meeting, dimmed the lights, and pitched our hearts out. For the first time, everyone in that room saw the blurry non-Retina ads for what they were—ugly and unbecoming of The Times. Everyone came out of that meeting jazzed to solve the problem, and together, we did!

This technique worked so well that we used it repeatedly, improving the app along the way. Our little slideshow sideshow became so familiar that it earned us a nickname: “the twins”. In fairness, we did have a bit of a Ringling Brothers vibe going on at the time.

---

Presentations are perfect for persuasion. Solid slides make information digestible; they show that you’ve thought deeply about the problem. And putting effort into them shows that you’re serious and that you care. Anyone can write an email, post a Slack message, or toss a meeting on the books. But few people will take the time to prepare a thoughtful, well-reasoned, and persuasive deck.

The next time you want to convince your coworkers, despite their differing priorities, to commit to working on something you care about: open your slideshow app of choice and make your argument in big type, one slide at a time. I bet your slides will change more minds than you expect.

Let me explain a little. By the “closed mode” I mean the mode that we are in most of the time when we are at work. We have inside us a feeling that there’s lots to be done and we have to get on with it if we’re going to get through it all.

It’s an active (probably slightly anxious) mode, although the anxiety can be exciting and pleasurable. It’s a mode which we’re probably a little impatient, if only with ourselves. It has a little tension in it, not much humor. It’s a mode in which we’re very purposeful, and it’s a mode in which we can get very stressed and even a bit manic, but not creative.

If you’ve worked on a team making software, you’ve almost certainly heard the thought-terminating cliché, “That’s impossible” hastily uttered by a programmer. I know I’ve said it; I suspect we all have. Sometimes engineers blurt this out because a product manager is asking them to do something unsupported by system APIs; sometimes they really mean “It’s hard” or “It’s not worth it” or even just “I don’t want to.” And then other times they are afraid to admit that they just don’t know how to do what’s being asked of them, even if they have a nagging suspicion that it can be done.

Software engineers reject entire product ideas, categories of problems, and persistent bugs as completely impossible to tackle. What is it about the psychology of programmers that leads to this limitation of imagination? In Cleese’s model, it would seem that programmers are spending so much time in the “closed mode” that they get stuck there. So, what’s the alternative?

By contrast, the open mode, is a relaxed, expansive, less purposeful mode in which we’re probably more contemplative, more inclined to humor (which always accompanies a wider perspective) and, consequently, more playful.

It’s a mood in which curiosity for its own sake can operate because we’re not under pressure to get a specific thing done quickly. We can play, and that is what allows our natural creativity to surface.*

Programmers are problem-solvers, spending most of their day building, a task that demands they be in the closed mode, “wired in”. Implementing features to spec, tracking down and fixing bugs, and thinking like a computer are exercises in putting one’s head down and blocking out distractions, and are therefore incompatible with the open mode. When we train ourselves to see the world this precisely, dividing things into neat boxes and clear abstractions, it can hurt our ability to accept ideas outside our mental model. It’s why many programmers I’ve worked with have stories about tracking an inscrutable bug down to an unhandled condition in their code with a comment that reads // This should never happen. And it’s for just the same reason that many brilliant engineers dismissed ideas like the internet, real time direction-routing, and digital currency as impossible for decades before they were implemented. For a coder, there’s inherent anxiety in impossibiilty, anxiety that can push them toward surrender rather than creative problem-solving.

But during the earlier design and ideation stages of projects, before we start writing code, we need to remind ourselves and our teammates to remain open. Nothing’s decided, nothing’s set in stone, and therefore many things are possible that might not seem that way at first. The Waterfall model of development forces this openness to end when building begins, but newer software methodologies like agile development promote the idea that we should expect design iteration to continue during software construction and therefore allow for open mode thinking throughout a project.

Cleese also suggests ways to avoid choking off our creativity too early. He recommends collaborators establish as free an atmosphere as possible in the open mode. Improvisational comedians have a well-known shorthand for this kind of openness to whatever ideas are presented: “Yes, and”.

And never say anything to squash them either, never say “no” or “wrong” or “I don’t like that.” Always be positive, and build on what is being said:

• “Would it be even better if…”
• “I don’t quite understand that, can you just explain it again?”
• “Go on…”
• “What if…?”
• “Let’s pretend…”

Even if an idea that a coworker proposes is truly impossible, it can still have value. In Edward de Bono’s book Practical Thinking, he writes about the value of intermediate impossibles. Sometimes unrealistic ideas are just a step on the path toward something that will work brilliantly. For example, you might design an impossible sign-up screen that magically knows the user’s name and email, and then realize later in a brainstorm that you don’t need either piece of information at all and still end up with a great user experience. De Bono calls this lateral thinking. As opposed to logical thinking, which requires a linear progression of true statements (just like most computer programs), lateral thinking allows and even encourages impossible ideas as middle steps, as they often help us get to a better end result.

The use of an Intermediate Impossible is completely contrary to ordinary logical thinking in which you have to be right at each stage.

It doesn’t matter if the Intermediate Impossible is right or absurd, it can nevertheless be used as a stepping stone to another idea that is right.

As software makers, we could all stand to be more open to the impossible, especially given that the technology we create must help solve wicked problems outside our screens, like climate change, transportation, and healthcare, problems that will require immense creativity and teamwork. To overcome what seem like impossible tasks, we first need to believe that there might be a way to do so.

The next time you’re playing around with new ideas and someone tells you that they’re impossible, remind them of what John Cleese said, ”When you’re playing, nothing is wrong.”

---

I want to tell you about a number that scares me: 404. That infamous code you see when that internet thing you meant to visit is gone or it moved and no one bothered to add a redirect or maybe it never existed at all.

I’m curious though: how many of you have ever made something you’re proud of on the Web?

So many of us have written, recorded, photographed, or created important works in our personal and professional worlds that live online. Maybe they’re your bylines at that fancy publication about tiny houses, or your YouTube seltzer reviews, or your graduate thesis about the history of pizza ovens. It’s not really important what they are, just that they exist and they’re online.

Well, until…they don’t. 404: Page Not found. 410: Gone. 500: Internal Server Error. These numbers, or status codes, tell us what went wrong but not really why. This problem, the problem of the disappearing internet, of “link rot”, is no joke. Researchers have found that over 50% of URLs cited in Supreme Court opinions no longer point to the intended content. Roughly 70% of links in academic legal journals are broken, and 20% of all science, technology and medicine articles suffer from link rot. The average life of a webpage hovers right around 100 days.

People often patly state that “the internet never forgets,” that once something is online, it will be forever. In a certain light that’s true. It’s nearly impossible to permanently remove something from the internet, on purpose. But, by the same token, the web also disappears at an alarming rate. 5% of the entire internet is lost every year, and we barely notice.

Making something on the web is not a one-time investment. Someone has to spend money every year on the domain, hosting, and maintenance. But what happens when the financial incentives to do that change? Right now the massive data centers that house all this information use 3% of all the electricity in the United States. What happens when that power gets too expensive? Or when we’ve been online for centuries and we start deleting dead people’s pages? Unlike a film, or a play, or a book, the costs of keeping art and science on the web are never-ending. We’re building one of our most important shared cultural resources on land that we rent rather than own, on borrowed time from a parking meter that’s all but guaranteed to run out.

We even saw a large-scale example of this recently when a capricious billionaire hastily took down years of content from Gothamist and DNAInfo, leaving reporters to scramble for saved and aggregated clippings of their work just to build a portfolio to get an new job.

Before you say, “Wait Matt, there’s this One Weird Trick. What about the Wayback Machine, what about the Internet Archive, what about Google’s cache?” Let me quote the web developer Maciej Cegłowski in his talk Web Design - The First 100 Years:

We have heroic efforts like the Internet Archive to preserve stuff, but that's like burning down houses and then cheering on the fire department when it comes to save what's left inside. It's no way to run a culture. We take better care of scrap paper than we do of the early internet, because at least we look at scrap paper before we throw it away.

He’s right. It is no way to run a culture. We’re experiencing quantitative losses of data on par with the burning of Alexandria every year, and we’re barely blinking an eye as the stuff we’re making vanishes in a puff of smoke.

The truth is: there is no easy fix. But as writers and makers and inhabitants of the internet, we need to demand better of the platforms and services and publications we entrust with our work. It might seem safer to trust the big guys (Facebook, Twitter, Medium) with this content because they have the funding and incentives to maintain it. That’s true today, but large platforms like them have failed before, taking terabytes of data with them. Remember Friendster, TwitPic, Geocities?

There are academic efforts like Perma.cc out of the Harvard Library Innovation Lab that will solve this problem for the most important legal and scholarly works. But we can and must to do better than that.

Starting in 2014, a small group of programmers became obsessed with building what is called “content addressable” version of the internet called IPFS. IPFS stands for “InterPlanetary File System”. And “content addressable” means that files are stored and located by their content instead of an arbitrary and therefore brittle address. As I’m sure some of you have guessed by now, it’s built on top the blockchain. Insert eye roll emoji 🙄. But before you write them off, I think these nerds might be on to something. Their system, which is entirely peer to peer, and inherently resistant to the rot I’m talking about is already being used to build a mirrored version of Wikipedia that will be accessible from countries with oppressive regimes, and was used by those in Catalan seeking independence when the government blocked their pages from being accessible on the web. The IPFS team is building a system by which the websites and apps of tomorrow might be able to defend against this failing foundation, but who knows if it’ll get adopted.

The next time you make something and put it online: think about where it’s going to live, how long it’ll be around, and what you can do to preserve it, even if that means making an extra local backup, or printing it out on a dead tree. The culture we’re building together is increasingly digital, hyperlinked, and accessible from anywhere. But it’s not accessible from any when. We’re losing more and more of it every day. If we’re going to continue making things online, we need to deal with this problem systematically and soon. How? I’m not sure. Maybe IPFS, or something like it that hasn’t been invented yet. Until then, I’ll keep my printer.