Paying Attention (or why I love coffee so much)

Image credit:

Image credit:

I made the best cup of coffee I've made in a very long while this week.

Obsessing over my pourover coffee technique is one of my favorite pastimes. I've been through several iterations of brewing equipment and technique, finally settling on a Kalita Wave paired with a Baratza Encore grinder, and they have served me well. The combination produces exceptional coffee, and the Kalita is used by a number of amazing coffee shops alongside their terrifically expensive commercial grinders.

It was in one of these amazing coffee shops, Little Owl Coffee in Denver, that I realized I'd been missing the mark. The cup at Little Owl had flavor notes and subtleties to it that had somehow snuck away from me at home. I had produced cups like this before, but it had been a while. As I stood there watching the barista carefully tend each cup, pouring the water just so, I realized what a hurry I had gotten into making my daily cup. My coffee ritual had gone from among my favorite parts of the day to a banal set of steps I followed to get my fix.

So I came home, I took a deep breath, and I got back into my coffee ritual. I tweaked my grind. I poured slowly. I made sure I hit my time marks. And I was rewarded with an amazing cup of coffee. This was with the same equipment and beans I had been using before the trip to Denver; the massive improvement came down to technique and attention to detail.

There's not enough time in life for you to care about everything. I spend an inordinate amount time and attention on coffee because it brings me joy. I could easily go buy a nice drip coffee makerand let it do the work for me, but I enjoy the endless futzing in search of perfect extraction, and I get a lot of satisfaction from being (relatively) good at it.

Even for all the joy it brings me, it still takes mindfulness on my part to not fall back into autopilot and settle for a good enough cup. Coffee is a trite example, but it's easy to go through the motions with most anything (or anyone) you care about in life. Attention is a finite resource, and if you aren't deliberate about where you want to spend it, you'll end up giving it all to the squeaky wheels in your life and not have nearly enough for the things that recharge you and bring you joy.

My challenge to you is to spend a few minutes thinking about all the places in life where you're spending attention by default rather than by choice. Are you spending your attention in the right places, or are you robbing yourself of joy by just going through the motions?

Making Remote Work

There's been a lot of noise around the web about Reddit giving its non-Bay Area employees until the end of the year to decide to pack up and move to San Francisco or seek alternate employment:

I'm fortunate enough to work remotely at WellMatch, and we've gotten quite good at remote work in the year I've been here. The Reddit dust-up and a few subsequent conversations with friends on Twitter got me thinking about what we've done to make remote work so well for us at WellMatch. As someone who's been at least partially remote for more than a decade, here's what I think makes us different:

Everybody's Remote

WellMatch doesn't have an office. We have some shared office space available to us in NYC, but we only use it for the occasional face-to-face meeting. This means everyone in our company, from the president on down, works remotely. For our developers, tmux/vim is our office; HipChat is our water cooler; and Google Hangouts is our conference room, happy hour pub, and everything in between.

In a mixed colocated/remote environment, the people who go into the office every day have several distinct advantages over the remote diaspora.

First, the boss gets to see the office worker's butt in their seat “getting stuff done", where the case is not always so clear for the remote worker. It takes a good manager to be able to judge people by their work output and not give unfair deference to the people they see in the office every day.

An in-office developer also has the ability to get up and walk into their manager's office anytime to discuss most anything. The remote worker has to somewhat awkwardly try to arrange time for a conversation from looking at their boss's (likely very busy) calendar. They have no way to discern their manager's busyness or temperament that day before asking for time, and they don't have any way to bump into the boss at the coffee pot or water cooler for an informal conversation.

