mb

A photo of mb bischoff in a red lip and leather jacket.

mb bischoff (they/them) makes  apps,  posts, &  podcasts changes

rss subscribe mb

Tagged #advice

Things You’re Allowed to Do 

This is a list of things you’re allowed to do that you thought you couldn’t, or didn’t even know you could.

I haven’t tried everything on this list, mainly due to cost. But you’d be surprised how cheap most of the things on this list are (especially the free ones).

I love this list from Milan Cvitkovic reminding us of the things we’re allowed to do but that we often forget are options. Some favorites that I’ve actually done include: hire a tutor, buy goods/services from your friends, get couples therapy, hire a coach, cold contact people, and fly to people for in-person meetings.

#advice #list #money #time

Are You Gonna Finish That?

Stack of Books

I’m a completionist by nature. I love checking everything off my to-do list for the day. When I discover a blog, podcast, or webcomic I love, my curiosity pulls me toward consuming its entire backlog. I spend hours spelunking the archives, finishing every last morsel of media.

Growing up, I attended Catholic school and was taught by nuns to finish my lunch because there were children starving halfway across the world. I was taught to complete one book before starting the next. Taught to give equal attention to every station of the cross.

This type of perseverance can be a valuable tool in one’s toolbelt. There are moments in life that call for grit, when it’s crucial to push through discomfort and disinterest. But fetishizing finishing isn’t nearly as helpful as it feels. Just the act of completing something isn’t virtuous by itself—the context matters.

We are living in a time of ceaseless information overload and ever-expanding choice. Thousands of photos are posted to Instagram every second, 500 hours of video are uploaded to YouTube every minute, and millions of books are published every year. You can’t consume all that “content” even if you want to. Your time and attention are limited resources. In this context, a better skill than finishing is knowing when to finish something and when to abandon it.

I’ve gotten better at this over the years. I’ve become more attuned to what my body and brain are telling me about the future value of what I’m currently doing. These are the questions I ask myself when deciding whether to stick with something or bail:

  • Am I enjoying it?
  • Is it feeding my mind or my heart?
  • Will it help me accomplish something or solve a problem?
  • Will it matter in a year? Five? Ten?
  • Is there something I’d rather be doing?
  • Have I had enough?
  • Might it be better to set it down now and pick it up again later?
  • What’s the worst thing that would happen if I give up?

These questions help pressure-test the idea of continuing to follow my current trajectory. And sometimes their answers reveal that I should have pulled off the highway a few exits ago. But no matter how close to the end I am, it’s never too late to stop.

I want to give you permission to quit the thing you’re trying to finish that’s not working for you anymore. It could be a New Year’s resolution you regret making, a book that all your heroes recommended but you keep bouncing off, or even a side project that doesn’t bring you joy anymore but that you keep maintaining out of a sense of duty. Whatever it is, you’ll know it, because just the psychic weight of it being unfinished is stressing you out.

You don’t have to complete everything. You don’t need to be in it for the long haul. Quitting something doesn’t make you a quitter. Instead, it makes you someone who knows their worth and knows what they want. Letting go of one thing can give you space to start something new that will serve you better. And if you regret your decision, it’ll still be there when you’re ready to pick it up again.

#advice #life #media #wisdom

How to Not Know Things

In May 2010, I was offered a job at the Apple Store at the King of Prussia Mall, one of the biggest shopping destinations in the United States. It was my first and only retail job, and in my three months working there, I became the top-selling salesperson (or as Apple called it, “Specialist”) on the sales floor (or as Apple called it, “The Red Zone”). I did this by sharing my passion, knowledge, and care with every customer. But I also did it by Googling a lot, by installing lots of apps for customers to check that they’d work, and by getting a little better every day.

My training for the job involved being clapped at a lot while donning the signature blue T-shirt in a room full of folks learning how to sell iPhones and iPads and create Apple “customers for life”. Our teacher was a blond-haired, blue-eyed surfer-turned-computer salesman named JB who wore white earbuds as a necklace. As he taught from the printed material and screened Apple videos for the class, he kept harping on one point that’s stuck with me in the decades since.

