Essentialism for developers

Essentialism – the Disciplined Pursuit of Less by Greg McKeown is a book with an essential message: much of life is irrelevant distraction and we would all be happier and more productive if we learned to strive for less, but better. I encourage you to read it, if only because sitting down and reading a book is good for your brain. Granted, it’s a self-help manual written in the typical Ted-talk style and aimed at an audience of business professionals high on ambition and short on sleep. It also fits in nicely with an already large number of popular psychology books that, each from their own angle, expose the evils of our 24/7 online lives. That doesn’t make the message any less relevant: our state of constant distraction is making us less happy and less productive. This is not going to be a review or summary of the book. Let me just highlight and elaborate on some sections that struck me as particularly relevant in my daily work as a software developer. Hopefully it will for you too.

It’s an old and familiar story: the best programmers are a thousand times more productive than the average ones. You can argue about the actual numbers (Linus couldn’t code in an hour what takes me a year), but you can’t argue the fact that some people’s creativity is just way off the charts. This is the well known Pareto distribution in action and convincing evidence that the universe is not fair. Chances are that you (like myself) are nowhere near as inventive as Linus Torvalds or Mitch Kapor. Statistically it’s a safe bet you’re not even in the top one per cent. So why rub it in? Well, what the best performers in any walk of life have in common is that they all like what they do and do it well. We can’t all be the best, but this is something that we can do.

I’ve been earning a living with programming for the past eighteen years. I have also been an English teacher, translator and call centre tech support operator. I am probably five times happier programming than translating and fifty times happier than doing call centre work. I like to think that I have hit the sweet spot between what I like doing and what I’m good at and nothing could be more important. The differences in satisfaction and productivity between all the career paths you could plausibly pursue are huge. Also note that passion always trumps talent: you can be lousy at a job that you like doing and you’re going to get fired. You can also be good at a job you actually hate and you’ll burn out, which is worse. Or you could be in a low paid job that you hate and for which you are unqualified, like when I did tech support in the previous century. Profitability or market demand should come a distant third. Doing something only because it’s lucrative is still going to make you miserable.

Taken from the article https://hbr.org/2012/08/the-disciplined-pursuit-of-less without prior permission, but I’m promoting the book, so I guess it’s okay.

McKeown stresses that you cannot really choose unless you know what your options are, and the best option is going to be a lot better than merely second best. Quite daunting, especially when you’re young. Why do so many people follow their parent’s footsteps when it comes to career choice? There is no special gene that a medical doctor passes on to his offspring that makes her more likely to succeed as a doctor (or actor, plasterer) as well. It’s because choice is hard and we’d rather let life decide for us. We subconsciously like to please our parents – yes, even when we’re sixteen! – and avoid the agony of choice. Your brain likes to run on auto-pilot whenever it can. Everything it can turn into a habit is snatched away from the reach of your free, conscious will. If it didn’t, driving a car during peak hour traffic would be completely exhausting, which it is for a beginning driver. Later our mental auto-pilot does most of the driving and you suddenly wonder how quickly you arrived at your destination, deep in thought about some juicy bit of coding that awaits you. Thanks to the same mental mechanism we find ourselves in unhappy marriages or disastrous careers wondering how the hell we got there. Constant and conscious evaluation is vital for making deliberate choices. It takes time and self-knowledge, but you wasted it on Game of Thrones.

If you’re a fellow programmer reading this post I assume you’re happy in your present career. But it’s a career where exploration never stops. Since the IT landscape is so huge and dynamic we need to constantly change focus and learn about the latest and greatest or soon we’ll be dinosaurs. No we shouldn’t. No one can even begin to keep up with everything new on the horizon. You need to carefully choose what to explore and what to ignore and do so by evaluating it in terms of your passion and talent, and by realising that not all options are equally important.

You can compare working in IT to sitting in a train and watching the landscape go by. If you focus on the first fifty metres you see electricity posts flashing past. They are Angular 1, 2 and 4. Remember those three farm houses a while ago? Those were EJB 1, 2 and 3. Look at those distant mountains: they are object orientation, functional programming, Eclipse, HTML, RDBMS and virtualisation. SOLID programming skills never lose their relevance. Some tools, frameworks and languages are here to stay while others ride the crest of a wave and are heard of no more. Shame about all the time you spent learning them, but that’s life. This is not to say you should be overly conservative and never be an early adopter. Not at all. I’m into Kotlin because I like it, not because I expect it to be the next Java killer – although hope springs eternal. It does mean that investing in basic programming and software design skills is always a safe bet.

Much of the time that goes into learning any new tech stuff is about wrestling with its quirks before mastering the basics. You spend five minutes on the Getting Started page and stackoverflow is your friend for the rest of the slippery learning curve. Admit it. Who has time to read manuals nowadays? There’s always factual knowledge required if you want to work with Framework X, but learning the bare minimum to get going doesn’t feel like mastering a skill. It leaves you feeling like an amateur even when it gets the job done.

I believe that as a developer you should focus on a portfolio of skills with minimal overlap rather than be a jack of all trades and master of none. Skills and knowledge are not created equal. You can buy IntelliJ, google everything there is to know about its keyboard shortcuts and a little knowledge goes a long way. But in the realm of IT security knowing a little is worse than knowing nothing if it leads you to conclude you’re competent enough to do things like tinkering with firewall settings. Also many tools/standards/frameworks are interchangeable whereas others are complementary: a good web developer should choose a single framework and become expert at that instead of being just competent at three frameworks that really do the same.

I haven’t done the numbers, but it’s safe to assume that less than one per cent of programmers work for the five (US) companies that account for 95% of all internet traffic. I don’t work for Google, Facebook, Netflix or Amazon (thank heavens! ) and none of the companies I worked for had anywhere near the same requirements in scale that gave rise to the family of frameworks and techniques that these companies helped develop to solve their very specific needs. “Netflix has gone reactive so we should too”. This is hype driven development in a nutshell and we should avoid it like the plague, which is not to say anything about the technologies per se, only about the absence of critical thought.

One closing remark to put things in perspective: maybe you heard about the pop psychology concepts of satisficers and maximisers. Maximisers spend an inordinate amount of time in choosing, while never being happy about their decision and still anxious that they have missed out. Satisficers know when to stop. What’s more, they know that some decisions (where shall we eat?) are not worth getting hungry over. So don’t become a maximiser. Only ponder what’s worth pondering. And one last tip: if you really want to know if framework X is worth learning, always google “Why X sucks” and “I hate X”. These rants can save you a lot of misery and they’re often a great laugh.