Four books to boost your programmer career in 2020 (including the one that made me quit my dream job)

This text was originally published on my blog: https://mikulskibartosz.name

Here we are, we are at the beginning of a new year. The time when people reflect on what they had done during the past year. The time of year when we think about everything we want to do during the next twelve months. For those of us who love reading books, it is also the time when we plan our reading lists for the beginning year.

In this article, I am going to show you a few books that, I think, may boost your career in software development. Most of them are not about technology, but I will order them from the most technical to the least technical.

The effective engineer by Edmond Lau

Let's start with "The effective engineer" by Edmond Lau because it is the only one of the books I am going to describe today that is written for the programmers.

In this book, the author describes the concept of high-leverage activities. He recommends focusing on activities that produce the most significant long term value. Edmond Lau described 10 such activities and the process of choosing the most impactful of them.

"Focus on high-leverage activities. This is the single most valuable lesson that I've learned in my professional life. Don't confuse high-leverage activities with easy wins." — The effective engineer

The author suggests asking yourself the three questions every time you are supposed to work on a task:

• How can I complete this activity in a shorter amount of time?

• How can I increase the value produced by this activity?

• Is there something else that I could spend my time on that would produce more value?

Some of the high-leverage activities Edmond Lau suggests are regular prioritization, optimizing for learning, and automation.

What hit me the most was the fact that Edmond Lau is writing about stuff that should be obvious to every one of us. It should be obvious, so why don't we do it every day?

How will it boost your career?

For me, "Effective Engineer" was almost like a "recipe book." You can directly apply Edmond Lau's advice to get immediate results. There may be some resistance if you are the only person doing it, and you don't get buy-in from the team, but perhaps the next book is going to help you with that.

The Psychology of Computer Programming by Gerald Marvin Weinberg

The second book is quite old. Its first edition was published in 1971. I was reading the Silver Anniversary Edition published in 1998, which contains additional comments written by the author 25 years after the publication of the first edition.

Why do I bother you with publication dates? That timeline is important because I was reading that book for the first time in 2015.
At that time, I was under the impression that things have not changed much since 1998, and Gerald Weinberg claimed that they have not changed much since 1971, either.

Obviously, technology has changed, but team dynamics, communication problems, dealing with ego, scheduling, and decision making does not differ a lot.

I won't' call this book a timeless classic. Still, it certainly gives us valuable insight into the history of programming and what people considered to be the essential skills of a programmer.

How would it boost your career?

It won't directly teach you anything, but that book makes you wonder what the most important part of your job is and what is going to be essential after the next 25 years.

On writing well by William Zinsser

Programmers are writers. Period. The ability to create a cohesive narration that follows the logical flow of events is as crucial in code as doing it while writing fiction or a newspaper article.

Learning to write well will make you a better programmer. Let me give you an example.

Terry Pratchett opened his book "Hogfather" with the following scene:

The senior wizard of Unseen University stood and looked at the door.

There was no doubt that whoever had shut it wanted it to stay shut. Dozens of nails secured it to the door frame. Planks had been nailed right across. And finally it had, up until this morning, been hidden by a bookcase that had been put in front of it.

What happens next? Does the wizard stand in front of the door talking about the soup he ate yesterday? Does the action move somewhere else, and the readers need to wait for 20 pages until they finally know what happens with the door?

Of course not! That would break the flow of events and surprise the reader. The scene continues with a dialog:

'And there's the sign, Ridcully,' said the Dean. 'You have read it, I assume. You know? The sign which says "Do not, under any circumstances, open the door"?
'Of course, I've read it,' said Ridcully. 'Why d'yer think I want it opened?'

Can we be sure that a programmer would write it similarly? Not necessarily. Often, when we read code, we have one question in mind: "Why is it here?"

"The code was in the middle of generating a PDF. But now it reaches to the database, gets some value, sends it to a REST API, and puts the response in a variable. That variable will not be used at all until it starts adding the last page to the PDF file."

Have you ever seen code that resembles that description? Would you like to read a book where the storyline looks like this?

How does it help you?

This book helps you write emails that are actually read by the recipients, bug reports that are not ignored, and compelling documentation.

But that is not the only benefit, because good writing skills are necessary to create code that can be maintained by other people.

If you learn it, things like the Single Responsibility Principle or DRY won't be arbitrary rules that you must blindly follow. Instead of that, you will realize that such practices are essential elements of well-crafted literature that also apply to programming.

Career Superpowers by James A. Whittaker

I recommend that book because it was an "eye-opening" book for me. It is a book that persuaded me to give up all my attempts to become a data scientist. After reading it, I quit the data science job and went back to data engineering and backend development.

James Whittaker made me realize that I could put a massive effort into the career shift and still not reach above the performance level of a mediocre data scientist.

He persuaded me to do it by writing a two-page long "Underachievement Manifesto" that made me think about my career choices:

This may seem harsh, but there is opportunity written all over it for those who aren't too blind with ambition to see it. The ranks of any fields, no matter how mundane or exciting, are full of people who have stretched to get there. People not quite smart enough for medicine still practice medicine. People not quite dedicated enough to law are still lawyers. People who aren't particularly mechanically minded still try to fix cars. This is why a good mechanic stands out, he or she is competing against people who aren't really good enough to be there. (...)

What I am proposing is that we be honest with ourselves and instead of stretching to be the dumbest person at the level above you, choose instead to be the smartest person at the level below you. (...)

One of these days we may live in a world where no one stretches too far; it would be a world where everyone was imminently qualified to do their job. No fakers, no pretenders, no one scratching to get by. Until that happens there is an opening for ordinary people to stand out when doing ordinary things.

What else is in that book? The author shares stories about events that affected his career and the lessons he learned. It may sound boring, but, in my opinion, James Whittaker is a world-class master of storytelling!

He writes about choosing the right niche for yourself, creating your elevator pitch, finding experts who can become your mentors, and "succeeding on purpose."

Be careful

Right now, I should tell you how this book helps you boost your career, but instead of that, I have to warn you.

James Whittaker's book is dangerous. If you read it and apply his advice to your life, you will be incapable of doing many mundane tasks.

No one in their right mind wants to do tedious work because it literally kills your career.

If you care about your career, you won't want to do "invisible tasks." It does not matter if you do an excellent job if the C-level management does not even know that you are doing it or does not care about it.

If you do what James is telling you to do, you will probably get the results you want and be happy with your career. If you read it and do nothing, this book will make you feel miserable.