I’ve been reading Daniel Bogan’sUses This (née The Setup) interview series since I was a teenager. They chronicle interesting people’s hardware and software setups and end up being a fascinating window into the subject’s priorities and tastes when it comes to tools and toys.
My own interview just went up on the site, so now you can read all the nerdy details of my setup. Let me know what you think!
A few years ago, I let folks on Twitter ask for software recommendations for any problem they need solved with an app. People loved it and I loved helping people find the perfect software solutions to their quandaries.
This Friday at 3 PM ET, I’m experimenting with a version of the same thing on Clubhouse co-hosted by my friend and colleague, Jillian Meehan. It’ll be be a fun, nerdy time and we’d love to see hear you there.
PS: If you need a Clubhouse invite, let me know and I’ll send you one. ✌️
I turned 30 years old today so I spent some time this afternoon reflecting and collecting 30 lessons I’ve learned in my time on earth so far and (as best as I could remember) where I learned them from.
Merlin and Roderick sometimes call these types of lessons “thought technologies” and that certainly feels fitting considering how useful and applicable they’ve been for me. Each one of them has helped me during critical moments in my life so far. I hope you find even just one of them helpful in yours. See you tonight. ❤️
Tech is always political. The way data is collected and handled is often biased, and many products are neither accessible nor inclusive. Ethical Design Guide is made to share resources on how to create ethical products that don’t cause harm.
Sarah L. Fossheim just released this wonderful collection of resources (and monthly newsletter) on how to make digital products more inclusive. It covers topics from accessibility, to race, to gender. I know I’ll be bookmarking this and referring to it often. Huge thanks to them for putting this together. (Via Jillian.)
For the last few years, every time the holidays roll around, I make a big batch of Jeffrey Morgenthaler’s Clyde Common Egg Nog for my family and friends.
Since I won’t be seeing them this year due to the pandemic, I made a video showing everyone how to make it (which Jeff seemed to like). Enjoy! And let me know what you think if you end up making a batch. 🎁
For Sloan and her partner, the answer became clear after the two spent a couple months together at the beginning of the pandemic because of COVID-related travel restrictions—and they decided to choose both. “I knew this was the person I wanted to marry, and I wanted that so strongly that the odd circumstances didn’t even bother me.” said Sloan. Though they’re still living in different countries now, the two were wed in a small ceremony in Madison Square Park this November.
In general, you don’t need a reason to want to start a relationship with someone far away. Regardless of your situation, sometimes you find a person, you both feel a genuine connection, and you can just tell their company would enrich your life. That can all happen online with someone who doesn’t live near you, with the same sort of chemistry as a more proximal partnership. When it works, it just works—and it’s more than worth it.
Some people have their weddings announced in The New York Times; Kate and I are clearly more of a VICE couple. But seriously, if you’re curious about how to date online or whether you should consider long-distance relationships, this piece by Chingy is a must-read.
Tone indicators are most popular within some Twitter and Tumblr communities of young people with overlapping interests in identity representation, anime and K-pop fandom, twee aesthetics, and sensitivity toward mental health and gender issues. It’s a milieu where inclusivity is considered a paramount virtue. These people use and like tone indicators because they want to help others have better experiences online.
In recent weeks, several users have posted lists containing dozens of tone indicators ranging from “/j = joking” to “/lh = lighthearted” and “/nsx = nonsexual intent.”
I love how much folks in gen Z are using the tools of the internet and their digital-literacy to improve inclusion, how much they’re thinking about the needs of neurodivergent people, and how this kind of accessibility is gaining a kind of mainstream momentum.
As technologists, we should be following these conversations closely and finding ways to build support for tone indication, content notes/warnings, and other new ideas about communion directly into the tools where appropriate. We should be enabling and empowering better, more nuanced conversation within the software itself.
The latest episode of 99% Invisible details the history of and hopeful future for bathroom design. With a focus on the needs of trans and nonbinary people, Susan Stryker and the other members of a project called Stalled! have recently won a major victory in the International Building Code that will allow for better bathrooms for everyone. In her words:
What I feel is so elegant about the Stalled! public toilet project is that at some level… it doesn’t matter what most people think about trans people. It doesn’t matter if you feel like you should accommodate people with disabilities… The design of the space just solves the problem.
If you’re a parent or thinking of becoming one, read this essay about my friend Sarah (they/them) and how their mom, who’s an anthropologist, responded when they came out to her as agender. I was already crying five sentences into this piece, but the conclusion is what really got me.
I am thankful for their permission to tell a part of their story here. As I think how best to end this essay, I am filled with one upwelling sensation. I am proud to be the mom of a wonderful person—one who works tirelessly for social justice, and who lives as neither a woman nor a man. To love them as they are is a gift of my life.
Things are changing. People around the country are finally recognizing what black people have been telling us forever: that white supremacy, structural racism, and police violence are endemic in our culture, and it’s killing them. If you’re overwhelmed or having a hard time figuring out what to do right now, my friend Jillian Meehan collected this list of places to start. #blacklivesmatter
If there’s one aspect quarantine life has shown me is that there’s a wide orbit of things you’ll refrain from wanting to do because the results may not come close to what what you’re use to. There’s limitations. The quality may be different. Heck, the actual process of doing this new thing may require a different side of you that you probably haven’t developed yet and on top of that the people you may ask to assist you with it might consider you crazy. In the end what’s mostly permeating through my mind is how can one explore ways to continuing being creative during times where it seems like there’s not much to work with.
What does it take to build software that’s truly usable for as many people as possible?
This morning, I’m giving a talk on this topic at App Builders 2020. The presentation focuses on improving the accessibility of the software we build. Drawing on examples from the fields of architecture and design, as well as my experience, it explores the how and why of iOS accessibility in the broader contexts of ability and inclusion. You’ll learn how to audit your application for accessibility and get started making changes that will open it up to new customers.
The medical evidence for the practice is overwhelming. The post-SARS countries in East Asia have known this for a long time, and America and Europe are finally coming around. I’ve put a bunch of resources about the medical benefits of mask wearing in a further reading section at the bottom of this post.
But in this essay, I want to persuade you not just to wear a mask, but to go beyond the new CDC guidelines and help make mask wearing a social norm. That means always wearing a mask when you go out in public, and becoming a pest and nuisance to the people in your life until they do the same.
A very persuasive essay from Maciej Cegłowski, the founder of Pinboard, about the whys and hows of wearing masks in public. I started wearing one yesterday for the limited time I was outside, and the medical community seems to now be recommending that everyone do the same. It’s also worth reading Ben Thompson’s take and checking out these simple mask-making instructions from Loren Brichter.
While there are lots of great guides on how to work remote from companies like Notion, Zapier, and Slack, we thought share some of the specific tools we’re using to make this easier for our team. Hopefully, if you’re a newly remote employee or manager, you’ll see something here that can help smooth out a part of your workflow.
I wrote a new blog post over on the Lickability blog about the new tools we’re using to work from home better and some tips about how we’re using them. 🛋
The delightful weirdos over at performance art/tech company MSCHF just launched a new app. The app does what they used to do via text messages until the phone companies starting blocking their numbers: allows you to chat with them and sends you a notification every two weeks when they announce drop their new project.
Helpful Engineering is designing, sourcing and executing projects to help people suffering from the COVID-19 crisis worldwide.
We are an open community of volunteers without a commercial purpose. We believe that through a utilitarian approach, we can do the most good in the quickest time. Applying unused engineering and manufacturing resources, we can help the world cope with the threat of COVID-19.
I’m super impressed by the speed and organization of this group of volunteer engineers that are working on a number of really useful projects in the midst of the COVID-19 pandemic. If you’ve got spare time, resources, or engineering know-how, consider joining their efforts.
At Patent Pending, a Flatiron coffee shop cum speakeasy, every cocktail order automatically comes with a bag of chips so as to not run afoul of the liquor delivery rules, and any order over $50 gets a free roll of toilet paper, one of the most popular items during this pandemic panic. But despite the quick response to sell delivery alcohol under the new rules, this will not save the bars and restaurants.
“We could survive a month and a half on delivery,” said Nicholas Ruiz, general manager at Patent Pending. “We’re just trying to be a little beam of light for some people.”
A man in California is haunted by the memory of a pop song from his youth. He can remember the lyrics and the melody. But the song itself has vanished, completely scrubbed from the internet. PJ takes on the Super Tech Support case.
I’m way behind on podcasts, but at least I’ve got plenty of time to catch up since it looks like we’ll all be stuck inside for the foreseeable future.
After seeing this recent episode of Reply All recommended everywhere, I gave it a listen, and it’s as good as everyone says it is. Queue it up if you’re interested in music, mysteries, obsessiveness, journalism, or the intersections thereof. Also, if you want more like this, go back and listen to Mystery Show. RIP.
The exhortation “learn to code!” has its foundations in market value. “Learn to code” is suggested as a way up, a way out. “Learn to code” offers economic leverage, a squirt of power. “Learn to code” goes on your resume.
But let’s substitute a different phrase: “learn to cook.” People don’t only learn to cook so they can become chefs. Some do! But far more people learn to cook so they can eat better, or more affordably, or in a specific way. Or because they want to carry on a tradition. Sometimes they learn just because they’re bored! Or even because—get this—they love spending time with the person who’s teaching them.
A very smart essay from Robin Sloan about an app he made for his family, but also about how truly personal software and its creation is powerful.
He reminds us that not all code has to scale or produce market value. Sometimes code can be a way to express yourself, have fun, and make life a little better for the people closest to you. Sometimes coding can be like cooking a meal for someone you love.
Alcoholism, religious leanings, gender-nonconforming identities, BDSM relationships: All of these factors can mean that snap decisions made by servers can make for very unhappy customers, one reason why many restaurants, including high-end fine dining establishments, are doing away with gendered service in favor of neutral systems like serving clockwise.
One of my favorite writers, Madeleine Holden recently interviewed me and some other folks about weirdly-gendered restaurant service. I couldn’t agree more with her conclusion.
A great video from Vanity Fair with Nicholas Britell who wrote the music for HBO’s Succession. This type of piece where you can watch a creator actually break down the why behind their art is one of the most inspiring types of media for me. Seeing brilliant people work to elucidate their creations never gets old.
Last night, I listened to this episode of the podcast The Allusionist from October. As a keen observer of language, the host Helen Zaltzam is often bothered by the cliches of foodservice phrases like “Enjoy!” or “Are you still working on that?”. What follows is a fascinating discussion with restaurant professionals about the origin, meanings, and functional purposes of these and other similar expressions. I’d highly recommend giving it a listen.
It is the most dramatic new look for our magazine in its 162-year history, and one that, we hope, reflects boldness, elegance, and urgency. The redesign of the print magazine, as well as the new look of our website, was led by Peter Mendelsund, our creative director. His design work, carried out in collaboration with many teams across our magazine, is also reflected in the new Atlantic app that launched today.
Really excited about this bold new look for one of my favorite publications, and honored to have gotten to work on the development of the app at Lickability.
While this is a very real way people might use the pinching gesture 🤏 in both the physical world and in the emoji world, this societal obsession with penis size can be harmful. Masculinity is not defined by penis size, or even having a penis at all in the case of many trans men or nonbinary individuals.
The next day, he said, “We are looking at a way to link. Noting Motherboard explicitly—and I understand why [sic] would want this—is more complicated, however. Are we then obliged to note that The Guardian had some of the documents, too? If half a dozen other publications got a piece of the Facebook material, as well—for ‘internal’ documents, they do seem to get around—would we need note them, too? Where does it end?” The Times never added a link.
Thinking about a journalist in the NYT newsroom in 2019 not being able to figure out how to make a hyperlink cracks me up and I’m not the only one.
Whether you need some context on yesterday’s Supreme Court cases, some hope for the future, or a reminder that trans people are people: go listen to the latest episode of one of my new favorite podcasts, Gender Reveal, hosted by Molly Woodstock.
It’s Julie’s last day at work. She’s already turned in her laptop to IT, sent her goodbye email to the team, and is wrapping up her last knowledge transfer meeting. Tonight, there’s a goodbye drinks with the whole engineering department at that bar everyone loves across the street from the office. You’ve followed all the processes as a manager to offboard this person correctly, and wished them good luck at their shiny new job with more stock options and a higher salary you just couldn’t match. “Good for her,” you think, as the night winds down over a final round of cocktails. But wait – you’re not done yet.
When you’re a manager, the way you treat the people that were on your team matters almost as much as how you treat the people that are. Your ex-employees are the people out there talking the most about your company and your team. They’re the people that get DMed when a new recruit is trying to find out what it was really like to work for your company and for you. And handled really well, ex-employees are often great folks for you to tap in a few years for the new team or company you’re working on, when they’re ready for a new challenge.
How should you treat the people you used to work with, so you won’t leave a bad taste in their mouth? Here are a few do’s and don’ts I’ve picked up from my own ex-managers over the last decade or so. Disclaimer: this advice won’t apply to every situation, including if an employee left or was pushed out on bad terms.
What to Do
Let them leave with dignity.A CTO I really respect taught me that letting people take the time they need to say their goodbyes and tie up loose ends, without rushing them out the door, pays dividends. He gave me the great advice to spend my last day on the job having coffee with everyone that had an impact on me, thanking them, and exchanging contact info.
Remember that it can be emotional to process endings, even if it was their choice, and last days can be full of paperwork and tears. It’s okay if they need to come back the next week and pick up a few more things, or need building access for a final meeting after their technical last day. Don’t be a jerk or make mean-spirited jokes about how much they must want to stay. Not cool. You want their last memory of this place to be a positive one: handshakes, hugs, and well-wishes.
Keep in touch (if they want to). Some of your reports or teammates probably view you as one of their mentors, and it can be hard to abruptly lose that guidance when they switch jobs. In your last 1:1, ask the person departing if they want to stay in touch after they get settled in their new role. If they do, set up a recurring reminder to check in with them every few months or a few times a year on their career over coffee or lunch. If they blow you off or don’t seem interested, take the hint.
Let them hang around. It’s natural for folks to miss some of their coworkers, the office, and aspects of the culture when they quit. So if you see them coming by for lunch or after work to hang out with some pals, say hello and be cordial. Obviously, also be aware of the security / guest policies of your company and make sure those are being followed. The benefits of knowledge-sharing (of things they’ve learned in their new role) with your team far outweighs the risk that they’re going to “steal all your people” or whatever other irrational fear your lizard brain has cooked up. Chill out; it’s nice to see their face again.
Take their feedback seriously. They likely understand and care about your product a lot. So it might not be long before you see a tweet or email from an ex-employee about the thing they used to work on. They might be reporting a bug or airing a grievance. While it might not be the most polite way for them to give this feedback, it’s still useful. This person is essentially doing free QA on a system they’re very knowledgeable about. If you see something like this, shoot them a message asking for more details and thanking them for the report. Stay classy and fix the issue if you can! You’ll make them feel heard and respected while helping them and lots of other users too. Win-win.
What Not to Do
Don’t blame them. A few weeks after an engineer leaves a team, there will be a bug that someone will blame on them—their code, their oversight, their fault. Resist this temptation. Your team has code review, unit tests, and architecture meetings to prevent this type of singling out of developers. Remind them that every issue is a shared responsibility, and focus on fixing the problem instead of dredging up historical evidence of whose fault it was. Don’t let folks blindly rewrite systems just because “only Jim understood how this worked.” Work to build a shared knowledge base and set of documentation so that no one person is completely indispensable.
Don’t make them work for free. There’s often a temptation to message ex-employees with “quick questions” about esoteric code or systems that they worked on after they leave the company. Please don’t do this. If you absolutely need these answers, hire this person at their consulting rate and pay them for their time and labor. This kind of arrangement is super common, and your company should hopefully already have a boilerplate agreement for this scenario. If not, now’s the time to draft one.
Don’t erase them from history. This isn’t Eternal Sunshine of the Spotless GitHub. It’s unprofessional and petty to remove folks as contributors to your open source projects (especially if they want to contribute in their spare time) or scrub their bylines from your engineering blog. I’ve even heard of bosses ignoring their former employees at conferences and industry events or blocking them on social media. This is a really bad look. Don’t be a jerk to people who worked for you.
Don’t ask them on a date. I wish this went without saying, but it doesn’t, because I’ve heard of this happening. If you had a crush on your employee and the only reason you weren’t asking them on a date is because of the HR policies in place to prevent that, now is not the time to flirt with them. The power imbalance that existed between you doesn’t magically disappear because they work somewhere else. This is a really bad idea, and you should do some soul-searching and work on your boundaries if this is your first impulse.
Many managers think a lot about how they treat their team, but very few I’ve spoken to have a philosophy about those who leave it. Treat your ex-employees like they’re professionals that helped you build and ship great things, because that’s exactly who they are. If you’re consistently nice and professional to the folks you’ve worked with in the past, it’ll help build your reputation as the kind of person that’s great to work for.
If I could show just one talk to every software engineer, it wouldn’t be a treatise on the elegance of algorithms, a lecture about accessibility in apps, or even the masterwork that is Englebart’s Mother of All Demos. Instead, I’d show them this frequently-referenced 1991 speech that John Cleese gave (transcript) to Video Arts, a company he co-founded. In it, he presents a blueprint for how to nurture creativity at work that’s based on his own experience in Monty Python and the work of experts like Donald MacKinnon, Johan Huizinga, and Edward de Bono. The talk’s thesis is that “creativity is not a talent; it is a way of operating”. His method for creativity involves regularly setting aside time and space to be in the open mode, when most of our lives and occupations push us into the closed mode.
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?”
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.”
It’s scary how much email I get at work. Despite Slack’s best efforts, much of the business world still “runs on email.” In 2019, the inboxes in my life are brimming with messages from new leads, existing clients, potential vendors, folks trying to network or ask for advice, and lots of transactional bullshit: newsletters, password resets, and spam. I’m sure your inboxes feel just as overwhelming. So it’s no surprise that folks (me included) sometimes get behind on responding to their email.
But today, I’m writing about a particularly pernicious form of email non-response and how to stop it: professional ghosting. The mid-2000s millennialism “ghosting” refers to abruptly and intentionally cutting off contact with someone you’re dating without warning or justification. You stop responding to their flirty texts and date asks and don’t tell them why. In fact, you don’t tell them anything. You’re a ghost. The word gained popularity in 2015 along with the rise of Tinder and a bevy of other dating apps where “leaving people on read” has become commonplace. Professional ghosting is basically the same thing…except it’s at work, so there might be money involved.
Imagine this: you’re in an email back-and-forth with a client who has hired you to design a new website for them. After they’ve paid a deposit and you’ve started the project, you have a question about how big the logo should be. You dash off a quick email to the client to ask them. And you wait. Maybe you figure it will take them a business day or so to respond. But then you hear nothing for days. Days turn into weeks. Radio silence. You’ve been (un)professionally ghosted.
Why does this happen? It’s not always just that folks are busy. It’s often a more specific kind of anxiety and friction that causes this particular supernatural phenomenon. Maybe something in your email raised follow up questions, maybe more stakeholders behind the scenes need to be consulted, or maybe it felt like things were getting more expensive or more complicated, even if you didn’t directly say so. Professional ghosting happens when the ghoster can’t immediately respond because they’re missing something and scared to admit it for fear of looking unprepared or under-resourced. And then it’s too late, new emails are already pouring in and yours has lost priority.
While this trend of ghosting in work contexts isn’t new, it does seem like it’s on the rise. Both anecdotally in my work and industry-wide, more employees and companies are noticing ghosting behavior from their colleagues, bosses, and reports. How can we fix it? Let’s fire up our proton packs and figure it out. I ain’t afraid of no ghosts.
Advice for the Ghosted ☠️
Here are a few things I’ve done while being ghosted at work that have helped me bring back some dead threads.
Follow up. I know it might feel like you’re nagging someone to email twice in a row. But if you’re in a professional relationship, and you’ve been interacting with someone who’s vanished, they’d likely appreciate a friendly follow-up after a few days. I’ve resurrected more deals than I can count with one well-timed follow up. Use a CRM system or an app like Boomerang for Gmail to automate this.
Make responding easy. Bold the questions in your email and keep them as easy to respond to as possible. Discuss complex or sensitive matters by phone or video chat. Your goal should be that your email is the first one your recipient opens, because it’s got a great subject line and they know exactly what you want and how to give it to you. Use self-service calendaring tools like Calendly to avoid being ghosted in the midst of a long scheduling volley.
Track opens. This is controversial from a privacy perspective. But on crucial business communications like bills or contracts, I think it’s appropriate to have view tracking in place. If you know your client is seeing and opening your invoices, it can give you peace of mind that they’ll pay them on time. And if they don’t, you can let them know they don’t have a good excuse to be late, because you see that the invoice was opened the day after they received it. 👀
Advice for Ghosts 👻
If you ghost on the job, these tips might help you get a little better control of your inbox…and your humanity.
It’s never too late. Looking at your flagged emails you realize that your skin is turning a pearly, translucent shade of white. You see a list of nice people you’ve ghosted with accompanying timestamps, some of which are months ago at this point. Take a deep breath. It’s not too late to respond to these messages. You’ve got this. Wish them a happy new year and throw in a “sorry for the delayed response” like the professional, living, breathing adult human that you definitely still are.
Ignorance is bliss. It’s okay to say “I don’t know.” In fact, it’s liberating. If one of the reasons you’re ghosting a colleague or business partner right now is that you’re just not sure about something in their email, start there. “I’m not sure how to answer this. Do you mind if we schedule a 15-minute call on Monday and figure it out together? Here’s my availability.” Sometimes that admission of uncertainty all it takes to bring that thread back from the ether.
Set realistic expectations. If you know you’re prone to ghosting, don’t use an email client that lets you snooze emails; it makes it too easy to delay indefinitely. If your Fridays are always filled with meetings, don’t tell someone you’ll get them something by “end of week.” Your time and attention are valuable just like your correspondent’s, and as long as you let people know when you can realistically respond and (mostly) stick to it, it’ll be fine.
I wrote this blog post for myself as much as for anyone else. If you’re ever waiting for a message from me, feel free to link to this piece in your polite follow up. I swear I won’t mind. None of us are perfect at this stuff. We’re all human, even if we sometimes ghost our coworkers. ✌️
This weekend, I spoke to the audience of the Difficult to Name reading series at Study Hall in Brooklyn. My talk was about the internet, my fears about building and sustaining culture there, and what we might be able to do about it. Watch the talk or read my prepared remarks below. And let me know what you think on
Twitter. I’m @mb there. Thanks to Michael Liberatore for shooting the video and to everyone who helped edit early drafts of the talk.
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 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.
You’ve been there. You’re sitting in a meeting and your boss, a product manager, or an executive is talking about Q2 goals. They’re laying out a roadmap of the features that are going to be “coming down the pike”. All of a sudden you see it. An innocuous bullet that makes your blood boil: “Auto-invite friends”, “Re-engagement notifications”, or “Disable ATS”.
The particular feature isn’t important. What matters is that you’re the engineer that’s noticed this capital-B Bad Idea. You know why it’s a problem. This time it’s not just the technical debt or the time it’d take to implement. This idea is bad because it trades a worse product for a better “business”: revenue, eyeballs, impressions, you know the drill.
You have a choice in this moment. You can stay quiet and hope it goes away or point it out, question it, and even argue against it. But so often, engineers fold. They ignore their conscience and their gut in the interest of a steady paycheck and an easier work day. Avoid conflict at all costs, especially when that cost could be their job. “Just keep your head down and do what you’re told”, they think, while they twiddle their thumbs as bad product decisions whoosh by. Sure, they complain about it over drinks with coworkers and in one-on-ones, but they don’t say anything when it counts.
We’re better than this. As software engineers and designers, we’re in the room when decisions are shaped, and the only ones who have the power to actually execute them. It’s our responsibility not to forsake the people who trust the apps we make with our silence. To stand up and refuse to implement unethical systems and dark patterns. And even more, to educate stakeholders on the real human costs of their business decisions: the time, attention, money, and trust of their customers.
It’s harder, yes, and riskier. But they can’t build it without us. We get a say. Even if it’s not in that meeting, we can think about the goals they’re trying to accomplish and propose alternatives. We don’t have to hide in our sit-stand nap pods and eye-roll while we engineer a worse world. We can do more than write code. We can research and present better alternatives. We can write memos and make a slide decks to convince them of of our position. We can be activist engineers.
Even though these bad ideas may buttress the metric-of-the-week, they’re at the direct expense of consumer trust and customer satisfaction. They’re a tax on our company’s reputation. We have to push the people making the decisions to measure more than just the number they’re trying to increase. Look at reviews, net promoter score, social media mentions, and team morale. All of these trends matter to the long-term health of the company, and should be treated as such.
This requires long-term thinking and the kind of organization that’s receptive to it. In many companies, quantifiable short term gains are valued more than long-term, qualitative investment. The best companies resist this temptation to make a quick buck and build upon a lasting mission and principles. But even in companies with lofty vision statements, things can go awry. A bad quarter can send the company’s hard-won principles out the window to make room for the growth hackers.
In other disciplines, engineers wear an iron ring to remind them of their commitment to their profession. Though we may not be part of the Order of the Engineer, we can learn a lot from their obligation:
As an engineer, I shall participate in none but honest enterprises. When needed, my skill and knowledge shall be given without reservation for the public good. In the performance of duty, and in fidelity to my profession, I shall give the utmost.
Of course, not every idea you dislike is a bad one, so spend your reputation thoughtfully but forcefully. Make your dissent count, but don’t be a jerk.
Our job as software engineers is to build things that make the world (or a corner of it) better, things that solve problems. But that’s not our only job. It’s also to be gatekeepers: to prevent ideas that we know are harmful from being realized. What’s the worst that could happen: we get a reputation for giving a damn?
A year ago, I sat in a glass-walled conference room at The New York Times in a routine meeting. I listened as a business-schooled product manager spoke about yet another monetization strategy when he broke character and whispered, “now is the time to lower the gates”. He was referring to The Times’s crackdown on website users who read articles for free by googling headlines, installing NYT Clean, and clearing their cookies. Now, that defensive mindset is creeping into The Times’s mobile products.
Late last month, The New York Times quietly slashed the number of free articles in its mobile applications from 3 per day to 10 per month. It’s not hard math, each reader can access 80 fewer articles this month than they could have last month, a decrease of 89%.
While great free apps like Circa, Yahoo News Digest.1, and now Paper from Facebook, fight to take over mobile news, The Times scrambles to persuade mobile users to pay top dollar for its coverage by limiting what they get for free.
Since The Times’s mobile products are partially supported by advertising, it’s counterintuitive to drive down the number of ad impressions by cutting off enthusiastic users just as they’re getting excited about the content. Ten articles per month just aren’t enough to justify keeping the apps installed; it’s almost insulting. The proof is in the plummeting App Store ratings as well as in the company’s usage statistics, which I suspect show readers returning less frequently since the change.
From the outside, it looks as if the company is desperate to drive up subscription numbers on its confusing digital subscription packages, which are still more expensive than having the newspaper dropped on your doorstep every weekend. But I think there may be something deeper going on.
The Times plans to roll out even more digital packages this year, and people I’ve spoken to at the company are starting to worry that few will want them. Why not make its current offerings less appealing in the short term, so that they can save the day with their newer, better apps in a few months? If this is what NYT is doing, it’s downright irresponsible and counter to The Times’s commitment to integrity. There’s no integrity in misleading readers.
I asked Times spokesperson Linda Zebian about the changes and she defended the move, writing, “We continue to believe that our strategy of balancing free and accessible content with revenue from paid usages is the right one.” When asked whether the company was attempting to make the mobile applications behave identically to the website she added, “The intention is to align the meter experience on mobile apps with the website and our mobile website…”. I got no real answers to the questions of whether this change is expected to decrease advertising revenue or intended to bolster the planned new digital products.
When I raised this issue on Twitter, Jordan Kay asked me what I would do differently if I were in charge of The Times’s digital subscription strategy. If The Times wants to be the place that most Americans read their news, then it must adopt a freemium model that’s much freer than this in order to compete.
But I don’t think that’s what The Times is or should be. It’s a premium news source, and it would be much better to make that clear from the start. Everyone knows how good the journalism is. Charge for it up front with an optional free trial. As it stands, the meter devalues both the product and the brand, and any new products the Times plans to add later this year run the same risk — creating confusion and muddling the message.
The Times’s new mobile strategy forces casual readers to look for other options, and there are many out there. I hope The Grey Lady will realize her mistake and change course quickly, but knowing how things work inside an organization founded over a century ago, I’m not holding my breath. By dropping the pay gates on mobile users, the Times is ensuring its irrelevance in an increasingly mobile world.
Criticism may not be agreeable, but it is necessary. It fulfills the same function as pain in the human body. It calls attention to an unhealthy state of things.
— Winston Churchill
Last week, I wrote a short blog post on my Tumblr commenting on the news that my former employer had released a new web application and critiquing the product strategy, calling it “pointless”. Apparently this struck a chord because minutes after I had shared my brief thoughts about the new Today’s Paper web app, I started receiving tweets, direct messages, and emails from former colleagues, friends, and followers. From what I’ve heard, it’s also generated several internal emails and conversations. Many of the messages I received raised the same question: why would I write this post?
The answer is simple: I care a lot. Software needs to be criticized to get better. 90% of it is crap, and very few people are willing to explain why. My blog is a place where I can express my opinion, and I have a strong opinion about this “new” product. I share my thoughts with the hope that they’ll make people think and encourage discussion, which is exactly what happened.
There are several arguments that people made about why I shouldn’t have written the post. These deserve to be addressed one by one:
Yes, I did. I don’t any more and lack of a sane product strategy is one of the reasons why. A lot of the most amazing things we learn about how companies work are from people that used to work at them. Books like Hatching Twitter, articles from former Apple employees, and a lot of the best answers on Quora wouldn’t be possible without ex-employees speaking up. Learning requires opening up.
The people that worked inside an organization are the ones that can explain and critique it with the most insight. They also tend to be more emotionally invested in the company’s success. I plan to continue criticizing (and praising) the organizations I’ve worked for, and I hope others do the same.
Why You Gotta be So Mean?
Whenever someone accuses me of being mean, I stop to consider to whom I’m being mean. In this case, there are two groups of people I mentioned in the post.
The creators of the web app (designers, developers, editors, and product managers)
The (potential) users of the web app
The only thing I say about the creators of the web app is that they are “truly great” at what they do and that their time should not have been wasted on something so silly. Doesn’t sound mean to me.
Can people’s feelings get hurt when something they work on is criticized? Absolutely, but that’s no fault of the critic. We don’t worry about Guy Fieri’s feelings before giving his restaurant a scathing review in The Times, and we shouldn’t be afraid to criticize software for this reason either.
Was I mean to the users? Well, I did say that many of them will likely die soon, but only as a way to cheekily explain the demographics demanding this product. Not mean, exactly, but a little heavy handed and likely unnecessary.
I’ve been criticized for lacking empathy towards members of this generation of people that are uncomfortable with The Times’s current offerings and prefer the simplicity of print. To the contrary, I think that generation is right. Many of the Times’s current products, especially the website, are confusing, outdated, and just plain hard to use. However, the solution is not to make yet another product. It’s to make the existing products great for everyone, just like Google and the iPhone are great for everyone. Good design is universal. No dumbing down necessary.
What’s Wrong With Skeuomorphism?
Nothing, except that’s not what this product is. It’s not just using skeuomorphic techniques to improve NYTimes.com, it’s literally another way to view the exact same content on the exact same platform. By my count there are at least 13 ways to read the Times: Paper, iOS, Android, Kindle Fire, Kindle, BlackBerry, Windows Phone, Web, Mobile Web, Replica, Times Skimmer, Time Wire, and now Today’s Paper. We don’t need more ways to read the same content that better imitate the past. We need the existing applications and websites to be much much better and focused on the future of news consumption.
The Team Had Fun
It’s fine for a couple of people to make a terrible product for fun or to learn, especially because it’s difficult to know if something will be good before it exists. But for a company that’s as large and well respected as the Times, it’s embarrassing to use the team’s enjoyment as a reason to release a product to the public. Plenty of products have been killed before release at The New York Times and this should have been one of them.
People Asked for It
Of course they did, but just because people ask for something doesn’t mean we should build it. Often, the way users phrase questions and requests is very direct: “You should do this”, but they really want us to do the thinking for them. No one asked for an iPhone before the iPhone was released, and yet hundreds of millions of people of all skill levels use and love these devices every single day.
It’s our skill and responsibility as creators and experts to understand and synthesize user feedback into great products, and not slavishly do what our users say, producing one more pointless product after another.
It’ll Make Readers Happy
Today’s Paper may very well make readers happy just like plenty of people are still happy with their dumbphones. That doesn’t make those phones good products. If the Times believes that Today’s Paper is really the right way to look at Times content, it should be the way the website and the native applications work, not a side effort that’s only available to subscribers and doesn’t even work on smartphones. This is simply a product that placates a vocal minority. These are the people that would still be asking for a faster horse years after the Model T was released. They will only drag the company and its products down.
John Gruber at Daring Fireball called Today’s Paper “utterly uncluttered”. He’s right but misses the larger economic point. This isn’t a sustainable way for the Times to publish content, even for only subscribers. It has no ads which means that if the website operated this way, the entire thing would be a money-losing operation. Gruber is presumably comparing it to the clutter of the NYTimes.com website, but guess what most of that clutter is: ads.
It’s Just an Experiment
This product is not an experiment. Experimentation is something you can do internally, via user testing, in private betas, or on whiteboards. Experiments don’t have revenue goals, and usually don’t require full-time engineers working for months. Experiments don’t have splashy launches and email campaigns to hundreds of thousands of users. Would I have criticized this publicly if it was just an experiment? Absolutely not.
“That sucks” is negativity. “That sucks, here’s why, and here’s how to fix it” is criticism, and it comes from a place of love. That’s the difference.
— Alex Payne
In media like film, theater, television, and music, quality criticism is something that’s expected and encouraged. People looks to critics to tell them what’s good, what’s terrible, and why. In software, this same culture has failed to develop. Sure, there are review websites, but the main question they ask of software is: “does it work?” and not “should it exist?”.
We live in an environment where companies and individuals are constantly releasing new products, and the signal to noise ratio is incredibly low. We need to collectively grow a pair and become comfortable criticizing each other’s work. We need fewer products that are higher quality.
In order to produce better products, we must be willing to critique openly and honestly. We must accept that we will all fail. It’s not personal.