There's also the awful company-wide conference call where everybody in the office crowds around the fancy Polycom conference room phone if you're lucky (or an iPhone in speakerphone mode if you're not). You, as the remote worker, have to try and figure out who said what, assuming you can understand anything being said in the first place. If you have something to add, you have to try five or six times to interject because everyone in the office has forgotten there's anyone joining remotely at all.

I've yet to see any of these issues at WellMatch, and it's because being fully remote puts everyone on equal footing.

Human nature dictates that we trust tangible things over intangible ones, things that we see regularly over things that we don't, and so workers in the office who get regular face-time with each other will default to trusting each other more than their remote colleagues. It's nothing intentional or malicious – it's just how our brains work. The only truly effective way I've seen to combat that tendency is to do what we've done at WellMatch: put everyone on equal footing by being fully remote.

We Pair Because We Care

At WellMatch, we pair program very close to 100% of the time. It's a habit we picked up from our friends at Hashrocket, and it's a big part of what makes remote work so well for us.

One of the arguments for colocated work environments is that it makes it easier for knowledge to flow around the organization through overheard conversations and spontaneous meetings. Pairing delivers the same benefits, especially when practiced promiscuously. When you regularly switch up who you're working with, you're forced to both share and learn knowledge acquired by your pair in the weeks prior. Pairing also helps spread organizational values and culture organically, especially when someone new works with someone well-established in the shared values of the group.

Promiscuous pair programming helps avoid the information and trust silos so common in both remote and colocated organizations.

Pairing also helps keep developers from drifting away unnoticed. When everyone is in an office together, it's easier (not easy, but easier) to notice when someone is becoming frustrated, disengaged, or despondent, and to intervene before it's too late. Working alone remotely makes it even more likely for someone to drift away, but pairing is an almost perfect foil. It's hard to disengage and start trawling job boards when you're on Skype and sharing a text editor with another developer, and pairing promiscuously keeps you regularly connected to everyone else in the organization.

We Strive Towards Empathy and Egolessness

Our developers, almost to a person, say that WellMatch is one of the closest teams they've ever been part of. It seems really odd to say about a completely remote team. We don't have a lot of the normal "team building" shtick that managers usually think is responsible for building a solid team. Instead, it's happened very organically, and it has a lot to do with the kind of people we've been fortunate enough to hire.

Pair programming, it turns out, is a neat hack for hiring developers with very high emotional intelligence. Developers who seek out full-time pairing tend to be highly self-aware. They're comfortable being vulnerable and admitting they don't know something. They happily give credit to others where it's due, and they mostly avoid the common software developer pitfall of trying to make themselves look smart at the expense of everyone else on the team.

Empathy, egolessness, and vulnerability will emerge organically across your team when you seek out developers with high emotional intelligence.

These traits aren't unique to remote environments, but they have a lot to do with how successful we've been at working remotely. Empathy helps us overcome the communication constraints introduced by foregoing traditional offices. Egolessness helps us share credit and ensures everyone feels a part of success (and that no one gets scapegoated for failure). Vulnerability lets us share when we're struggling or becoming disconnected instead of suffering alone in silence.

There's plenty more that we do at WellMatch that has helped us be successful as a remote engineering organization:

  • We have regular offsites so we can share face time.
  • We have daily standups and weekly retrospectives like any good agile engineering group.
  • We've spent a non-trivial amount of time honing our tools so they work well for all of us.
  • We have a remote happy hour in a Google Hangout every Friday.
  • We do a weekly book club together so that at least some of us are always learning about the same thing.

But all of that pales in comparison to the three points above.

The biggest key to being a successful remote organization is deciding to be a successful remote organization. It requires commitment from the very top on down, but it brings the incredible benefit of being able to hire the best people possible without worrying about where they live. It's unfortunate that the myth of remote work ineffectiveness still lives strong among the elites of Sand Hill Road, but it is just that: a myth. Any organization willing to put the time, effort, and energy into hiring the right people and setting up communication practices that work for those people has fantastic odds of success (without all the rent and relocation expenses).

Disclaimer: The opinions expressed in this piece are mine alone, and originated from my vantage point as a team lead at WellMatch. They do not represent the views of WellMatch, Healthagen, or Aetna in any way and should not be considered official or sanctioned.)

Start Asking Questions

Impostor syndrome is something I've been fascinated with for as long as I've known about it. But I've suffered from it for far longer.

It reared its ugly head again this summer when I started a new job. As part of my training, I had the good fortune of spending a month pairing in the Hashrocket offices in Jacksonville, FL. Working with some of the sharpest developers I've ever met was a fantastic learning experience, but it wasn't easy.

When I walked in that first day and sat down next to Micah Cooper, I felt out of my depth. Micah was warm, friendly, helpful, and encouraging, but he was also much better at [Vim](\)) (our editor of choice) than me, and he practicedoutside-in development like it was second nature while I fumbled along.

