In the years I’ve run a consulting studio, I’ve noticed something odd about consulting studios: they often implode. Big ones, little ones, and ostensibly successful ones all seem have a weird habit of suddenly letting go half their staff.

I would very much like to not lose half my staff. To that end, I’ve been collecting anecdata about consulting firms’ rapid unscheduled disassemblies, and the problems that cause them. Was it a technical boondoggle? A nasty lawsuit? Simply failure to innovate?

Usually, no. Talking to more than a dozen people from various troubled consulting firms, I’ve identified the handful of key risks that most often lead to consulting shops’ ruin. Previously, I’ve written about not getting paid. Today I’d like to take a look at another common existential threat: the Big Deal.

Keep Working and Nobody Explodes

Often it happens gradually. You land a client, a company bigger than you with plenty of funding. The work goes well, and over time the relationship grows. The project expands, the work broadens. One thing leads to another, and before you know it most of your revenue is coming from this one Big Deal.

On occasion, this happens all at once: a potential contract is so huge and so juicy that you can’t help but put in a proposal, even if delivering would be a stretch.

Either way, the Deal is probably Big enough that the client gets a discounted rate. At this lower rate, they’re inclined to sign for even more work. You hire more people. Maybe you get a bigger office too. Everything is big, and getting bigger.

In some ways, a single big project is great. It lets you focus on delivering instead of switching contexts, making sales, and juggling different clients’ needs. It can make things feel predictable.

Except they are totally not predictable. Sooner or later, the client’s interests will diverge from yours. When that happens things can get dicey very fast if that client has become “too big to lose”.

If that happens, the least bad outcome is probably that they decide to acquire you. Negotiating from there is hard though, since if they don’t already know how reliant you are on them, they’ll sure as hell find out during due diligence. Still, when you’ve become chemically dependent on a single client, selling out even at a steep discount can be better than the alternatives.

That’s because all good contracts must end. Your client may change up management, scale back your project, bring development in house, or even go out of business. No matter how excellent your work, the cookie’s going to crumble eventually.

If you’re lucky, you’ll get some notice – some warning that things are amiss. If you’re not lucky, the first sign you’re cooked could be a bounced email or late invoice. Either way, unless you’ve been hoarding cash, you’re now in Big Trouble™.

Back in the day, I knew an 80-person contracting firm that had one client grow and grow until it was 90% of their revenue. The contract eventually came up for renewal, and at the last second the client decided to move everything to India. It turned out poorly for the client, but that was no consolation: losing that contract was the consulting equivalent of a nuclear bomb going off.

Eggs in Multiple Baskets

Getting dependent on A Big Deal is theoretically easy to avoid, but it can be emotionally difficult to do so. It’s easy to laugh at folks for letting a giant wooden horse on wheels into their gate, but who doesn’t want a sweet giant horse? It’s so huge!

That’s why it’s worth having a rule of thumb. At Steamclock, whenever a client wants more than 30% of our team’s bandwidth, we always tread carefully.

On the sales and marketing side, signing diverse clients should be an explicit goal. Instead of using discounted rates to help a Big Deal become even bigger, use them to land work that will broaden your portfolio, or to land projects where you can do exceptional work.

It can also be helpful to diligently avoid rushing projects. While piling 60% of your team on something might get it out the door a bit faster, there’s usually a path where 40% of your team could ship a higher quality product for less money, given a more thoughtful scope.

Strategically billing clients less can be an important skill. Some contractors work hard to bill as many hours as they can get away with in the short term. This gooses revenue today, but causes chaos later.

To build long-term relationships, figure out a billable pace that is actually sustainable for each client, and iterate within that.

Sustainability: it’s kind of a Big Deal.

It’s a trap, one I fall into often. I’ll be reading Twitter or Hacker News, and come across an article. It’s promising and potentially enlightening, but long, so I send it to Instapaper for reading later.

Each time I do this, I get a sense of accomplishment. “Yeah! Good for me! I decided to read a substantial essay, something that will expand my mind!”

Yet I have accomplished nothing. Nothing has expanded – other than my Instapaper backlog.

Sure, on occasion I’ll have the good sense to read some saved articles instead of the latest bleeps and bloops, and when I do it’s always rewarding. But I like the latest bleeps and bloops. And reading feels like work! I can start tomorrow.

As a result, I do a lot of saving articles, but not a lot of mind-expanding.

So, this spring, I decided the time had come: I would read through my Instapaper backlog by the end of June. I would finally benefit from those thoughtful and insightful articles no matter how much reading it took.

Spoiler: it took a lot.

After turning on the unread badge in Instapaper – and using an advanced setting to let it download my full backlog – I came face to face with my goal: 372 articles. 372 pieces of writing that past-me had delegated to future-me. Well future-me, time to make some coffee.

With my coffee steaming and my toddler napping, I got comfortable and scrolled down, way way down, to the oldest article.

It was from 2009.

Apparently, I once used an early version of Instapaper to save an article from A List Apart on a topic as old as time: JavaScript frameworks. This wouldn’t have been the first article I’d ever saved, but I guess it was the first one I procrastinated reading.

I skimmed the article for old times’ sake, then hit Archive. Progress 1, mind expansion 0.

Over the coming weeks, I diligently worked my way forward in time. The JavaScript article wasn’t the only piece to age poorly. “The bold new world of 3D TV”, ha right. “Why Twitter must reverse its 2012 policy changes,” sigh. “Why Trump could never be elected,” projectile barf.

Before long, I’d learned to cock my Archive finger when I came across a piece about politics or technology news. These links, the bulk of my Twitter and RSS feeds, seemed important when they were new, but a few years later they’re kinda just not. The more urgent a take felt, the less likely it turned out to be an important one. Which is kind of a known thing.

Luckily for me, some of those older articles did stand the test of time. There was a 2010 posting based on a 1988 paper on defensive communication, and how spontaneity, provisionalism, and problem orientation can lead to better outcomes when giving feedback and communicating generally. So that was cool.

Incidentally, this was one of the pieces that aged poorly for another reason: archaic pronoun usage. Prose that I wouldn’t have blinked at 5 years ago sticks out now for strangely gendered pronoun usage, either due to authors flipping between “he” and “she,” or using the awkward “he or she” construct every time they need a pronoun. The singular “they” happened slowly, then all at once.

For every article that aged poorly though, there was a timeless classic. Stories of ages gone by, for example. I loved Nintendo of America’s weird origin story, the story of how NHL ’94 became a masterpiece, and how Starcraft barely worked and originally looked like some kind of acid trip.

I was also pleased to find great stories of great failures – whether it was massive oil rigs losing their way, massively acclaimed studios losing their best staff, or massively funded startups losing their grip. I tell myself I like to read about failures so I can learn from their mistakes, but there’s something more to it. I’m fascinated by the key element of failing at scale: hubris.

