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.
Michael and Kirk Douglas, Martin and Charlie Sheen, Lloyd, Jeff and Beau Bridges, Ingrid Bergman and Isabella Rosselini. And they’re only the famous ones.
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.
Elegant delegates in Kotlin
Kotlin has given us some really killer features . Some are obviously useful (null safety), while others come with a warning, like operator overloading and extension functions. One such ‘handle-with-care’ feature is the language support for delegation...
15.11.2017 | 5 Minuten Lesezeit
Anti-patterns part 2: Coding is the biggest Golden Hammer of all
In my previous post I explained how software anti-patterns are symptoms of bad habits that can be endemic to entire teams. Today I want to talk about what is perhaps the most infamous of all: the Golden Hammer. Actually, it’s a collection of hammers...
9.10.2017 | 6 Minuten Lesezeit
When anti-patterns become a pattern
There are plenty of learning resources on software best practices. Sprinkled in between all the well-intended advice are warnings about common pitfalls. We could do with a lot more of these warnings and think about why we keep doing the same things wrong...
27.9.2017 | 6 Minuten Lesezeit
The most useless knowledge of all
There are things a programmer needs to know, no excuses. There are things you can’t possibly all remember, so it’s fine to look them up when needed. There is the business domain the software touches on that you need to know. And then there’s knowing...
10.9.2017 | 5 Minuten Lesezeit
Not everything that is vital is also your core business
Large software projects have many vital concerns, such as authentication and authorization. Despite the wealth of available libraries in the Java ecosystem we seem to be re-inventing the wheel far too often. Keep the focus on the core business of your...
- Software architecture
16.8.2017 | 5 Minuten Lesezeit
In defence of pedantic tools
Outline We aim to please the customer at short notice and always overestimate our capacity to comprehend a system as it gets more complex. That’s a recipe for technical debt. The antidote to this psychological shortfall is more team discipline in writing...
- Agile methods
2.8.2017 | 7 Minuten Lesezeit
Mocks or the real thing? Tips for better unit testing
Recently I had to bone up on some of the new features in Mockito 2 and Powermock , though more out of necessity than from genuine curiosity. Powermock and Mockito 2 let you fake static methods, final classes and even constructor calls, but this has ...
- Agile methods
16.7.2017 | 8 Minuten Lesezeit
The vicious circle of bad test code and how to break it
SUMMARY Compared to the great advances in programming languages and tools, the day-to-day practice of how we actually code is messier than it should be. Especially for long running and complex products building things right is just as important as building...
- Agile methods
6.6.2017 | 9 Minuten Lesezeit
CRUD operations on Spring REST resources with Kotlin
In this practical, hands-on post I would like to share some of my experience in building REST services wih JSON and Spring(Boot) using Kotlin. All examples can be transferred to Java, and if you use the indispensable Lombok library it doesn’t even look...
2.4.2017 | 7 Minuten Lesezeit
Integration testing strategies for Spring Boot microservices part 2
This is the second part of my earlier post about strategies for integration-testing Spring Boot applications that consist of multiple (rest) services. You can find the accompanying sample application in my gitlab account: git clone email@example.com:jsprengers...
27.2.2017 | 8 Minuten Lesezeit
Integration testing strategies for Spring Boot microservices
SUMMARY: Unit tests are a necessary condition to clean code, but today’s convention-over-configuration frameworks like Spring Boot are often used to build applications consisting of multiple services. You need some way of ensuring that the parts are ...
13.2.2017 | 9 Minuten Lesezeit
Web frameworks and how to survive them
SUMMARY: Frameworks that help build the web apps of tomorrow must keep up with all powerful new technology there is on offer. At some point your application has to adapt, and that is never a painless process. You can avoid a total rewrite however if ...
12.1.2017 | 8 Minuten Lesezeit
Kotlin’s killer features
SUMMARY: Kotlin is a new JVM language fully interoperable with Java bytecode. It is clearly inspired by Scala, but has a different design philosophy, a much gentler learning curve and some really helpful features like null-safe types. The Importance ...
3.4.2016 | 10 Minuten Lesezeit
Caching de luxe with Spring and Guava
Summary We generally don’t optimize expensive operations in code until they create a bottleneck. In some of these cases you could benefit a lot from caching such data. The Spring solution is non-intrusive, highly configurable yet easy to set up, and ...
14.3.2016 | 13 Minuten Lesezeit
Sensible mutation testing: don’t go on a killing spree
This is a follow-up to my earlier post about mutation testing (MT). To recap: MT helps you ensure that your unit tests are any good. The framework manipulates your compiled code by inserting small changes (mutants). It then re-runs your tests and expects...
26.2.2016 | 6 Minuten Lesezeit
Mutation Testing: Watching the Watchmen
You can’t do without automated (unit) tests if you want to stay on top of the ever increasing complexity of software projects. A mutation testing framework ‘watches the watchmen’ by inserting small changes into your compiled byte code and then validating...
25.1.2016 | 7 Minuten Lesezeit
Dein Job bei codecentric?
Agile Developer & Consultant (w/d/m)
An allen Standorten
Gemeinsam bessere Projekte umsetzen.
Wir helfen Deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Do you still have questions? Just send me a message.