It's not like I wasn't prepared. I knew when I got on the plane to Jacksonville that I would be learning a new codebase as well as a new set of development practices concurrently. I fully expected that doing this with a Hashrocket developer sitting next to me would make me doubt my own abilities, and it did.

The worst part about impostor syndrome is that even though you suspect that the nagging doubts in your head are false, you're never really sure. When you're confident in your abilities, it empowers you to ask questions about things you don't understand so that you can learn. At its simplest, impostor syndrome robs you of that confidence.

So how do you get out of it? For me, the answer turned out to be pretty simple. I started forcing myself to ask questions. Little Vim things at first, like "How'd you delete that whole paragraph?" and "How'd you jump to that method?" Things that didn't require much vulnerability to ask. Once you get those first questions out of the way and realize that all the scary stuff your brain has been bullying you with (getting made fun of, being revealed for the crappy programmer you're afraid you are, losing your job) doesn't actually happen, you start to build that confidence back.

Pair programming has also helped me quite a bit. I had never paired before this job. When I compared my raw, messy thought process with others' finished work, it was pretty easy to psych myself out, thinking how much smarter than me everyone else must be. Pairing gives you the missing context of what happens before the final product, and it helps you have a more accurate basis for gauging your relative strengths and weaknesses. I'm finding that the more I pair with others, the less I struggle with impostor syndrome. Not that it's gone, but it's easier.

My time at Hashrocket really took off once I worked up the confidence to be insistent about the things that I didn't understand. I got what amounted to a full day training course in Cucumber simply by admitting "I've never used Cucumber. How does it work?" My WellMatch pair and I got a week of invaluable Backbone training by sharing the terrible code we'd written with Micah Woods, another Hashrocket dev, and asking him to help us fix it. I leveled up at least three belts in Vim just by being willing to stop whoever I was working with and ask how they did that crazy edit with only 2 keystrokes.

I finished my time there with an overwhelming amount of new knowledge and a few new friends as well. If I hadn't worked up the confidence to be vulnerable and ask questions, none of that would've happened. It wasn't easy, but it was worth it.

Have you struggled with impostor syndrome? Found something that works for you? I'd love to hear from you on Twitter.

VPN and Apple's Airport Extreme

Video baby monitors and 2.4 GHz wireless networking do not play well together. This is the fact that led to my purchase of a refurbished Apple Airport Extreme from Best Buy a few weeks ago. I still have a few devices that are 802.11g-only, so going simultaneous dual-band was the only way I could get reliable performance for my computers and keep all my legacy kit at least marginally online.

It was about a week after installing the Airport Extreme and living in no-interference bliss that I realized my VPN connection to my hosting provider wasn't working. We host with Softlayer, and thanks to their wonderful private network infrastucture, I'm able to firewall off all ports except 80 and 443 from the public Internet. To SSH to any of our boxes, I need to connect through Softlayer's VPN gateway into the private network.

I couldn't. The VPN would authenticate just fine, but I wasn't receiving any traffic. If I changed my VPN settings to "Send all traffic over VPN connection", I could connect to NE's servers, but since Softlayer's private network is completely disconnected from the public Internet, I had no network access other than to my servers.

But this was only when I was at home. Everything worked fine when I was at the office, and everything had worked fine from home before installing the Airport Extreme. I had my culprit.

I sent several emails back and forth with Softlayer's support department asking about oddities of working with their VPN and Apple networking gear, but I'm not sure anyone in their first-line tech support even understood the specifics of the problem. I also spent 30 minutes on the phone with Applecare, but they had no answers either.

Once I got a response from Reed F. in Softlayer's second level support department, though, the solution became obvious. Reed's excellent response:

If I am not mistaken, most Apple gear tends to use a 10.x.x.x addressing schema, if
this is the case, then it will conflict with the routes that are provided from the VPN

(As an aside, Softlayer's support department constantly amazes me. They're patient with the most mundane requests, always fast to respond, and driven to solve even issues like this where the problem is obviously not on their end. I can't recommend them highly enough if you're looking to lease a server.)

Apple's wonky default 10.0.1.x IP address scheme was conflicting with the 10.x.x.x scheme used by Softlayer's VPN. Softlayer chose that scheme, I'm sure, because most consumer network gear distributes 192.168.x.x IP addresses by default.