Nicholas Carlson spun a brutal tale of hubris in an excerpt from his book about Marissa Mayer and the Fight to Save Yahoo, which was fascinating albeit clearly one-sided. The piece wants you to think of Mayer as hopelessly arrogant, but she sounded to me more like a smart person trying really hard to move a beached whale on an impossible schedule. Fascinating nonetheless.

Hubris is maybe even more interesting when it doesn’t (quite) lead to doom and gloom. I enjoyed learning about Angus Reid and the power struggle at Vision Critical, and the wild way Elon Musk built SpaceX with sheer force of will. Either story might feel like a stretch as a work of fiction.

Remarkably, out of 372 articles I found but a single piece of fiction: the brilliantly written and provocative short story Cat Person. The fact this was one of the best articles in the bunch seems to indicate I should be reading more short fiction.

Beyond the hubris and the stories, I did find a few essays that should help me actually do my job. For example, two articles helped me refine my thinking on our labs projects at Steamclock: Aaron Harris’ Why Toys?, and an article about Teehan + Lax’s Labs program. I also got a good reminder from Rands that leaders need to Say the Hard Thing, and a peek at the culture that being too hard purportedly created at Amazon.

I also learned more about the confidence gap that is an obstacle for many women and marginalized people when building their careers, and the pernicious nature of “Assuming Good Intent” in codes of conduct.

As helpful as those few essays were though, I expected to have saved more solid articles on these topics. Building stronger products and teams is my job – I should be reading about it. Sounds like I need to improve my list of inputs.

Today, I read the the final article. I’d already finished the original 372, but I’d also kept adding new articles, so after roughly 400 articles, I finally finished The Trouble With Johnny Depp. I’m now at Instapaper 0.

So, did all that expand my mind? Maybe. A bit, yeah.

But in a bigger way I feel dumber. It feels as though the world of knowledge and ideas and stories that I don’t know has grown a lot, and the world I do know has only grown a little. Which makes sense – there are a lot more than 400 long form stories and essays worth reading, and it’s going to take a lot more than three months to read them. But I’m willing to try.

Armed with my Save for Later bookmarklet and my Kindle, I’m going to keep on reading. I’m going to expand my mind. I’m going to read those great articles, those great essays, and the great novels too. Yeah! Good for me!

I can start tomorrow.

A fun thing about programming is that most days, you make progress. Maybe you fix some issues, maybe you add a feature, maybe you build towards something bigger. Your code moves ever forward.

Until it doesn’t.

On occasion, you will hit a Bug. Not a mundane bug, some trifle you can fix in an hour, or even a day. This is a true Bug. One that defies reason. One that evokes a “that’s not possible,” a “how could this even happen?”, or most dreadfully, a “could there be a bug in the compiler?” Hold on kids, we’re going hunting.

Recently, I reported a regression in an app we’re working on: it had become dreadfully slow on launch. QA had noticed the issue too, which is good, but nobody on the development team had seen it happen – which is bad. Scrolling performance was awful on our CI release builds, but fine when the project was built via Xcode. The build settings seemed to be the same. Standard performance profiling turned up nothing obvious. We had ourselves a Bug.

Diagnosing and fixing a Bug requires patience, thoughtfulness, and above all a systematic, scientific mindset. We must eliminate variables one by one. Persistently forming hypotheses and testing each one is the name of the game. While the poor engineer assigned to hunt the Bug already knows this, it is our tradition to ease the pain by sharing the story of a legendary Bug Hunt.

Gather ’round, friends, for the Story of the Crashing Xbox.

You see, before Steamclock, my co-founder Nigel worked in the games industry. The games industry is very fun, when it’s fun. It’s also very not-fun when it’s not-fun. Games are particularly not-fun when you’re finishing them, so by law that’s when you will discover a Bug.

At that time, the team was working on what was to be one of the first games ever for a brand new game console, called the “Xbox”. As final testing ramped up, QA set up three pre-release Xboxen to run automated tests overnight. If the previous day’s build of the game was still running the next morning, it was a sign of a stable build.

Unfortunately, by morning one of the consoles had crashed. Crashes are never good, but this was a particularly bad crash: something running on the graphics card had brought the whole system down. Diagnosing a GPU crash meant hard mode: no debuggers, no stack traces, no “printf” debugging. All you could do is read the code and try things, like an animal.

And so began the Bug Hunt. Each day the lead engineer would comb through the evidence they had, develop a hypothesis, and work to eliminate possibilities. Each night, QA would get a “random” crash, without a clear cause. “That’s not possible.” “How could this even happen?” “Could there be a bug in the compiler?” All the greatest hits.

Naturally, the game ran perfectly well on the engineer’s machine – for multiple days, even. This was little consolation, as the deadline to print and ship the game loomed large.

Luckily, a pattern was soon detected – albeit a strange one. The game was only crashing overnight on one of the three Xboxes. A search for differences ensued. It wasn’t the power cables. It wasn’t the controllers. It wasn’t the order they were burning the DVDs. Bring the Xbox back to your desk – no crash. Put it back – crash. It was something about the very specific setup QA was using.

Now, the process of elimination requires eliminating all variables. So eventually, in desperation, the engineer tried one more thing: he shuffled which console sat on what table. Boom.

It wasn’t that Xbox that crashed, it was any Xbox sitting on that table that crashed. In the middle of the night.

Now, sometimes you need to do strange things for science, and this was one of those times. Stoically, the engineer set up a chair, gathered the requisite quantity of Red Bull, and the Bug Hunt became a Bug Watch. He vowed to watch the Xbox run automated testing on that cursed table until he saw the problem with his own two eyes.

The night passed by slowly, then quickly, and eventually dawn approached. The game still ran. Infuriatingly, it ran. The sun began to rise.

As he started to consider calling it for the night, something interesting finally happened: The Table was struck by a ray of light from the rising sun. Minute by minute, a sunbeam crept across the table towards the Xbox, its warm glow quietly enveloping that black blob of a console.

Which promptly crashed.

It turns out, early Xbox units had an issue where the graphics card could fault when the console reached a certain temperature. There was nothing you could do about it in software. The hardware issue was escalated, the game was cleared for release, and the Red Bull was swapped out for beer – or let’s be honest, probably whisky. Science one, Bug zero.

Back at Steamclock, our scrolling performance Bug was more straightforward. After some process of elimination and some teamwork, yesterday we tracked it down to our crash reporting SDK. A recent change in how the Buddybuild SDK interacts with iOS means that Buddybuild’s Instant Replay feature now causes severe performance degradation, which is very visible when scrolling. Feature disabled, problem solved.