I don’t know, let’s find out

JB taught us that there was no way we could know everything there is to know about every Apple product, let alone every app that runs on them, and every way they can fail. He taught us that rather than making up an answer, guessing, or shrugging our shoulders, we should instead say, “I don’t know, let’s find out”. Admitting that we didn’t know was the first step. Then, we were to find out together with the customer by walking over to a Mac and looking up the answer or pulling in another employee who might know the answer.

This one sentence from a retail training manual contains many insights that I’ve relied on every day since in my personal and professional life:

  1. It’s okay not to know because we can’t know everything, and we shouldn’t expect that of ourselves.
  2. It’s better to admit our ignorance than get things wrong.
  3. Even if we think we might know, it’s okay to double-check because getting it right matters.
  4. People trust us more when we admit our shortcomings.
  5. Learning is better together.
  6. People love to see and share in the process of discovery.
  7. People trust information more when we share the way we found it.
  8. Memorizing isn’t as important as knowing how and where to look things up.

Fuck around and find out

This is another similar phrase that’s become popular since 2020, especially sarcastically in leftist circles. But it’s legitimately valuable advice because sometimes, no amount of Googling or reading about a topic will get you to the answer. Sometimes, trial and error is the only way to learn. By experimenting or fucking around, we learn together by playing together. We do a little science and discover something new about the world that we can share.

Many of the answers to life’s daily questions can be uncovered using these thought technologies. Are you faced with a tricky question in an interview for a new job? Try being honest with the interviewer that you don’t know the answer and explain how you’d research it in detail. Not sure what your gender is? As Mattie Lubchansky suggested on a recent live episode of the Gender Reveal podcast, “fuck around and find out”. Try on makeup, a new set of pronouns, or a binder, and see how it feels!

Let’s make better mistakes tomorrow

Just because you don’t know something today doesn’t mean you won’t know it tomorrow. If you cultivate an attitude that faces the unknown with curiosity, sharing, and experimentation, rather than blame, fear, and stubbornness, you may get a bit smarter every day. You’ll learn much more by remaining open to new discoveries and sharing that journey with the people around you, at work and in the rest of your life. And that continuous improvement, or kaizen, will accumulate like compound interest. It will, in the words of Mike Monteiro, let us “make better mistakes tomorrow”.

What don’t you know right now? What do you want to find out? Let’s do it together.

#advice #apple #knowledge #learning

30 Lessons from 30 Years

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.

On Work

  1. First, care.
  2. If it takes less than two minutes, do it now.
  3. Your mind is for having ideas, not holding them so if you didn’t write it down, it didn’t happen.
  4. Ideas are just a multiplier of execution.
  5. Putting it on paper lets you start fixing it. If it stays in your head, a perfect idea, you’ll never share it with anyone.
  6. For the first couple years you make stuff, it’s just not that good.
  7. Say “yes, and…”
  8. Practice out loud.
  9. The best code is no code at all and the best interface is no interface.
  10. Make It work, make it right, make it fast.

On Relationships

  1. Do what you say you’re going to do. Conversely, don’t say things you have no intention of doing.
  2. Don’t compare someone else’s onstage to your backstage.
  3. The conversation is the relationship.
  4. Love is a skill, not just an enthusiasm.
  5. Love is not enough.
  6. Love is not a finite resource, but time and attention are.
  7. Kindness is more important than wisdom, and the recognition of this is the beginning of wisdom.
  8. Never attribute to malice that which is adequately explained by stupidity.
  9. I’d rather be 9 people’s favorite thing than a hundred people’s 9th favorite thing.
  10. The way to love someone is to lightly run your finger over that person’s soul until you find a crack, and then gently pour your love into that crack.

