Eight Months of Remote Work

Last time I did one of these, it was four months ago, and I mentioned this:

All conversations must be in a digital medium. Working with people who are in an office together means either all conversations have to go through Slack, or missing out on critical information.

Sounds easy, right?

It isn’t.

Missing information isn’t the only issue I’ve run into; and I was all prepared to write a blog post about it, until I found this blog post, on what affects remote workers the most.  In order from most to least:

Screen Shot 2015-11-17 at 9.56.17 AM.png

That blog post hit me right in the gut.  It’s exactly how I feel, with roughly the same mixture as the survey.

To help combat these issues for remote workers (right now, just me) we’ve had a “George Cam” (todo: change name when we hire more remote people) that we keep up in the office and I am able to interact with everyone over that.

It works. Ship it.

Except after a few months of this, we (ok, me, since I was the only one remote) noticed a few issues:

  1. Ambient noise is the enemy. In Open Office Floor Plans (like the current environment we’re in (not by choice)), the ambient noise combined with the built in microphone on the MacBook Pro means that unless my office-mates are facing the laptop, I have a hard time picking up what they’re saying. This causes me to miss some or all parts of a (probably important) conversation and have to ask those on the other end to repeat what they said.  If it’s annoying for me, I can only imagine how it feels for them.
  2. I need to see people. Non-verbal language accounts for 93% of all interactions. Since my camera points in the general direction of everyone (but most people’s faces and bodies are out of frame), I get a good shot of people’s hands… Which doesn’t help when I need to see their body language to discern what’s going on.
  3. Just like in real life, not all conversations should involve me. Sometimes, I awkwardly invite myself into things that aren’t actually for me.  It happened just yesterday; I heard two coworkers talking about an event one evening this week, and somehow assumed it had something to do with work; I wanted to make sure I was free that night / was there for it.  Since it wasn’t actually work related (and I wasn’t actually invited), that made that exchange a little awkward.  Again, this is something that wouldn’t happen if I were there, as body language would tell me I wasn’t invited (as would the fact that they’d probably wait until I walked away, which is hard to bet on when the person is remote).
  4. Being two-dimensional (I’m on a computer screen) means that it’s easy to forget I’m there (or not there), and sometimes I’ll miss important conversations because they happened spontaneously and I just happened to stand up and walk away right before or at that time.  If I were in the office, that wouldn’t happen, since it’s much harder to forget about a three-dimensional human being.

Since we have feedback sessions often, I’m able to bring up these issues, and here’s what we’ve done to address them:

  1. Get a good microphone, and place it in the middle of the group.  The difference is amazing. Now I can hear everyone talk to each other and talk during standup, instead of straining to listen because the Mic wasn’t in the middle of the action.
  2. Have personal hangouts when we need to have discussions; perhaps in a conference room.  The office cam is great for general chit-chat and one-off conversations, but not so good when I need to see the person who is talking to me.  The personal hangout allows me to read body language, and that’s really important.
  3. Write private messages to ask one person if the conversation that’s going on is personal or work related.  That’s a more subtle approach than blurting out, “There’s a party? When is it?”
  4. Have all important conversations go through Slack.  Of course, that doesn’t happen (would you expect 80% of your company that sat next to each other to slow down their conversation so they could type it?), but that’d be the only way to be sure I didn’t miss really important communications.   It’s not just about me. It’s about what works best for the entire team. Since the fix is harder than the work around, I do ask that they at least put a note about the conversation in chat and I can follow up when I’m back.

As I write this I’m heading to NYC to spend the next few days for some face time with the rest of Jewelbots.  So for the next few days, at least, I won’t be a remote worker.

Advertisements

Why?

Recently I had the occasion to start learning and writing firmware.  If you’re like me, you’ve spent most of your software career writing web applications in a high level language, and have never needed to worry about memory management, or space constraints, or even what data structure to use.

Ok, so I’m being a little facetious with that last one, but for most web applications, Big O notation simply doesn’t matter: Most data structures and algorithms are Good Enough.  In fact, you could throw a dart at any major data structure and it will perform adequately for most workloads1.

Big O CheatSheet

So this means Computer science classes are a waste of time, and we should all just start writing Web apps, right?

Well… no. Throughout the course of learning how to program hardware, I’ve encountered from very stark realities: Hardware is the honey badger of platforms. Whereas other platforms may be forgiving, or may let you get away with something that isn’t a “Best Practice”2, hardware simply does not care about your feelings and desires to launch software. You have 16KB of Ram, and 256Kb of ROM, and that’s it (and in SoC terms, that’s a lot). All those optimizations that we used to make fun of? Well now we’re doing them.

I wasn’t totally unprepared for this turn of events; I had been going through the Programming Pearls book for years3, and so my mind was open to the challenges of writing low level code.

But, nothing I’ve ever done professionally has really prepared me for this. I’ve worked on a few “Web Scale” projects, but mostly been able to optimize code without having to really do low level stuff. Since there’s a tradeoff to business for optimization, it’s always been a ‘good enough’ approach.

And that’s my fault.

The entire world around me is filled with answers, but I’ve never asked the right questions at the right time. Imagine how good at programming I would be if instead of taking apart the computer and put it together, I simply kept asking people “how can I program this?” Or imagine if instead of partying and wasting my college years playing Tribes, I had asked my professors what I would need to learn to build a compiler?

My father (a reporter and journalist) used to say, “It isn’t the man with the answers, it’s the man with the questions.”4

What if I had taken his advice sooner? Where would I be now?

I’m privileged to be able to work across the entire software stack, and working at a hardware startup has been extraordinary; but I can’t help but wonder what I’d be doing now if I had asked questions sooner in life. Would I have gone to MIT? Would I have fulfilled my potential sooner? Would I have understood what I wanted to do with my life sooner?

I’ll never know, of course, but, as they say: The second best time to plant a tree is right now.

If there’s one piece of advice I have for my 7 year old self, it’s: Ask ‘why’, and don’t stop until you’ve found the answer. And then find another question to ask.


1: “Most” meaning most, of course. If you work with Web Applications (or even most applications), your user base or data set just isn’t large enough to worry about this sort of stuff; you’ll generally find greater gains fixing things elsewhere. That isn’t to say it doesn’t matter at all, just that for most of us, it doesn’t matter most of the time. It’s like the Pareto principle, only less succinct.

2: Used un-ironically, for once.

3: Really, I keep picking it up, doing an exercise, and putting it down. It’s like Godel Escher Bach for me.