Next time you hit a Bug that defies all explanation, it’s worth trying to channel the persistent and systematic nature of the Bug Hunters that came before you. Whether the Bug is in your code, a 3rd party library, or the thermal expansion of prototype hardware in the morning sun, the only solution is science. And maybe a little whisky.

In 2013, I decided it was time to start an iOS development meet up. I’d run VanJS for many years, which was great. There was one thing about running VanJS that was not great though, and that was using Meetup.com.

You see, Meetup is optimized for getting small groups assembled and running. A huge proportion of Meetup’s focus is around making it easier for groups to organize, socialize, and maintain their momentum. Meetup continually adds new ways for members of a group to post various things to the group. If your goal is to have as many Meetup™s as possible surviving and paying dues, optimizing your KPIs for optimal synergy, then this is great.

This is not as great if your goal is to curate a high-quality speaker series for a group with 3000 members, watched hungrily by dozens of hungry recruiters and other loud individuals.

For example, a few years back Meetup added comments to events. They also opted everybody into notifications, as is the style. This probably worked fine for groups with 10 attendees, but at that time we were organizing a large event with 200 attendees. Naturally, Rando Calrissian hops onto the event’s page to say “ill be 5 min late”, which caused Meetup to email 200 people the very important alert that Mr. Calrissian will be 5 minutes late.

In another fun encounter, I started getting urgent messages asking things like “I can’t get in, where is everybody?” I briefly panicked. Had I organized an event but forgotten to attend? I checked my Meetup page, and although I hadn’t, somebody else had! Meetup had quietly added the ability for all attendees to “propose” events, and assign them dates and times, and send announcement emails, without necessarily ensuring that there was a venue or staff or anything associated with that event. So a bunch of people showed up at our usual auditorium, for a talk that somebody had offhandedly suggested. Unfortunately, the auditorium costs $500 and needs to be booked weeks in advance, so this resulted in some poor customer sat.

An interesting problem

Given all that, I wasn’t keen to start another group on Meetup. And doing some research, chatting with other event organizers, I learned that many organizers weren’t keen on Meetup either. Complaints about the lack of control were plentiful. Multiple Meetup customers told me point blank, “I hate Meetup.”

A lot of the complaints centered around the UI. Meetup’s interface is full of feature clutter and bloat. They even have a feature where you can print out a checklist of attendees to check them off as they arrive. Who does that? In part due to this chaos, Meetup’s look and was about a decade behind the times – not the best for events focused on cutting edge design and development.

In contrast, I saw that CocoaHeads Montréal had a simple custom site that presented Just the Facts: the events, where they were, and how to RSVP. It was a breath of fresh air, and far closer to what I wanted for our new group than could be configured on Meetup.

So, we spent a couple weeks prototyping a custom web app, which we called Caravan, for our new iOS meet up, which we called VanCocoa. We left out all of Meetup’s social features, spam, and list-printing doodads. Instead, we focused on what we saw as our key differentiator: Caravan pages would be simple, attractive, and easy to use. In particular, went to great lengths to not require attendees to create accounts – years before it was cool.

That August we hosted the first VanCocoa using Caravan. Although people liked the event and the site, I immediately started to receive a lot of support email about it. 90% of the issues stemmed from my brilliant idea of not requiring accounts:

• “Did I RSVP?”
• “How do I un-RSVP?”
• “I accidentally RSVPed twice with two different emails, what do?”
• “Do I have to re-type my email each time I RSVP?”
• “I accidentally RSVP’ed to another event using a different email address than I’d used before, and now I’m getting announcements to both emails, can I just merge them somehow, should you maybe just have some kind of account login?”

We were able to fix some of these in a workable way without requiring people to create accounts, but the product design challenges around avoiding logins made it painfully clear why every product in the space requires account creation for attendees. Blech.

Meanwhile, I started demoing our Caravan prototype to the Meetup organizers who told me they hated Meetup so much. Each organizer was excited to see our progress, but had a feature request. Which is great! Every person’s feature request was different than every other person’s. Which is not great.

One organizer wanted to charge fees. One organizer wanted a message board. Another wanted a poll for pizza preferences?

My favourite was the Meetup organizer in New York whose venue had some security rules that required them to do paperwork for every event. Before attendees could enter the venue, a security guard needed to check them off a list – a list they generated with the very Meetup feature I’d been using as an example of needless bloat. Well, f.

As if that wasn’t bad enough, we were soon offered a cool new venue for VanCocoa. It was very nice and well located, but had a catch: they needed us to sign attendees in. From a list. Well, ff.

Perhaps even worse, we saw first-hand the power of Meetup’s network effects. Where our VanJS group on Meetup naturally grows substantially every month just by being an active tech event in Vancouver, our Caravan-based group grew ever so slowly, despite having talks of the same caliber. The iOS development community here isn’t quite as big as the web development community, but it’s strong and healthy – something that just wasn’t reflected in the attendance for VanCocoa, despite glowing reviews from attendees.

What do

Given what we’d learned from our prototyping and interviews, we went back to the drawing board and did some design explorations for what a “Next Generation” Caravan could look like. The more we explored and the more we talked to organizers of large Meetup groups though, the less it looked like there was a clear niche for a simple, beautiful Meetup competitor focused on large tech groups. Around that time I saw that CocoaHeads Montréal, the group that inspired Caravan in the first place, started using Meetup themselves. 😕

So, we decided to shelve further development on Caravan and focus on other products we wanted to explore. We kept the site running for VanCocoa for some time, but this winter I sent out a survey of the group asking about future directions. Besides positive reviews, a big message that came back was that we should switch to Meetup – even though people liked Caravan better – because more people would find the group that way. Well, who am I to argue?

So today, we finally ported VanCocoa to Meetup. We also took the opportunity to rebrand: next week will be the first ever Vancouver Xcoders. We’ve always had a great relationship with Seattle’s Xcoders group, and it felt right to join forces. If you’re in Vancouver or visiting sometime, and you’re interested in giving a talk about development in the Apple ecosystem, let me know.

Of course, Meetup is still bad. Very bad. But there’s nothing like trying to build your own thing to help you appreciate the bad thing you don’t need to maintain. And I’m pretty sure the network effect and new name will bring together more of the Vancouver iOS community, and – perhaps more importantly – a more diverse audience beyond the bubble of folks that knew about VanCocoa.

Of course, if you do end up beating Meetup at their own game, please drop me a line.

Canada has a cheese problem.

Back in 1970, dairy farmers convinced the Canadian government to enact something called the “National Milk Marketing Plan”. This regime greatly restricted the production and sale of dairy, creating a cartel. The goal was to increase dairy prices in Canada – because who doesn’t like high prices? However, in the 48 years since the cartel was established, something strange has occurred: we’ve had high prices.

How expensive is cheese in Canada, you ask? Well let’s consider pizza, everybody’s favourite cheese delivery mechanism. There’s a big nationwide chain here called Boston Pizza that sells, among other things, pizza. A large pepperoni pizza at Boston Pizza is $30.28.

