Older posts...
Older posts...
23 Sep
Designing APIs in a resource-oriented architecture
23 Sep 2014
Designing APIs in a resource-oriented architecture
28 Sep
How I'm going to land my dream job
28 Sep 2014
How I'm going to land my dream job
1 Oct
Neural net training fail
1 Oct 2014
Neural net training fail
13 Oct
Pow + SSL without the hassle
13 Oct 2014
Pow + SSL without the hassle
17 Oct
Using machine learning to rank search results (part 1)
17 Oct 2014
Using machine learning to rank search results (part 1)
23 Oct
Using machine learning to rank search results (part 2)
23 Oct 2014
Using machine learning to rank search results (part 2)
9 Nov
Managing complexity in Go
9 Nov 2014
Managing complexity in Go
25 Nov
Remote work: an engineering leader's perspective
25 Nov 2014
Remote work: an engineering leader's perspective
19 Sep
Running A/B tests on our hosting infrastructure
19 Sep 2016
Running A/B tests on our hosting infrastructure
27 Mar
Every service is an island
27 Mar 2017
Every service is an island

A case of PEBKAC

The general population is quite technology-unsavvy. Here’s my most recent encounter with this ever-so-true nugget of geek wisdom I tend to forget.

Lesson learned for software developers: listen to your users’ pain, but wear earplugs. They’re often wrong, especially about the details.

Learn their cognitive biases. And own what you build.

I’d rather warn you, this story is going to sound silly to seasoned geeks in the audience. Please bear with me. All characters in this story are fictional.

As an intro, I like to think that there are two things in “IT” (for lack of a better term) that no-one has managed to get right in four decades of mass-market computing: printers and local networks.

In both cases, getting anything to just work, even more so in a heterogeneous (read, Mac + Windows + Linux) network. Even a simple print/scan/fax machine requires an absurd amount of setup.

My point is no to talk about lack of standardisation in printing, but rather about what happens when you decide to put matters in your own hands.

Birth of an office hero

So, we had a crappy Wifi setup in the office. BT brought the fiber in and set a decent router up, and our office manager paid a wire-laying contractor to plug in a few cheapo access points.

Of course, as soon as we went past a few tens of users (plus their assorted array of devices), things went south, and only coffee deprivation makes a startup more cranky than a bad internet connection.

Being a generally nice person, I stepped up, bought a few reliable WAPs, configured them as a single SSID (one 5GHz, one 2.4GHz) to allow roaming, and found the best spots to place them at.

Finally, I ditched the old WAPs, and all was well. My praises were sung, and I got so much fan mail I had to hire someone.

The harder they fall

That’s when I noticed a change. More often than not, a user having “internet problems” would ask me for assistance. Soon enough, I found myself utterring the inevitable turn-it-off-and-on- again incantation. Usually successfully.

Network switch

This is actually less user-friendly than an iPhone…
and less user-proof, too.</figcaption> </figure>

Well, except that day when someone thought it’s be a good idea to plug both ends of the same Ethernet cable in the same switch.

But in general, multiple non-geek teammates were asking me questions, mosts of them silly (no offense to them, I’d be as clueless on their turf).

Why this is relevant

While being helpful like this gives me a warm glow of usefulness, it’s probably the best possible use of my time. But hey, it was still a bit of fun and helped me re-learn a couple valuable lessons for any open-source software author.

Users will hold you accountable for what you’ve built for them.

If, like me, you occasionally build software libraries or event small tools for users, trying to help solve their problems, they will end up having expectations:

You should carefully weigh whether to respond to users’ pains: once your code is out, they’ll have a reasonable expectation that you will maintain it, and possibly beyond what you originally intended.

Even if all you’ve put online is a tiny hack you’ve open-sourced, say a small library, they’ll expect you to keep it up-to-date, working, and compatible with the kitchen sink. And rightfully so: you own the product you built.

Users’ signal to noise ratio is low.

When something breaks, users will assume the most top-of-mind part of it broke. Back in the day, when the Google stopped working, users assumed the computer was broken when it was their internet connection. In my office Wifi example, users assume the Wifi is broken when they forget to turn it on on their machine—probably simply because they heard about a recent Wifi upgrade.

This is a classic cognitive bias known as the availability heuristic: people make judgments about the probability of events by how easy it is to think of examples.

In most cases, “your gem doesn’t work” actually boils down to “I haven’t configured things properly”, or “I’ve used it outside recommemded parameters/dependencies”, which it turns may well mean “I haven’t read the README”.

You implicitly accept responsibility for this when you release open source software!

In other words: caveat emptor when using someone else’s code, but… caveat venditor when you’re sharing your own. Prepare to show your users some love and do a bit of handholding!

Not that this should keep you from building and sharing great software!