Jakub Arnold

Programmers Suck at EmpathyDec 10, 2013

Given the nature of our profession we have to continually keep learning and improving our skills in order to not fall behind the evolving curve of technology. But as we learn more and more we forget how it was like in the beginning.

Every time you try to understand a new concept it takes a while for your brain to accept it. It can be recursion, monads, NoSQL databases, single page applications, or whatever you pick and choose. But no matter what the problem is, you will always feel the same frustration in the beginning, the moment of How the hell does this thing work?

If you only ever used relational databases and then suddenly someone shows you MongoDB, you just won’t be able to process the idea of it. It the world of rigid and strict schema it doesn’t make sense to store data in a way that has absolutely no schema. But after a while, which might be a few months of background processing in your brain, the whole thing will click and you’ll understand what it’s good for. It’s the feeling of reading an article or a book and not really having a clue what the hell is going on, only to understand it next morning when you wake up.

When the epiphany strikes your whole world changes. Suddenly there is a place for that weird thing which you despised yesterday. Suddenly it all makes sense and it seems easy. You feel like you understand, finally. It can be the most trivial thing, or something you’ve been trying to learn for years, and suddenly in that one second you get it. This is also when the thing becomes trivial to understand for you. Which leads to the next step

teach all the things

Once you understand the thing it becomes trivial to you. You feel like it’s so easy that anyone can understand it if you just explain it to them. But you’re wrong.

Let’s take a monad as a good example here, because 98% of all tutorials on functional programming are explaining how monads are so stupidly simple that you can’t not understand them.

You can tell someone the definition (which is now obvious to you) in 10 seconds, but it really doesn’t mean they’ll understand it in 10 seconds. Not even if you say that monad is actually a burrito.

Imagine you have a friend named Joe, who likes to program in Java and only Java. Joe doesn’t spend much time reading about programming. He just does his job and then comes home to his wife and kids.

One afternoon you come over to Joe’s table, enlightened with understanding what a lambda function is (because you spent the past two weeks thinking about it in the shower) and try to explain it to him in 3.7 seconds. Joe will look at you thinking you’re crazy. Why would you ever want to do that? Why does it have such a silly math name? Are you trying to teach him math?

In Joe’s world there isn’t such a thing as function as a value, because Joe doesn’t think in functions, he thinks in objects. He doesn’t even understand what you mean by the as a value part until you explain it, because he never thought about programming in that way. In his world there are methods that take arguments and that’s it.

You can’t start from the middle and say that he could theoretically just pass in a lambda instead of using a anonymous Runnable. Because Joe will look at you and say something like Why the hell would I use an anonymous Runnable? My IDE will happily extract that into a separate class.

In Joe’s world the concepts you’re trying to use to explain something like a lambda or a monad don’t really exist. Joe will happily use a template or a strategy pattern with 10 different classes, because that’s what the UML diagram says. How to draw a lambda in UML?

To explain a new concept to someone requires empathy from your part. First you need to understand where they’re coming from and identify their view of the world, before you can shovel information in their face.

You’re not likely to convince a Java developer to try Ruby if you explain it in a way that only a Ruby developer would understand it. Other people work differently than you do. One person might draw a bunch of UML on a whiteboard before he writes any code, another person might sit down a write 400 lines of JavaScript without really thinking about the problem beforehand, another person might spend a week putting constraints in the database to make sure no data gets !@#$ed up. Do you really wanna start a discussion with that guy about MongoDB by saying you know, schema really isn’t that important.

Want to hear about my upcoming book,
Haskell by Example?

Haskell by Example Book

Subscribe to receive updates and free content from the book. You'll also get a discount when the final version of the book is released.