At Pizza Hut in the US, they currently have a deal on where you get a large pepperoni pizza for $7.99. That is less than $30.28 – even after health insurance premiums.

Now, would I recommend paying $8 for a Pizza Hut pizza? No. Would I recommend paying $30 for a Boston Pizza Pizza? Also no. Should we be eating pizza in the first place? Well, yes, pizza is delicious. As is cheese – but it’s slightly less delicious in Canada, because it’s god damned expensive.

It’s so expensive, in fact, that pizza places estimate their daily food cost with a single number: Cheese Cost. My brother used to work at a pizza place here, and the manager only wanted to know two numbers at the end of the day: revenue, and Cheese Cost. Meat? A rounding error. Vegetables? Irrelevant. Show Me The Cheese.

With these cheese prices, you would expect a healthy import market. Except not, because dairy tariffs in Canada are 245.5%. That is to say, if you want to import a $4.99 block of sharp Tillamook Cheddar, it will cost you $17.27 after import taxes. Surprisingly, there ain’t a lot of sharp Tillamook Cheddar here.

Still, the cheese must flow. A few years back, some clever pizzeria owners noticed a loophole in Canadian customs laws. While there is an obscene tax on importing cheese, there was no such tariff on importing “food preparation items”. In 2011, the border lines swelled with restaurateurs filling their cars with Costco pizza kits. These kits contained highly sought-after mozzarella cheese, conveniently packaged with pepperoni and pizza crust. Once these bootleg kits got into Canada, the cheese went right onto freshly made pizzas, and the pepperoni and crust went right into the trash. Restaurant margins 1, a functional system of trade 0.

While that loophole has since been closed, our whackadoodle dairy controls continue to cause grief of an international scale. Canada’s largest trading partner, for example, was recently taken over by a feral animal of some sort, resulting in a dispute over free trade. While most of the “reasons” for the trade dispute amount to flaily nonsense, our dairy cartel is rightly a point of contention.

America, Europe, and the world all want to offer Canadians great cheese at reasonable prices. Yet 12,965 dairy farmers are holding our nation hostage. They have created a world where a milk production quota costs $35,000 per cow, and a restaurant can charge $30 for mediocre pizza and stay in business. They have used lobbying and cheesy cheese ads to lull us into submission, and as a result, have reduced the availability of cheese in this otherwise fine country.

This cartel causes there to be less cheese, and that is a crime.

Or at least, it should be.

Update, April 3

Folks have been writing in to inform me that comparing Boston Pizza’s regular prices with Pizza Hut’s sale prices is not an equivalent comparison – which is true, since Pizza Hut is garbage and Boston Pizza thinks it’s people. So as my apology to Canadian dairy farmers, here are some additional facts people have sent in:

• Milk in Canada costs 2x what milk across the border does, but due to labour costs the difference in bulk cheese is usually less dramatic.
• USD and CAD are different currencies which fluctuate over time, increasing or decreasing the on-paper price of goods and services.
• The Canadian dairy cartel generates substantially less profit than the Mexican drug cartel does.
• Pizza Hut also has sale pricing in Canada.
• Boston Pizza is attempting to expand to the United States under the brand Boston’s, where they also charge too much for pizza.
• Whiz is not one of the styles of cheese recognized by the Canadian Dairy Commission.

Update 2, April 13

I have received many additional messages informing me that sarcastically comparing the price of highly divergent pizza vendors does not constitute a scientific evaluation of the international cheese trade. Thank you for your heartfelt messages. Unfortunately I left my Cheese Economics diploma in the car, but if you’d like a more reputable source for the claim I actually make (that the Canadian cheese market is silly), I invite you to read this Globe editorial on the cartel, or this CBC article on a police officer who was arrested for smuggling cheese – for use in pizza.

Email is awful.

Don’t get me wrong, some specific emails are delightful – who doesn’t love a short, thoughtful note from a friend? An inbox full of noise though? What a drag.

So what do? Sure, you can start unsubscribing from mailing lists and notifications – as many as possible, ideally. Still, there will always be a category of email that you sort of should be getting, but that is semi-automated and not time sensitive and annoying in aggregate. You know the stuff I’m talking about. Receipts. Invitations. Notifications. 53 emails from iTunes Connect about increasing the price of apps in Armenia by 7.7% effective January 2018.

So here’s a new rule for your inbox: humans only. If an email was sent by a bot or service, it shall be filtered with great vengeance. Your Amazon order has shipped? Filtered. People liked your tweet? Filtered. Somebody would like to sell you SEO or offshore development services? Filtered, to be ruthlessly marked as spam.

Luckily, if your email is hosted by Google this is easy to set up – even if you generally read your email in Apple Mail. Just follow these easy steps:

1. Notice your inbox is inhumanly cluttered
2. In Gmail on the web, check a message that was not sent by a human
3. Click “More” → “Filter messages like these”
4. Verify that Gmail’s proposed filter looks reasonable (it usually is)
5. Click “Create filter with this search”
6. Check “Skip the Inbox” and “Also apply filter to matching conversations”
7. Create the filter
8. Repeat until your inbox is human-only or you achieve inner peace, whichever occurs first

With this setup, countless pseudo-important emails will skip your inbox, but stay unread so you can review them if and when you like. Meanwhile, your actually-important emails from real people will have room to breathe. Using this approach, I’ve cut my inbox to a fraction of the volume it once had.

While simply shunting automated mail to your archive is a good place to start, there are a few Advanced Techniques™ that can help keep your inbox healthy:

• Applying a label to filtered mail so you can see an unread count for it
• Exempting some emails from filters if they include your username (for example, GitHub issues assigned to you)
• Marking archived email as read automatically, for emails you need a copy of but don’t actually read
• Deleting email outright, for that goddamn airline mailing list you can’t figure out how to unsubscribe from no matter how many times you try, those shameless goons

So give it a try. Next time email chaos is wearing you down, spend 10 minutes humanizing your inbox with some well-placed filters. Your humans will thank you.

If you’ve been doing the same thing for a while, it’s time to try the opposite.

As you age, you tend to double down on what you like – or at least, what you think you like. However, sticking with what you know is the short-term play. The more conscious you are of that, the richer your world gets.

For example, I like deep games. Building a team, a story, or a whole civilization is satisfying. After completing a particularly egregiously long story-driven RPG, I knew it was time for the opposite: Fortnite Battle Royale, a chaotic 100-player free-for-all. It’s not what I usually like, but it was time to shake things up. Turns out, abject chaos is a crapton of fun. Not only did I get a change of pace, I discovered a whole new genre to enjoy.

