Two weeks ago today, I relaunched my personal site. From here on out, that’s where I’ll be writing.

I’ve already moved all the posts from Make Before Break to that site; in a couple of weeks, I’ll be redirecting this site there as well. If you’re reading this in your favourite feed reader, you’ll want to update that as well!

I’m sorry for the inconvenience; maintaining all these sites has been more administrative work than I’d like, and hopefully with less overhead, I can get back to doing more writing, and more making.

Messy Journeys and Scruffy Role Models

Tell me if any of this sounds familiar:

  • Why am I having such a hard time with this? What’s wrong with me?
  • Maybe I’m not smart enough to do this.
  • People hired me to do this work, but I’m never going to figure this out. I’m a fraud.

There are at least a couple of common threads with these statements, but I think the most interesting one is that each of these statements is an implicit comparison that I’m making between myself and someone that’s, y’know, good at what they do.

And when you’re trying something new, it can be really hard to remember that you’re trying something new. We approach new things with expectations, adn we typically want to feel smart, we want to believe that we’re good at stuff. Eventually, though, Reality pops in for a visit to remind us that we haven’t done this before.

“Sorry to rain on your parade there, but this… this isn’t going to be a cakewalk for you. Here, have a brick wall!”

And when you run face-first into a brick wall you feel, well, not very smart. Someone else would have noticed that wall. I don’t know what I’m doing.

Desirae Odjick wrote a great article at Half Banked on learning about money that I think touches a bit on this:

“What makes you feel confident with money?”

There’s a lot I could say about it, including that building knowledge over time has been helpful, as has seeking out both expert opinions and people “in real life” who are willing to be open with me about it.

But I did that over ten years, at different paces based on where I was in my life. “Start ten years ago,” isn’t exactly the most actionable advice out there, ya know?

When I’m tackling something new, it often feels like I have so much catching up to do. And, sure, if the best time to start was ten years ago, the second best time to start is right now.

But here’s the thing with comparing yourself to a ten-year veteran in the field, or comparing your first app to stuff that’s won Apple Design Awards or whatever.

They’re not real.

Not really, anyways — at least not outside of the reality you create for them in your head.

Building up the confidence to just get started on something new is hard, and it’s especially hard when you’re comparing yourself to other folks that have years of experience doing what you’re struggling to learn.

And so in your augmented reality that you create for these experts and the fruits of their labour, you can’t see the ten years of hard work. The string of failures. The moments of self-doubt and being on the precipice of giving up.

That’s why, when it comes to learning, it’s nice to see a map of the whole confused, messy journey:

The slick, polished look of the app and its refactored, tidied-up codebase doesn’t tell the real story about how it was created. It skips the hours spent digging into that elusive bug, the time stuck while crafting a particularly tricky piece of logic, and the endless UI tweaks to get it looking just right.

You company’s engineering journal on all the cool things that went into your 1.0? That’s awesome. Your slick and polished app? Amazing. Your talk on best practices for using, I dunno, whatever JavaScript framework is cool these days? Inspirational.

But when I sit down to try my hand at creating something, it’s comforting to have seen that great things aren’t just born that way. Seeing the gaffes and the dead-end experiments that didn’t make it into the final artifact is reassuring: when they happen to you, they feel less like failures, less like monumental wastes of time, and more like a part of the learning process.

And therein lies the rub, the disconnect: we talk up the value of learning from others’ mistakes, and then put in all kinds of effort to scrub clean that which we put out into the world.

Maybe that’s doing us all a disservice. Maybe that’s to be expected in an age where we focus on social media over social learning, but maybe we can do better —and get better— by being a little bit less perfect.

App Store Reviews in Manuscript

I’ve got some iOS apps as side projects (they’re in dire need of updates, but that’s neither here nor there). To keep things organized, I use a Manuscript (née FogBugz) account that I opened six years ago for planning work and, more relevant to this post, to capture (almost) all customer feedback. There’s a custom mailbox set up with an email address in my business domain, to which customers can send questions and comments about the apps. These emails generate cases that I use for correspondence, and I can then open feature requests, bug reports, and known issues as linked cases in the relevant project.