On Life

  1. Life is not a zero-sum game.
  2. Two is one and one is none.
  3. Everyone is just making it up as they go along.
  4. Keep moving and get out of the way.
  5. It’s easy to be on time. You just have to be early.
  6. You don’t have to talk. Instead, ask Does this need to be said? / Does this need to be said by me? / Does this need to be said by me now?
  7. The natural world makes no promise to align itself with preconceptions that humans find parsimonious or convenient.
  8. If you want to be trans, you’re trans.
  9. Time is a precious thing, never waste it.
  10. Enjoy yourself. It’s later than you think.
#advice #lessons #life #me

Reply All: The Case of the Missing Hit 

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.

#advice #gimlet #journalism #music #mystery #podcast #pop #reply all

Professional Ghostbusting

Ghostbusters

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 each other.

#advice #email #work

Reviewing Code: A Checklist

You’ve been there. A 10,000 line pull request lands in your email and you don’t even know where to begin. No description provided.

Should you start by installing it, running the test suite, or should you just start scrolling though while your eyes glaze over from the red and green stripes? Is this developer really looking for feedback or are they on a deadline and pressuring you to say “lgtm”. Will your one innocuous comment ignite a flame war?

Code review, or more generally peer review, has a long record of finding defects in not just software engineering, but in science, academia, and many other industries. While some argue about the specific percentages of issues that it finds compared to an automated test suite, or others method of testing, code review is an incredibly useful tool in any software teams arsenal against bugs and poor software architecture. But only if it remains a sharp one. Laziness can creep into code review very easily if you’re not careful.

Jason Brennan has written two great pieces on the topic of diligently writing and reviewing pull requests, and I’ve used his series as an inspiration for my own system. I’ve also found it’s handy to have a short-form checklist to go over when performing code reviews to remind myself what I’m going for. Maybe it’ll help you and your team too.

For the engineer drafting the pull request

  • Provide a screenshot, GIF, or video of the change if possible. People like pictures.
  • Explain what changed and why.
  • List step-by-step how to test the changes.
  • Link to any relevant task(s) or ticket(s) in the bug tracker.
  • Link to any existing documentation that could make the change easier to understand for the reviewer.
  • Mark any areas that are work in progress or require follow up.
    • Note anything that is waiting on other departments or team members.
  • Call out any legal, security, or privacy concerns.
  • If any third-party dependencies have been added, explain what they are and why you chose them.
  • Double check that the code is styled, documented, and tested to your team’s standards.
  • Mention people who would be interested in the changeset:
    • Engineer(s) who wrote the old version
    • Designer(s)
    • Product manager (if they’re interested)
  • Give the diff one final pass yourself before asking others to take a look. You might catch a few silly things like typos in comments.
  • Annotate particularly tricky sections in the diff to make what’s going on even clearer. Maybe even turn these into code comments.
  • Get a coffee and wait for the constructive criticism to roll in.

For the reviewer

I find it’s helpful to do these in order if you can.

Most importantly, remember that the engineer on the other side of the screen is a person. Try not to be curt or hurtful in your comments.

The Pull Request

Start here to build an understanding of what you’re about to be diving into.

  • Let your teammate know that you’re reviewing their work however’s customary: a comment, a message, making yourself the assignee.
  • Read over the pull request description and any linked documents to understand the nature of the changes.
    • Ask questions about anything you don’t understand or if there isn’t enough detail to properly review.

The Product

Does it work as you’d expect? You can write lots of pretty code that doesn’t work.

  • Checkout the pull request locally.
  • Confirm that the project builds and compiles.
  • Look for any new warnings or errors that have been introduced.
  • Run the unit / integration tests to look for any new failures.
  • Follow the steps provided to test the changes or determine a testing plan for it and run through those tests, noting any issues in your comments.
    • Test things that the original engineer might not have considered like errors, failures, other inputs.
  • Look for significant changes in performance.
    • Profile the changes if performance seems to have regressed.
  • Run the application in another language and region to check for internationalization and localization issues.
  • Confirm that the changes are fully accessible to customers with disabilities.

The Code