Our habits tend to fall into local maxima. We choose well compared to similar alternatives, but ignore options that are totally different yet possibly better. Machine learning algorithms avoid local maxima by occasionally testing random permutations, with techniques like simulated annealing. People can do the same thing by periodically trying something way outside their norm.

With this in mind, I propose a rule of thumb: for every 10 times you do what you know, what you like, or what you’re good at, give the opposite a chance.

Mostly stick to rock music? Listen through a Taylor Swift album. “Know” you prefer writing UI code? Pick up a low-level networking task. Always order the burger? This time, take a chance on the Zanzibari Mackerel with House Special Sauce.

Typically write long articles? Try a short one. 🤷‍♀️

It might not work – but maybe it will. Either way, you learn.

I’m officially sick of hearing about blockchain.

As the recipient of various “idea for an app” emails every week, I don’t have much patience for get-rich-quick schemes. Suure, you’re going to put hyperlocal photo messaging “on the Bitcoin”, good luck with that, don’t talk to me or my son ever again.

Recently though, things have shifted on the blockchain front. After two years of monotonically increasing hype and my corresponding antipathy, I’ve started to get uneasy. While you can (and should) dismiss Bitcoin as a structurally unsound bubble of cosmic proportions, there’s an aspect of blockchain technology that is harder to understand, and thus dismiss: smart contracts.

As fun as it is to kick back and laugh at dumb tech fads, it is important to first understand how and why they’re dumb, so we can mock them soundly and accurately. Before I could let “blockchain” join “bitcoin” in my Twitter mute-filter dungeon, I needed to go on a journey. I needed to understand what smart contracts actually are, what they mean for the blockchain, and confirm whether or not they’re just the latest foolish escapade fuelled by a few billion dollars of VC crack.

Into the abyss

Dutifully, I dug in. Over the last month I’ve read hype pieces and cautionary tales, perused specifications and white papers, and even went to the extraordinary step of talking to somebody who actually knows what they’re talking about. I am now a world expert in blockchain, and I have news for you: it’s bananas.

Specifically, 1kg of bananas, grown in Laos, by shady Russians. Maybe.

Maybe grown, that is. They’re definitely shady Russians.

Let me introduce you to Bananacoin! In their own words, Bananacoin is:

The first environmentall friendly plantation in Laos which has released a utility token based on Ethereum, pegged to the export price of 1 kg of bananas.

Banana plantation is a real proof asset with blockchain inside. It is new technology of the agricultural sector.

At first I thought Bananacoin must be parody, but it is in fact more ridiculous than parody – it is a blockchain startup in 2018. As of this writing they have supposedly raised $1.9 million sight-unseen for unregulated Laotian banana futures.

They have a handy FAQ. What if there is a bad harvest? There won’t be. What if the price drops? It won’t. Why use blockchain at all? “Good question.”

Wait.

Why am I talking about Bananacoin? This piece is supposed to be about how smart contracts work and whether they’re good for anything. Unfortunately, trying to discover what blockchain might actually be good for is incredibly difficult when 99% of the news about it is a relentless hurricane of irrational exuberance and exuberant meltdowns. Whether it’s government crackdowns, Bitcoin’s rise to $20,000 USD and immediate crash of over 50%, or the latest coin to “exitscam” investors that simply replaced its website with the word “penis”, crytocurrencies and ICOs are a staggering shitstorm right now.

Thankfully, we can actually ignore that part. Bitcoin is a ponzi scheme, ICOs are basically just unregulated securities, and getting involved in all that today is like investing in tech stocks in 1999: you’re gonna have a bad time.

Let’s just put that aside for now. The actually interesting thing lurks under all this chaos: smart contracts.

Here’s the deal

So, Blockchains are distributed databases. They store data in a peer to peer fashion, kind of like BitTorrent or Cassandra if you’re familiar with one of those. The clever thing is that blockchains use cryptography to maintain consensus in the system without the need for centralization. This lets them securely implement constraints like “no double spending” in a distributed way.

While this is a interesting theoretical property, it has one main application so far: digital currency. So Bitcoin is a thing, along with the million altcoins and shitcoins that followed it. We now have a veritable smorgasbord of digital currencies, providing 20-somethings worldwide a way to engage in irrational speculation and, occasionally, buy drugs. Blockchain 1, skeptics 1.

Things got a lot more interesting more recently though. In 2015, a 20-year-old (sketchy) Russian-Canadian (double-sketchy) launched the first blockchain to really matter: Ethereum. The key question behind Ethereum is: “What if a blockchain had a full scripting language?” The answer to that question so far has been, “Wait, this… this may change the technology industry forever. Maybe. We’re not sure yet. But just in case, take literally all our money.”

With smart contracts, blockchain can be good for more than just cryptocurrency. Smart contracts make it possible to securely run Turing-complete programs on the distributed system. These programs can make evaluations, write data, and perform financial transactions. Beyond being a distributed database of transactions, Ethereum is actually a distributed virtual machine. A globally decentralized secure computing platform. Which is pretty neat.

If you’re like me, your first question was probably: wouldn’t that be really slow and inefficient and hard to program? And it is. At least so far. You can throw a blockchain VM at a bafflingly large array of problems, but it will only turn out to be good at a farily narrow subset. The trick is figuring out what kinds of things this system is good for.

Even at this early stage, simple smart contracts are being put to use that benefit from the system’s decentralization, distributed trust, and transparency. Looking at these can help clarify what kind of industries and products blockchain may actually be useful for, and which applications are probably just dumb.

Smart is in the eye of the beholder

Within like 30 seconds of smart contracts being a thing, people started making tokens with them. Tokens are simple smart contracts that put coins in your coins, so you can speculate while you speculate.

More formally, a token is a unit of trade created within a blockchain. They can represent anything, really: assets or funds, commodities or futures, Air Miles or Laotian bananas. Before Ethereum, experimenting with a blockchain-based unit of exchange required you to create and coordinate an entirely new blockchain system.

Now, you can spin up a standardized token just by filling out a boilerplate smart contract format called ERC20, then getting your script written to the Ethereum database. You simply implement six methods – totalSupply, balanceOf, allowance, transfer, approve, and transferFrom – and Satoshi’s your uncle.

Since smart contracts really are little computer programs, a token can behave in almost any way you can imagine: it can award bonus tokens in certain contexts, it can mediate, facilitate, or automate transactions, or it can just straight-up implement a ponzi scheme.

Just like that, you’ve created the next great investment vehicle, scam, or… okay, let’s be honest, it’ll probably be a scam of some sort. But tokens are the biggest thing to happen to scams since the internet. Whee.

So cryptocurrencies make it easier to buy shady things, and smart contracts make it easier to offer shady investments. That’s great, but we have a strict no-shadiness policy at Steamclock (this policy actually exists and I’ll tell the stories of the clients that led to it another day).

