Kyle Simpson @getify gave a talk on the "economy of keystrokes" at the last MallorcaJS meetup on October 15th, 2019. Kyle's talk was sometimes eye-opening, sometimes encouraging and sometimes controversial but indeed worth listening to.
For those of you who don't know Kyle Simpson, It's an author of the "You don't know JS" book series, speaker, teacher and more. Kyle was invited to Mallorca by Trivago guys and kindly agreed to share his wisdom with MallorcaJS community.
I'd like to share a few takeaways from Kyle's talk with you because I believe it's something that every developer should contemplate.
Kyle was giving his talk in a bit unusual way - by creating slides on the fly. I think it's a very flexible way allowing the speaker to adapt to the audience attitude and familiarity with the topic.
Kyle started from comparing keystrokes with a currency (money) by suggesting the idea that we buy functionality with keystrokes and invest keystrokes into our products, our code which we generate with keystrokes can reduce its value with time (inflation), etc. This is, from my point of view, is a very good analogy.
The important takeaway here is that as developers, we should think about in what quality of code we invest our keystrokes. To make our code sexier with shorter solutions or to make it understandable sacrificing a few additional keystrokes?
Let's look at the classic JS function syntax:
function x (y) {
return y * 2;
}
Today some developers can say that the "function" keyword is too long and it's a waste of keystrokes if we compare it with the modern Arrow Function syntax:
x = y => y * 2;
But the Arrow Function example is not automatically more readable just because it's shorter. Imagine if you see it the first time. Is it that readable? The thing is, if we remove all visual signals, it requires more effort to comprehend the code.
In fact, the "function" keyword is not a waste of keystrokes but it's an investment in readability of the code.
The readability is the most important quality of code. We write our code for humans, and not for machines, so the code should be well-readable and easy-understood. From my point of view, it's the most important idea of the talk.
Stuff you write which doesn't communicate information clearly won't survive. Imagine, you look at a piece of code and you can't comprehend what it does. How likely it is that you won't rewrite that piece of code from scratch in one of the next iterations?
Here is my personal example... I remember the times when I was just starting my career while finishing university. I was crazy about OOP features and patterns and tried to use them very actively in my work projects. One day my boss called me for a chat and said that my code was not good enough. He asked me a question which I now often ask myself when thinking about code design and architecture of every new project: "Will another developer who gets your project after you easily understand what the code does?" He asked to reduce the number of OOP abstractions and patterns in my code to the reasonable minimum. I was confused at first because I thought that the more patterns I use, the better. My further experience of working on different teams confirmed that my boss was right.
Kyle shared a lot of information on the topic proven by science, his own experience or famous people in the industry, so I can hardly retell it all here precisely. However, here are some more insights from his presentation which I personally found interesting:
- Familiarity. Readability is influenced by whether you're familiar with the code/concept/approach or not. The code you know well or the syntax you used a lot before can be more readable for you.
- Cognitive load. There is a limit of information people can process at a time. This quality of human brain can also affect readability. We should take it into account, for example, when we speak at a meetup.
- Tribal knowledge and conventions. We assume that everybody else knows what we know. It's when you find your code quite readable but other people don't. What would happen if a new dev doesn't have that tribal knowledge? We should think about that when we write our code or create conventions.
- Empathy in code review. Use code review to teach people and learn, not judge. If code under your review is not good enough, call a person and say: "I'm gonna accept your PR but it'd be better to use different techniques next time". It will build people up!
- Code comments. The idea that we don't need code comments and, instead, our code should be self-documented is complete nonsense. Not overload code with comments but do use them moderately to explain Why (sometimes How) and not What.
In conclusion, I'd like to encourage your to follow Kyle's piece of advice:
Make every keystroke spent, and every keystroke saved, count for REAL value! // Kyle Simpson