Alright, it’s time to start looking at the code, line by line.

  • Deleted code
    • If code was deleted, was its functionality adequately replaced or is what it provided no longer required?
  • Added code
    • Does the new code introduced conform to the teams’s standards for style, documentation, and testing?
    • Does new code make sense when read? Is anything too clever or inexplicable?
    • Is new code safe?
      • Does it have the potential to crash or hang?
      • Are there any obvious race conditions or concurrency concerns?
    • Is new code fast?
      • If not, can you suggest optimizations?
    • Is it well-designed and well-factored?
      • If not, try to propose alternative solutions or schedule a time to whiteboard with the engineer.
    • Is it well-named?
      • Are the names of types and functions obvious and unambiguous?
  • Modified code
    • Do you understand why the modifications were made?
    • Do the modifications improve the factoring, design, or performance of the software?
    • Do the modifications change any of the fundamental assumptions that the original code made?
  • Dependencies
    • Make sure to understand the implications of new dependencies on third-party code, including their licenses.
  • Assets and Resources
    • Do all assets and resources exist in all the right formats and sizes?
    • Are they finalized and ready to go into production?
  • Configuration changes
    • Do you understand the effects of these changes and how they can be rolled back?

Adding a system like this to my own pull request reviews has helped me catch a lot more, but I’m sure there are still things I’m missing. If you have ideas about how this checklist can be improved, pull requests are welcome!

#advice #code #code review #programming #work

The Idea Guy

A few years ago I was tasked with helping to recruit interns for The New York Times iOS team1. I traveled around to top-tier engineering programs at universities all over the northeast talking about the Times’s engineering culture and to students about what they wanted to be when they grew up.

One of these interviews stuck with me. I asked a junior what he saw himself doing in five years, and I’ll never forget what he said.

“I want to be the idea guy at a startup”.

I wish I could have stopped the interview right then and there. I wanted to tell this guy that there is no Santa Claus, that the Easter Bunny isn’t the one hiding the eggs, and that no such role exists or ever will.

Ideas are everywhere. They’re a multiplier. They’re not a thing you make, and they have have no intrinsic value. We certainly don’t need a whole person for them at a company that’s just starting out.

Some nights I wonder where that guy is. I’m scared to look through my notes and check up on him, but I sincerely hope that he’s found some way to bring his ideas into the world — something to do or to make.

I wish we hadn’t separated those two concepts in English. ‘Faciō’, one of my favorite Latin verbs, encapsulates both concepts in a beautiful way. Anyway, back to doing. The ideas will come.

  1. By the way, they’re still hiring. If you want to work there, or at Tumblr for that matter, email me

#advice #startups #work

You’re Up

Whenever I go to tech conferences or meetups, I almost always end up traveling with either Brian or Andrew from Lickability.

Let’s face it, I’m a nerd, and it can be a little awkward for me to walk up to a brand new group of people at a conference or a party and introduce myself. Will they like me? Am I smart enough? Are they going to eat me?

Brian and I ended up using a really simple system at WWDC 2011 that we’ve continued using to this day which makes this process fun instead of anxiety-inducing. It’s a game called “You’re Up”.

The Rules

  • Join a team of 2-3 people.
  • Pick one of you to be “up”.
  • If you’re up, you must introduce yourself to someone new and bring your teammates along.
  • Have a conversation with your new acquaintances.
  • Alternate who’s up.

Instead of milling around and staring at the furniture or talking to the people that you already know, it’s good to push yourself outside your comfort zone. This simple game has led to dozens of interactions and friendships with people that I still talk to regularly, and I’ve enjoyed going to industry events much more with this in my back pocket.

There are no points in this game for a reason. You don’t play it to win. The reward is in having engaging conversations with interesting people. This is just a little hack to make the hard part of socializing easier and more fun.

Just remember: most people want to meet you as much as you want to meet them, especially in social situations like this. No one would prefer to stand there and stare at their phone when there are tons of fascinating people around.

So go have fun and meet some people. You’re up.

#advice #conferences #game