I say “almost” all customer feedback, though, because not everything gets captured in Manuscript.

What’s missing? You don’t get notification emails from Apple for new App Store reviews, so I can’t pipe these into Manuscript. Wouldn’t that be nice? Instead, you have to check for new reviews manually, across App Stores in all countries where your app is sold, or rely on yet another service. I don’t know about you, but I’ve got enough inboxes to deal with.

Enter Manuscript integrations, powered by Glitch. At their core, integrations let you create microservices in Glitch that communicate between Manuscript and some external service.

And thus came the idea for this project: since every app on the App Store (and Mac App Store) has an RSS feed of its reviews, I could create an integration that checks your app’s feed and, if there’s something new, pull it into a new case in Manuscript.

I’ll be working on this in Glitch, and tracking it in GitHub. As of the time of this writing, the Glitch project is just a remix of the sample Manuscript integration, but the work has been planned out; I’ve set a release date of March 25th for v1.0 of the integration, giving me two weeks to build and test the thing. While I’m not especially concerned about the ship date slipping, not having any ship date at all usually means that a project doesn’t get any priority on my calendar.

Last week was all about defining the project itself and the work to be undertaken, and this week is about getting started on the actual code. If you’re interested, you can read over the draft functional spec and technical spec. It’s open sourced under the MIT license. I’ll be working on this in the open, which I have feelings about (read: anxiety and trepidation), and I’ve also set up a development journal in Day One, where I add short weekly retrospectives on wins and losses for the week.

More to come as I make progress against the milestone!

Remote Work: Year One

A couple of weeks ago, Julia Evans wrote a retrospective on what it’s been like working remotely that resonated with me, given that today is my one-year anniversary since taking a remote position. Since this is my first fully-remote job, taking some time to reflect on how things have gone seems like a good idea.

Julia answered some great questions about working remotely, so I’ll do the same here.

What’s scary about working remote?

Honestly, not very much, though that certainly depends on who you’re working for and your own comfort levels with all kinds of things. I’d worked from home a fair bit prior to going fully remote, so I knew I wouldn’t have issues with productivity. I thought there might be difficulty in bonding with colleagues, or missing out on the hallway and/or watercooler talk, but that hasn’t been a thing (more on that later).

If there’s a downside, it’s that it’s really easy (for me, anyway) to slip into a place where I don’t leave the house and don’t get in any social interaction or physical activity. I have to force myself to be deliberate about those things now.

What’s good about working remote?

The number one benefit of working remotely is having the ability to focus. Oh, wow, is it ever awesome to be able to set yourself up with the perfect work environment, and know that you (for the most part) don’t have to worry about being an hour deep into researching or working on something only to get tapped on the shoulder or interrupted by noisy coworkers. We’ve reconfigured our second bedroom to be my private office.

The commute isn’t bad, either. During my engineering degree, I had to turn down an internship at the Canadian Space Agency because I just couldn’t afford to buy a car to commute back and forth (or move closer to their location, either). That sucked, and it made me realize just how messed up it is that working can cost you money.

Let’s talk about career development.

This is a bit hard to address, as I’ve spent most of my first year just trying to learn the ropes and become a productive member of the team. I haven’t taken advantage of things like our conference and education budget, so I’m aiming to be better at this in year two.

How do you learn from your colleagues remotely?

I mean, picking someone’s brain is never more than a Slack conversation away, but we recently trialed a new mentorship program. I got to learn a lot about working on web applications/in JavaScript under the tutelage of a really smart and experienced developer.

We also use Manuscript as a store of knowledge, so learning from colleagues is never more than a few searches away — detailed notes in cases can serve up a whole lot of learnin’.

How do you stay plugged into spontaneous conversations around the office?