Given that, I wanted to understand: what might Blockchain and smart contracts be good for that may deliver actual value to people and businesses? If smart contracts can do anything, what is worth doing with them? That’s the billion-dollar question, and there are some surprisingly plausible candidates for non-dumb applications of smart contracts. Things that are totally not scams that actual smart people are working on with real business cases.

Three contenders

While blockchains’ distributed security and trust models can facilitate shady behaviour, they seem to also be useful for combating certain types of shady behaviour. As far as I can tell, this seems to be where the most promising applications flow from. Beyond the “gimme” interbank finance applications, these are the three best examples I’ve seen so far:

1. Supply chain management

Modern supply chains are fiendishly complex, and offer countless opportunities for shadiness. Counterfeiting, lax quality control, mislabelled materials, adulterated ingredients, and the use of unethical labour are all difficult to track down and eliminate from a complex supply chain. Blockchains’ security, decentralization, and immutability could be useful tools in this space. You can’t stop suppliers from trying these things, but you could potentially trace back who is doing what, and cut them out of future deals.

Imagine you need 40,000 high-grade steel widgets ASAP. Today you might call up a supplier, and try to work out the quality, provenance, and location of the various widgets on the market. Alternatively, a blockchain could tell you that the parts you need are in a warehouse right down the street, what their purity and provenance are, and give you a traceable record of everyone who has contributed to its current state and location.

Verdict: Maybe not dumb.

2. Trading digital art

As art has moved into the digital world, we’ve mostly lost the idea of ownership – nobody really collects digital fine art. On a blockchain, though, it’s possible to encode and verify the ownership of digital assets. You can also track provenance, verify scarcity, distribute royalties, and even wire things up so partial proceeds of resales go back to the original artist.

In the last year people have used Ethereum to collect punks, weird art, and self-replicating digital felines. There is a lot of exuberance in this space, but unlike the various token offerings, it tends less towards scams and much more towards experimentation and fun.

Also, the sheer novelty of using blockchain smart contracts to implement a genetic algorithm for breeding digital art is kind of staggering. Like, if you can do that, what else can be done? How weird and wonderful can it get?

Verdict: Possibly dumb, but surprisingly neat.

3. Voting

Now, we should always be skeptical of digital voting. That said, it sounds like blockchains’ transparency, security, and decentralization may make it the least dumb digital voting technology proposed so far. Using smart contracts, you can build an open-source voting system that allows people to cast secret ballots that they can still verify, and also make the system-wide tallies independently verifiable by any party.

While digital voting is still terrifying, and the incentives to subvert the system are high, the prospect of securing votes on a blockchain is at the very least intriguing.

Verdict: Possibly the least dumb attempt in this space. But maybe still dumb. Time will tell.

The beauty of the unknown

The smart contracts of today are notoriously hard to write, often expensive to execute, and in many ways are a multi-billion-dollar science experiment. But that’s what makes them kind of interesting: they open up so many potential applications that people are going to have to actually try some of them in order to suss out what actually works. And that’s kind of exciting.

Of course, actually investing in any of these businesses at current valuations would be absurd – this stuff is hairy enough right now that the Apple or Amazon of smart contract platforms could be a decade out. And my personal specialty, building delightful product experiences, is probably best applied later in the tech cycle than “wait, what if this isn’t dumb?” But after a bit of time, maybe a lot of time, blockchain really might drive major changes in how some businesses function.

In the meantime though, I think it’s safe to kick back, eat a Laotian banana, and get back to enjoying blockchain for its entertainment value. Oh hey, it looks like the company most responsible for Bitcoin’s recent rally may just be a sham, and Facebook just banned cryptocurrency advertising. What a time to be alive! 🍿

Unlike us, our ancestors were calorie-restricted. Just like cats, pandas, and almost all large animals, humans have evolved a strong natural drive to be lazy. In the wild, laziness is smart business – seeking comfort and reserving energy for the hunt is a winning strategy in a harsh world.

Millions of years later though, things have changed. We have more food than we can eat, sinfully cozy couches, and our troubles have evolved from finding enough coconuts to dreams of self-actualization. Meanwhile, our monkey brains still tell us that the most valuable thing we can do is curl up beside a fire with a jumbo bag of Lindt Balls and sleep for 13 hours.

Our instinctual drive towards comfort no longer serves us well.

As a kid, I spent a lot of time strategizing how to maximize comfort. I’d position my computer so I could play games near a heating vent, go to great lengths to avoid being outdoors, and find inventive excuses to avoid exerting myself. Surprisingly, I was not a particularly athletic child.

For example, I liked the idea of playing hockey, but there were a couple obstacles between young Allen and NHL stardom. For example, you may not know this, but ice rinks are awfully cold. Ice skates also pose a serious threat to comfort: if you lace them tightly you’ll hurt your feet, but if you lace them loosely you’ll hurt your ankles. In the face of such a dilemma, I would lace them half-tight. This approach ensured both my feet and ankles hurt, proving once and for all that sports are dumb and we’d all be better off at home under a blanket.

Whether I was attempting a sport, suffering greatly through one of Vancouver’s famously mild winters, or being subjected to the ordeal that is Phys Ed, I spent a lot of my childhood being indignant about being uncomfortable. This was rather apparent, so from time to time, an adult would try to upend my worldview with the pithy wisdom, “no pain, no gain.”

Oh, how I hated that phrase. Steeped in macho tough-guy attitude, it was toxic masculinity before I had a name for it. The idea that there was some sort of competition to experience pain was the dumbest thing I’d ever heard.

The manly glorification of discomfort simply reinforced my slothful attitudes. I don’t need to freeze to death or crush my feet just to enjoy hockey – I’ll just collect hockey cards! I’m not lazy, I’m rational!

As a teenager I would seek schemes, sometimes elaborate ones, for how do the minimum amount of work, whether by automation or social engineering. I would calculate how much each assignment was worth in a class, what my target grade was, and determine the minimum amount of work I had to do to get the grade I wanted.

Basically, I was a little shit.

Many years later, I found myself revisiting learning how to play hockey, and found myself again staring down a pair of skates. Funnily enough, if you just lace skates tightly, and have a good attitude, it’s a non-issue. Your feet grow some little calluses where needed, but you soon associate any remaining discomfort with the satisfaction of skating well. If you focus on the end result, the discomfort becomes irrelevant.

Now, this is obvious to anybody who is into fitness. To a waifish programmer though, it was a blockbuster new thought technology. Overcoming discomfort is a skill. Shrugging off the frosty air while you take out the garbage is a talent. Posing uncomfortably until the photographer gets the shot they want is an art. Calvin’s dad actually had a point!

Discomfort, by its nature, is perceptual. There is a beauty to taming and controlling it. There is a way to find the joy in satisfyingly tight skates, the sharp winter air, or the soft burn of newly formed calluses. While I grew up thinking of comfort as a human right, I now see it as a blanket: good for bedtime, but often impractical.

