Books that changed my career - Introduction
This blog post is a starting point of a series which contains the most influential books that I have read in my programming career. This is my private ranking, each post will contain a good dose of my private opinions (you have been warned), but besides that I hope that you will find it valuable.
Introduction
If you are a programmer and you like your profession, it is very likely that you are reading a lot of technical books. There are plenty of them on the market - related to craftsmanship, oriented fully around technology, patterns or methodologies and more. Besides practicing in your spare time - reading is probably the most important way of learning new stuff.
I read a lot of books, what is even more important - my reading queue is growing faster than my reading abilities - and what I found after a while is that merely only a couple of them can be marked as a highly influential on my career. It is not only related to the frequency with which I am returning to it - there are some books which I find really valuable, but I have read it only once. So, what makes a book good?
Before we define that set of features, I would like to divert a bit - learning is hard.
This is true especially if you are doing it in isolation (this is directly related with reading a book - you can do it within a book club, but still - it can uncomfortable or not enjoyable for someone). There is a very important concept related to learning new skill, when you are selecting a task which is only just slightly more difficult than your regular task, but still doable - it is the sweet spot where you can learn in the most effective way by yourself (learning in group is fundamentally different).
What I have observed relates to that sweet spot - books which I grouped in my private the best of list are related to that concept and with a particular time when I read it. That is why this list is perfectly viable for me, and can be irritating for you - especially if we are on the different level of skill acquisition for the particular set of features, covered in the described publication.
Today I would like to start with a very interesting book, but at the first sight it looks just like a classic example of XYZ for dummies guidebook. Such omission can result that you can miss a very good publication.
Seven Languages in Seven Weeks
Why this book?
We live in interesting times - software is eating world, now even more than in the 2011. Being a software engineer means that you have to solve various business problems. The more advanced topics you grab, the more complex problems appear. Up to some point, using a well-known hammer is a very pragmatic and good choice.
But someday you will hit a wall. You will see that it is not enough to know just one technology or one programming language well in order to solve these problems. This is especially true when you are building a distributed system, which should handle significant traffic and at the same time solve a complicated business case. In such environment you need to adapt - improve your skills by continuous learning.
There is another term, highly connected with the aforementioned concept, called polyglot programming (coined by Neal Ford). It does not mean that you should put every single language into your project, but rather that you should try to enhance your perspective, skills, try to think in a different way, build and interact with completely new ideas. That experience will influence your existing capabilities, it will create new pathways inside your brain and it may open your senses to the new patterns. Obviously, it requires curiosity, small dose of courage and humility (because nobody likes to feel stupid and this is inevitable at the beginning).
I found this book (polish edition) in the middle of 2012. At that time I was mostly a web and front-end developer (only JavaScript) with significant .NET experience and some smaller Python and Node.js episodes. I have tried both flavors, back-end and front-end, and only this kind of partition in the IT world had a significant meaning for me before. But the transition had already started - I heard about functional programming, I started looking for different experiences - I have just discovered Erlang and started getting familiar with it, I worked for a while with Scala because of Coursera’s course guided by Martin Odersky. At the studies I worked twice with Prolog and that’s it - I have seen every non-obvious technology as impractical and not worth looking at. Being a clean coder in the enterprise was the thing back then. At least I have seen it as a fully professional requirement. But it changed when I have started reading this book - it just literally sucked me in.
At first, it was not a pleasant ride. As a huge fan of JavaScript, I felt insecure and wronged because of choosing different prototype-based language as a representative of this group. But suddenly, when I finished the first 3 chapters, a really strange thing happened - I just realized how narrow my mindset was, how ineffective is to use single tool to the every problem that you try to solve. There are plenty of problems from very interesting domains that can be relatively easily solved (in comparison to my favorite well-known language) just by choosing a screwdriver instead a hammer again. I have soaked myself completely in polyglot programming movement and after a while I have seen the first effects.
Thanks to the different perspective, I started to think in categories that were previously fixed, sometimes even not considered as a point for change or improvement. I have understood the theory underneath many patterns and behaviors that I previously subconsciously used or implemented (e.g. I have used early versions of RxJS just because it was convenient - already built, packaged and well-tested). This book definitely changed my approach to the programming languages and I can honestly say, without exaggeration, that thanks to this book I started treating programming language as a tool, instead of treating it as a dogma.
If you are aware of that simple fact, that your life is oriented around 1-2 programming languages, within only one programming paradigm (e.g. OOP), I strongly recommend to buy this book and read it. You most likely will not write your next back-end system in Haskell, you will not use Prolog inside your application, but your mindset will change.
I would say that the only drawback of this book is the incomprehensible explanation of monads (yes, there are the m-words there). Besides that, this book is really well-written, it contains nice set of homework assignments and for me was an eye-opening book, which significantly enhanced my toolbox.
What’s next?
Obviously the aforementioned book cannot be described in just one blog post, so I would like to announce a follow-up post series, which will start immediately after this one. There I will discuss each language presented in that publication separately.
Regarding this series, next books are ready, waiting in the pipeline and I would like to share them with you. The next one is a must-read for every programmer, but in a different way that you might initially think. If you have an idea which one I am talking about, please post the title in the comment below. Regardless of whether you know - stay tuned!