With something like two-thirds of the company remote, most conversations happen in Slack. Tuning in to the right channels (and getting your notifications right so that you’re not interrupted when you’re heads down) makes it easy enough to understand what’s going on, but it did take a while to get that right.

How do you have idle/watercooler discussions?

One of our developers created a “coffee time” app that connects you with another colleague every Saturday via email, just so that you can catch up with them over a warm beverage. We also have a Friday Zoom meetup where we wind down ahead of the weekend. We’re trialing Donut for more of a group coffee-time thing, and that’s been fun.

These meetups are always optional, so if you’ve got a heavy week, no one will make you feel bad about skipping them.

What happens if you spend a week stuck on a problem?

It’s rare that this will happen. We’ve got proceses in place for escalating issues that we’re especially stuck on that ropes in members of the development team, but before it even gets to that, we usually invoke one of our team values: support engineers help one another.

What’s the setup like for meetings with people in the office, does it work well?

My first-day experience while being onboarded Fog Creek’s headquarters in NYC was a monthly Town Hall meeting. I remember feeling that it was pretty odd that everyone in the office was sitting at their own desk, in front of their own computer, headsets on, and interacting in the meeting via group videoconferencing. On the other hand, this makes it pretty inclusive for us remote folks — there’s not much in the way of sideband conversations going on when you’re all on your own webcam. So that’s pretty cool, and in practice it works well.

How do you stay productive and also separate work/life at home?

Productivity gets easier when you’re not exhausted by commuting, and you’ve got a dedicated area that’s set up to meet your own ideals for a productive workspace. Like Julia, I’ve found it more distracting working out of an office than working from home. I do keep a pretty clear start and end to my workday, though, and generally only set foot in the home office to do work.

The Junk Drawer

I’ve slowly been moving over to Things 3 for task management, but more than that, I’ve been re-thinking just how my system needs to be fleshed out so that it works best for me.

As part of that move, I’ve been re-evaluating the way I think about capture. Typically, you’ve got an inbox, where you log all the incoming stuff in your life, and which you process periodically. That’s fine for the usual do-delegate-delete-defer type tasks, but if I want to use Things (or whatever task management system) to capture everything, I’ve found that I need a place for things that live somewhere between the inbox and a project.

Which brings me to BINQ.

BINQ is a concept I heard Merlin Mann talk about on the Back To Work podcast, and is an acronym for Brainstorming, Ideas, Notes, Questions (or something like that).

Essentially, BINQ is a junk drawer for your thoughts. It’s a holding pen for half-baked, hare-brained ideas that need to time to fully form. Tasks in the BINQ project don’t quite yet deserve to become a project, but they really need to get out of the inbox.

Some folks use the concept of “Someday” for these things, but in practice I’ve found that “someday” makes more sense as a temporal definition (kind of like a “pending” or “waiting” context, but important enough to be a first-class entity in the task manager). This is how Things treats “someday”: you set this as part of the when for a task, not the where.

My BINQ project lives outside of any so-called “Areas” in things — in fact, it’s the only project that isn’t part of some area of my life. A few times a week, I’ll check in and add some notes to a task that lives in there, or maybe delete something because it doesn’t make any sense to pursue further for whatever reason. Ideas for posts go into BINQ too, before a draft gets written.

This is a good place for checklists within tasks, too. As you start to flesh out some of these ideas, it’s handy to add checklist items to them. It then becomes pretty trivial to bring these out of BINQ quarantine and into your life using Things’ convert-to-project feature.

For now, I’ve set up four headings for each of the letters in the acronym (Brainstorming, Ideas, Notes, and Questions), but I don’t love the idea of having to decide what heading a task would fall under—it injects friction into what should be a easy process. Trying to enforce too much organization on a junk drawer just means that your real junk drawer lives somewhere else.

Too much of the pseudo-productivity silliness tries to package your life up into neat little packages, which is fine for remembering to take out the garbage, or for organizing your kitchen renovations. But sometimes, for the messy, ethereal things that come into your life, a good ol’ messy junk drawer is the right place for them to live.