A quick switch of the Airport Extreme to using 192.168.1.x IP addresses and all was working as expected. If you're having trouble getting a VPN to work from behind an Airport Extreme (or Airport Express), that's definitely the first thing to try.

The Magic of `top`

After receiving several replies to a random gripe I aired via Twitter, I’ve realized I’m not the only one frustrated by the differences between Linux-flavored and BSD-flavored top. Like a lot of people, I do my dev work on a Mac but deploy to a Linux production environment, so I’m constantly switching between Linux and BSD top (OS X is based on BSD, not Linux.)

What is ‘top’, anyway?

If you’ve used Windows Task Manager or OS X’s Activity Monitor, you’re already familiar with what top does. top is basically the *nix command line version of those two programs. It’s your one-stop-shop for any information you need on how loaded your system is and what specific processes are eating all that RAM or CPU time, but a little knowledge on how to use it goes a long way.

Linux-style ‘top’

Despite using OS X on a day-to-day basis, I’m far more familiar with Linux’s top command. It’s got a lot more functionality than BSD’s top. Here’s the basics:

Right After You Launch

The first things I do after launching top on Linux are press ‘z’ to turn on color and then ‘x’ to turn on sort-field highlighting. There’s no command line flags to do this for you, but I’ll explain a bit later how to save this as your default configuration.


There’s several ways to sort your process list in Linux’s top. Most of the time you’ll want to sort by Memory Percent Usage or CPU Percent Usage, and thankfully Linux provides us handy shortcuts for this (yes, they’re all uppercase - just type them in the main top screen):

  • M - Percent memory usage
  • P - Percent CPU usage
  • N - PID
  • T - Execution time

If you want to sort by a field other than those four, there are two ways to do it. First, you can use ‘<' or '>‘ to cycle through the sort columns. (This really isn’t useful unless you’ve typed ‘x’ first to turn on sort-field highlighting, though - how would you know what you were sorting by?) You can also type ‘O’ or ‘F’ to pick your sort column from a list.

Finally, if for some odd reason you need to know what programs on your system are using the least CPU or memory, you can type ‘R’ to reverse the sort order on the current field.

Interacting with Tasks

There’s plenty of other stuff you can do in Linux’s top, but the only other function I find useful on a regular basis is killing/renicing runaway tasks. To kill a task, type ‘k’ and enter the task’s PID. top will ask you what type of signal to send, the default being ‘SIGTERM’ (probably what you want, but if a process just won’t die, ‘KILL’ can be useful here as well). You can also renice a process by typing ‘r’. A negative number will give the process more priority, and a positive number less.

Default Configuration

If you get tired of typing ‘z’, ‘x’, ‘P’ as soon as you launch to get your color and favorite sort order, then the ‘W’ command is your friend. Once you get your top just like you like it, type ‘W’ and top will write out a configuration file to ~/.toprc and your top will launch with that set of parameters every time.

BSD-style ‘top’

Thanks to my reliance on OS X’s Activity Monitor, my BSD top-fu is weak, but writing is an exercise in learning.


There’s no quickie shortcuts to sorting BSD’s top, but thankfully there is interactive sorting available. To use it, type ‘o’ and top will ask you for a sort field. You can also type ‘O’ and top will ask you for a secondary sort field. Here’s an abbreviated list of sort keys - check the man page for more:

  • command - Command name
  • cpu - CPU usage
  • rsize - Resident memory size
  • time - Execution time
  • vsize - Total memory size

You can also specify sort order on the command line using the ‘-o’ and ‘-O’ flags just like you would use them interactively. Eg.: top -o cpu -O rsize

Interacting with Tasks

BSD’s top also gives us a way to send signals to a given process. Type ‘S’ and top will ask you what signal to send, defaulting to ‘TERM’ (which is probably what you want - again, use ‘KILL’ for stubborn tasks). After setting your signal, top will ask you for the PID to send the signal to. One thing to remember is that, if you use a signal other than the default, top will default to that signal the next time you invoke the ‘S’ command.

Wrapping Up

There’s quite a bit more tweaking possible with top than what I’ve explained here. The best source of info, like all *nix commands, is the man page for top on each operating system.