While I still take issue with “no pain, no gain”, I must admit it’s catchier than “Discomfort is typically an opportunity for growth.”

So, as we assess the past year and consider the next, it’s worth thinking about discomfort. What habit could I start that would be uncomfortable at first but soon become routine? Is there an uncomfortable thing I’ve been avoiding that, once done, would reduce my stress?

It’s also worth thinking about comfort. Comfortable habits have a tendency to outlive their usefulness for recharging or relaxation. For the comforts you indulge in daily, consider: do I get an important boost from this, or am I spending 4 hours a day on the couch just because millions of years ago some monkeys couldn’t scrounge up enough coconuts? It’s a question worth asking.

Then, lace up those skates. Donate the rest of the Lindt Balls to the office kitchen, and go make 2018 a better year than 2017 – just slightly less comfortable.

The iPhone X is packed with new and novel technology. Face ID. OLED. Dual cameras in a compact package. As fascinating as that all is though, it has an unusual property that been little discussed: this phone is really, really tall.

iPhone X’s screen is the tallest ever in an iPhone. It’s 30% taller than the comparably-sized iPhones 6 through 8, and even 11% taller than the enormous iPhones Plus. Meanwhile, it is only slightly wider than an iPhone 6. As a result, the X’s display has a downright Chockian aspect ratio of 2.17 to 1.

That is to say, it is tall.

Unfortunately, this has fuelled the Apple-hater meme that the iPhone X isn’t usable one handed. According to these pundits, reaching Control Center is “damn near painful”, “you need to shimmy it every time”, and “it feels like I’m going to drop my phone, Jesus this thing is as slippery as a wet bar of Pears.”

While it may be true that this ultra-tall screen makes Control Center and other top-oriented UI frustrating to use, it’s worth remembering that iPhones are designed by some of the most talented and creative people in the world. Apple’s industrial designers must have prototyped shorter phones with the same edge-to-edge design. They also surely evaluated making it slightly wider to make it better for reading on. But after all their testing, they decided that the “phone of the future” should have a tall and narrow screen. So let’s ask: why?

Room for activities

Anybody who has used an iMac or iPad Pro knows that a larger screen can make you more productive. Big screens allow you to keep multiple apps on screen at once, and they can acommodate wider, more readable line lengths. The iPhone X’s tall screen does neither of these things – but what it does do is show more lines of text at once.

Now, you may ask: “Doesn’t increasing the aspect ratio beyond the 1.8:1 ratio of human vision provide little value, especially considering the narrow height of the retina’s focal area?” And I would respond by saying: why are you asking me this? I’m not a doctor. Do I look like a doctor?

Okay whatever, maybe a narrow aspect ratio isn’t ideal for text, but let’s be honest: kids these days don’t read anymore. It’s all about photos and videos, and that’s what the new iPhone’s Super Retina display all about.

If you’re a photographer, you may know that really wide screens are great for viewing images, if those images happen to be panoramas. If you’re a fan of panoramas, the iPhone X’s aspect ratio is perfect for you. Even if you’re not, you’ll find that displaying normal photos on iPhone X is also possible.

Another place the iPhone X’s aspect ratio shines is movies. While it has been observed that the screen is effectively no larger than an iPhone 6 for watching TV or YouTube videos, iPhone X’s 2.17:1 format is nearly the same ratio that Lawrence of Arabia was filmed in. Lawrence of Arabia! In fact, most theatrical releases are filmed in an even wider ratio, 2.39:1. This makes this otherwise strange aspect ratio great for watching feature films, which is excellent if you’re the kind of person who likes to kick back for three hours and watch The English Patient on your phone.

Lay of the land

Although text, photos, and videos are the primary content people care about, it’s also worth considering what benefits an exaggerated aspect ratio has for app UI.

While landscape apps on iPhone X are as cramped vertically as they are on an iPhone 6, iPhone X gives app developers a lot more space available beside their content. As a result, you get to enjoy much more of your favourite apps’ background colours.

Typing in landscape on the iPhone X is especially distinctive. The keyboard appears front and center, while still giving you enough space to see not only the line of text you’re typing, but often the line before and after it.

A tall order

In summary, the surprisingly tall aspect ratio of the iPhone X has a non-zero number of advantages over a more ergonomic screen height. While a somewhat shorter display would be easier to hold, use, and develop for, it would be substantially worse for watching Peter O’Toole tromp around the desert.

Now that we’ve entered the iPhone’s “Generation X”, there is speculation abound about what other screen sizes may be available in upcoming designs from Apple. Will 2018 see an iPhone SE-X that offers most of the iPhone X’s screen width but with a more thumb- and pocket-friendly height?

No.

Will we ever understand exactly why the iPhone X’s display is so curiously proportioned? Also no.

No, our job is not to understand. It is to stretch our thumbs, put cases on these beautiful glass slabs, and appreciate that despite its flaws, the iPhone X is a truly remarkable device.

Even if it is a little bananas.

Being a generalist is great fun. There is much joy to be had in jumping between programmer and artist, project manager and product designer, bug finder and bug maker. You can also be a musician and athlete, parent and world traveller, superfan, superstar, and whatever else strikes your fancy if you invest the time. The world is your bivalve!

Generalists are ideal team members for startups and small product teams. Product teams that are themselves generalists – they are capable of working on many kinds of products – are also primed for success in a tech industry that walks ever randomly. Heinlein said “Specialization is for insects”, and he was mostly right.

There’s one problem though: it’s hard to sell somebody a mixed bag.

“So tell me, what are you good at?”

“Well sir, I’m okay at everything.”

“Sure, but what’s an example of a really exceptional project you’ve worked on?”

“Uh, well, I made a proof-of-concept Rails app, I designed some reasonable labels for a craft brewery, I wrote a pretty okay musical…”

“Right fine, let’s switch gears. How many times have you written a realtime video app?”

“Well, I haven’t yet, but… I’m a fast learner?”

This is kind of shitty, since a lifelong learner with broad skills is actually a great addition to most teams – it’s just hard to stand out in a crowd of other self-proclaimed fast learners.

Whether you’re trying to get hired as an individual or as a company, there’s a trick to getting work: start by becoming a world expert.

Insert training montage

In some industries and some eras, becoming a world expert was a Herculean undertaking. After decades of training to become a master sushi chef like his father, Jiro Ono’s son was still working in the back, making the rice and toasting the seaweed. I mean, I bet he toasted some damn good seaweed, but… damn.

In modern software development, on the other hand, becoming an expert is just a thing you do. Part of the fun of software is that the tools and methodologies change at least yearly – or if you’re using JavaScript, they change every 16 minutes.

