My career-related content is now open-source on GitHub.
Thoughts on my personal mantra
Laziness, Impatience and Hubris
The kindest compliment I ever received
On a professional level I mean.
In 2004, I was in engineering school at ENSIMAG, Grenoble, France.
Our class was struggling on a quite difficult algorithimic challenge.
For my part, I had given up and was trying to find a way to work around the main difficulty.
Suddenly, a loud intervention from my professor:
Jean-Michel, I have been watching you for a while now.
And I must tell you something
😮
You are very lazy
😶
You will be a great engineer
😊
What would you say are your three greatest strengths and weaknesses?
We have all heard at least once this stupid question in a job interview.
Actually, if that's not your case, please write a comment, that would give me hope.
And as a general rule, stupid question -> stupid answer.
Or frankly here, you would be justified to turn the tables:
Yes sure, give me one minute to order my thoughts.
In the meantime, I have a question for you :
What would you say are the three most annoying questions one could ask in a job interview?
But humans are creative, and no matter how stupid the question, one can always try to give it a clever answer.
Larry Wall's answer
🇬🇧 Most of you are familiar with the virtues of a programmer. There are three, of course: « Laziness, Impatience and Hubris »
Larry Wall is a US linguist.
He is also best known as the creator of Perl. At least to the odler folks, Perl is not often used those days (I think? Maybe I just lost track.). But Perl played a big role in daring to question the old Unix dogmas, helping the early internet to rise, playing the role of Python's nemesis, and was a major inspiration for Ruby.
But even if you don't use Perl, and I don't, Larry Wall is a very interesting guy.
I mean most programming books are bad or boring (same for every other subject), the good ones are helpful, a few are super interesting, but Larry Wall's book belong to the happy few programming books that on top of all that made me laugh.
I didn't know that was possible.
[Video] What skills or characteristics do you need to be a great programmer?
You should watch the video, I think it's a quite cool one. But I know you are probably in the subway, if you live outside of the US anyway, or you are in a super loud café, or you have an hearing handicap.
No issue, I will make a transcription just for you.
"This is a joke", almost
Laziness, Impatience and hubris.
These originated as sort of a joke in the first edition of what we call the Camel Book, the book that teaches the Perl programming language.
And in a sense, these are the three virtues of a programmer.
A lazy person will try always to find some way to do something, will always be looking for ways to do something faster, more efficiently.
And if you really want to control the world, that’s really sort of a hubristic notion. Excessive pride. The kind of thing Zeus zaps you for having.
But it really was sort of a joke….
In the Japanese edition of the Camel Book, they had to add “Laziness, Impatience and Hubris. (THIS IS A JOKE)”. Because they thought people could take it seriously.
But really … what makes someone a good programmer is much more than those three things.
Hobbits Would Make Great Programmers
If you have either read Lord of the Rings or seen the movies, you know about Hobbits. Well : Hobbits manifest many of the virtues you need as a programmer.
You need to have persistence when the going is rough to keep slogging through. A kind of innate stubbornness. In an happy way, not in a mean way.
You have to be smart enough to outwit your enemies occasionally.
You have to be able to be social, you have to be able to deal with a group of team members. Some of which are like you, they are other hobbits. Some of which are elves, dwarfs. Or even men.
They think very differently from you.
So you have to contribute your part as a hobbit, but also be able to understand other things. The day is long passed where programming was done individually. Almost all programming is done in teams.
So for example you need to be literate. You have to be able to read documentation. And to write documentation that others can understand.
But mostly you need to be just slightly insane, in the way hobbits are. Where they can view the long term, where the goal is to go back to your village. But also at the same time, they can forget about all that and deal only with the problem they have at hand.
On more concrete terms
On more concrete terms, you may be telling a computer to do various things. On one hand you have to be aware of what happens at a low level. But if you are aware of that all the time, you are going nuts. So you have to shutdown and work on high-level abstractions.
And doing both simultaneously gives the best results in programming. If you ignore one of those, you end up messing up.
So that’s what you really need.
A hobbit is lazy in a very industrious way.
A hobbit is impatient in a very patient way.
A hobbit is proud in a very humble way.
It sort of sounds contradictory. But to the extent that you can increase your dynamic range on all of those …. you will be a better programmer.
FAQ: What the F# is Hubris?
One name: Napoléon.
In the early 1800s, after having vanquished many European coalitions, Napoléon controlled pretty much all of continental Europe. But he couldn't help himself and decided to invade an allied country, Spain. Disaster. And then he couldn't help himself and decided to invade an allied country, Russia. You know where this leads: in the middle of the Atlantic ocean.
That's what hubris is. Dangerously excessive pride.
As Larry Wall mentioned, there are pretty cool Greek mythology stories around Hubris, as you can find out on Wikipedia
Laziness, Impatience, Hubris & Me
If you have read this far, you probably find the mantra interesting, funny, clever.
And sure, it is all that. That's part of the reason I chose it as my personal mantra.
But for me this mantra is more than that, it has meaning. It tells something important about me
Hubris, for me, consist in being stubborn and selective when I choose the kind of project I work on. It's not enough for me that you put things on the Blockchain, or that the Elon guy tweeted about it, or that BigCompany pays for it.
I need a convincing answer to one nasty question.
Who really needs this project, and why?
The search for meaning is the constant struggle of my career.
Impatience is clearly a personality trait that I have. I left the Android world in part because its slow build times were for me an agony. And that was the right thing to do.
Caveat : impatience is my least favorite of the three virtues, because it is very much a double edged sword. I have sometimes hurt people I love by being too impatient. And that's where the extend your dynamic range principle shines : what I have learned is to be way more patient with people, and even less patient with tools.
Laziness finally is my dominant great virtue, as first observed by this clever teacher.
And it would be easy for me to put an asterisk on lazy. I could point out that I have written 100 articles here, and more on in my french-speaking blog, that I have started a successful open source project, that I have shitload of stuff on my GitHub, that I have learned 7 programming languages, and also 7 real languages, and 5 music instruments, learned the culture of 4 different countries...
In sum, I could say that it's only a joke.
But I won't hide behind my little finger.
Unironically: I have a significant amount of laziness in my soul.
And not just because nobody is perfect.
But because I choose a profession that fits my personality: Programming means automating.
We are not supposed to be the digital equivalent of Charlie Chaplin's depiction of workers of the industrial age doing boring and repetitive tasks.
But it's also spiritual: Laziness has often been the sacred source of my creativity.
And I won't apologize for it because I don't want my creativity to dry up.
Related
This post's title was inspired by this pretty cool article from @sobolevn
Call to action
Please have a nice lazy day ☀️
Top comments (24)
Really nice article. The part about laziness throws me back to around a decade ago when I answered that as a weakness for an internship and the feedback I got was that I should never use this word on an interview but rather say that I'm proactive or something.
Nowadays I've been reflecting on how my main motivation to get my work done is exactly not having to work and how I could never say that on a job interview.
I'm glad that it resonated with you, thanks for your kind words.
Yes, that's very widespread, LinkedIn is infested by it, that's the cult of toxic positivity.
You wouldn't believe how many grown ups would benefit for watching a Walt Disney movie...
Nice article. I definitely prefer a 'lazy' style of coding. I sometimes know there's a more 'clever' solution to a problem; and sometimes see these implemented when doing code reviews. But often these 'clever' solutions increase complexity/decrease legibility; and are quite often clever just for the sake of it (i.e. provide little, if any, benefit).
Knowing that I - and others - will have to come back and work with that code at some later time I almost always stick to the 'lazy' option. That's easier than having to remind myself how the clever solution works; and in practice saves everyone time and effort.
That's great dialectic. You search the right trade off between two kind of laziness, short term laziness (the clever solution will spare me some work) and long term laziness (I will need to explain to my colleagues and maintain later).
When you think about it, the history of mathematics is the history of laziness. If we weren't lazy, we wouldn't have multiplication, we'd still add up the same term again and again and again. (In fact we wouldn't even have addition because we could just count marbles one by one or something.)
But importantly it's not any kind of laziness, it's laziness coupled with a determination to still achieve the correct result.
Another good example
Bad laziness is minimizing the amount of efforts in the short term
Good laziness is minimizing the amount of efforts in the long term.
Level 10 is where you don’t write any code because the product feature that’s being requested is not what’s actually desired and you nip it in the bud before you start. Sadly, this part usually involves a lot of talking.
Level 11 is when you inform product that what they really want (not what they think they want) is already available by doing X instead.
Then, with product off your back, you can go back to fine tuning and refactoring the spaghetti mess that the last revolving door of devs left you
Absolutely.
Building things right is important, but building the right things is even more important.
I think the Lean Startup has pretty valid insights on this that are too often neglected.
I also prefer a simple and straightforward approach to coding, often referred to as the "lazy" style. The clever solutions may be implemented for the sake of being clever, without providing significant benefits.
As developers, we must consider the fact that we or others may need to come back and work with the code at a later time. Therefore, it is usually better to opt for the lazy option, which is easier to understand and saves time and effort in the long run.
Nice article, just that the french link is dead, possibly from a trailing underscore.
Merci! 🙏🏻
Applause! Clap your (my) hands 👏🏿👏🏿👏🏿❗
Super! I guess it was all I needed to hear!
Before we developer anything, we have to be able to developer ourselves.
I am here to read article and comments and become lazy...
Welcome to the club.
You probably already were the day you choose to become a programmer though :)