And thanks to the wonder of the Information Superhighway, you can typically experiment with and learn new technologies before they’re even formally released. You just need to play with some beta releases, read a couple mailing lists, and otherwise gather knowledge from sources that are just inconvenient enough that most people don’t bother. Next thing you know, you’re top banana at an exciting new technology.

Of course, nobody can be an early adopter like this for every technology – in fact, most developers, especially ones at larger companies, won’t be early adopters for any technology. They’re content to let the indies and enthusiasts research, experiment, and occasionally blow themselves up due to some dire documentation or dubious dependency.

In return though, the experimenters benefit from great demand for the lessons they’ve learned. As the bleeding edge becomes just the cutting edge, bigger teams and companies start investing in the latest new-fangled wizardry and need folks to help.

I learned the value of this by accident when we started Steamclock. At my previous job, I’d become pretty experienced with a relatively obscure web framework called SproutCore. When I struck out on my own, I started getting inquiries out of the blue from big businesses that needed help with their SproutCore apps. It turned out that as a young open source project, very few people outside Apple knew the framework, so when companies wanted to experiment with it, Steamclock’s site popped up in the search results. This got us a couple of our big early clients, and taught us the value in specialization – intentional or not.

Each time new technology debuts, new experts emerge. Erica Sadun jumped into Swift on day one, and has now authored more Swift language proposals than anybody in the world. When Angelina Fabbro worked at Steamclock, she went from checking out a draft spec for Web Components to touring the world giving talks how to implement them before I could blink. And of course, friend of the show James Thomson – under the guise of developing a calculator app – has rapidly remade his career as a world expert in ARKit bananas. Which is bananas. But also, wonderful.

Back in the day, there was an interview show on 5by5 called CMD-Space. Each episode, the first question host Myke asked was:

“What do you like to be known for?”

While it served its intended purpose of kicking off many a good interview, it also slowly worked itself slowly into the audience’s brains – a question worth having an answer to. “What am I known for? What do I want to be known for?”

As a product studio, Steamclock does client work in order to fund our own product work, so having a good answer to these questions is critical. If we’re not known for anything in particular, we’re stuck knocking on people’s doors, trying to get in the lowest bid on Tinder for Bananas. On the other hand, if we’re known for doing great work of a certain kind, leads will knock on our proverbial door. Almost all of our work comes from this kind of lead today, and it makes for a far healthier business.

The thing is, it’s not enough to be able to say you’re good at building apps for companies – you need to be great at something specific. Maybe you’re great at building beautiful apps for ecommerce companies. Maybe you’re great at building secure apps for enterprise companies. Maybe you’re great at building dumb blockchain apps for excessively funded companies. You can stay a generalist – generalists are great. Just be sure to specialize in something too.

Seek out the surprisingly attainable goal of becoming a world expert.

If you don’t, you’re bananas.

The modern world is filled with notifications. Our days hum with little vibrations, each requesting little attentions. Now, they come straight to your wrist.

In some ways, notifications can be great. Messages from friends and family are welcome. Knowing you’re reachable can make being a parent or a manager a less anxious experience. At their best, notifications free us from checking for status on the things that matter.

Other times, notifications are the worst. Nobody needs their watch to tell them about yet another geopolitical garbage fire, the arrival of their 437th unread email, or anything to do with LinkedIn. Thus, we clamp down on what notifications get through.

Even with a fairly strict notifications policy though, sometimes you’ll be in the middle of something that matters to you, receiving a barrage of notifications that are Not Important Right Now™.

Maybe co-workers are mentioning you in Slack. Maybe you’re unnecessarily being cc’ed on a Twitter argument. Maybe you just got sucked into the inky maw of a giant group Messages conversation. In any case, your phone is now going off like Hector Salamanca in the middle of your critical presentation to the Wisconsin Board of Cheese.

Turn It Off

Do Not Disturb to the rescue! Since iOS 6, we’ve had a handy toggle for situations like this. All you need to do is pull up Control Center, tap the little moon icon, and voila: you will no longer get notifications – until you remember to toggle it again, later that evening, when you’re the only person left at work, wondering why your wife still hasn’t texted you, and you have the dreaded realization that Do Not Disturb has been on for seven hours, so you finally toggle it and the notifications pour in, oh man how did I not notice this sooner, oh geez Rick this is bad.

It turns out, you usually only want Do Not Disturb on for a little while. An hour perhaps, or maybe until the end of the work day or the next morning. Unfortunately, it’s very easy to switch on and accidentally stay on. Admittedly, the feature does put a little moon icon up in the status bar – which is displayed when you look at your phone, which you’re not going to do much, because DND is on.

Put another way, future me is an idiot, and I don’t trust him to turn Do Not Disturb off.

Thankfully, a lot of notification-heavy apps provide a “snooze” feature with an appropriate timer. Slack makes it easy to squelch pings for an hour or two, letting you focus on the task at hand. Facebook Messenger, whose runaway group conversations have brought down many a DND hammer, also lets you mute notifications for a set time. Your friends are still your friends, even if they somehow inexplicably prefer Facebook as their means of communication.

As nice as these features are, it’s not exactly practical to hunt through your apps and dig up their snooze functions every time you need to focus on something. “You’re right, I apologize, those notification vibrations are a distraction – just give me a few minutes to go toggle a variety of snooze functions in various apps and then you’ll have my undivided attention.”

Advanced DND

This month, Apple augmented DND by adding Do Not Disturb While Driving. Now, you can have it mute notifications while you drive, without having to remember to toggle them back on when you’re done. This joins the longstanding Quiet Hours feature, which lets you mute notifications over night: Do Not Disturb While Sleeping. WatchOS 4 also added another contextual DND: Do Not Disturb While Working Out.

So that’s a start, but they have a long way to go. We also need:

• Do Not Disturb While Having This 1:1 Meeting
• Do Not Disturb While Presenting This Talk
• Do Not Disturb While Vacation Planning With My Wife
• Do Not Disturb While Reading My Daughter a Bedtime Story
• Do Not Disturb While Watching This Totally Awesome But Very Serious Scene That Finally Explains The Main Character’s Mysterious Origin

Basically, we need a way to tell our phones to leave us alone for an hour.

“Well Allen,” you might say, “since you’re so great at accurately predicting the future of Apple’s UI, where would the iOS team even put this supposed DND timer control?”

Well rhetorical internet person, luckily for me, I don’t really need to speculate: iOS 11 already has an alternate mode for Control Center widgets. Most Control Center widgets have a 3D Touch action now, but not Do Not Disturb. In exactly the way you can now 3D Touch the Timer button to set a countdown, you should be able to Go Deep on Do Not Disturb.

You should be able to push firmly, set “1 hour”, and tap “Start”.

Then kick back, focus, and be truly present – in manageable one hour chunks.