Books that shaped me as a software engineer
Tags: books, architecture, programming, discuss
Published: 2024-02-22 15:21:25

For a while I had the idea to list books that I consider as those that shaped my understanding of an aspect of the software industry.
Note I don't say "programming", because part of the understanding is to see the place of programming, the process of conceiving and writing actual code, in the broader picture.
Some of the books will look trivial to many, but the point is  not what's more advanced - it's about what worked well along the way.

### 1. The C Programming Language - Brian Kernighan and Dennis Ritchie
While I ended up never writing a single line of commercial code in C, reading this book during high school defined the tactical part of my code thinking until these days. I did very basic development before, but it was - BASIC or Pascal (see what I did here with "basic"?). 
K&R showed me things that were simply impossible with my previous languages in terms of terseness of the code and the general wit of it. I actually did a chapter's exercises in order before proceeding to the next chapter - as instructed in the introduction. This way I could really follow the teaching.  
The wise progression of exercises also served as an inspirational guideline when teaching programming on various occasions.

### 2. Introduction to Algorithms - Thomas Cormen
This is not an easy read, but if you never saw an algorithm laid out formally, you have work to do, and this book will guide you. And if you saw some, there are always more to explore. It's too big to swallow in one go (in fact, it's a lifelong learning exercise), but going over at least some of it helps understand, evaluate and come up with new algorithms.
It might seem trivial that one would look at common algorithms as the fundamental topic to address early in the career. But to my surprise while interviewing a frontend dev with good references and about 3 years out of college, I asked him about the difference between breadth-first vs depth-first search, and he replied it sounds as something he heard of during the classes, but it was too long ago to remember details. He did a decent job which may sound as an approval for treating the subject as too abstract, but it's not. I firmly believe that given enough time and coffee anyone who does software engineering should be able to find their way out of a labyrinth with their eyes closed, in at least two different ways. A matter of survival.

### 3. UML Distilled - Martin Fowler
If you don't know Fowler maybe you should review your list of software engineering influencers. He is the modern incarnation of the whole Gang of Four in a single person (and if you are him I hope you are ok with the metaphore and I won't be expelled from the industry).
The book's title is completely misleading since he is using UML as the pretext for an efficient overview of the software / service lifecycle. He really tells you how to start thinking about a software project that doesn't yet exist. From idea to architecture on a napkin, through use cases, design patterns, iterations, testing, maintenance and even sunsetting.
Last but not least, he explains lean/agile/scrum, not as much the specific rituals as the mindset of choosing iterative action and accepting imperfection over excessive planning and analysis paralysis. It's also quite curious how over the years these ideas propagated from software into other areas.
You don't become an architect or a project manager immediately after reading this, but you get a boost in both directions, gain a better understanding of the context of your job, and know what to look at next - GoF.

### 4. Design Patterns - Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, a.k.a Gang of Four, a.k.a GoF
It is not really a book to enjoy as a fun light reading, nor do I believe anyone knows every pattern by heart or can always tell a facade from a proxy. But spending enough time with the book provides a perspective for recognizing higher-level abstractions that tend to repeat in seemingly different branches of software and across completely unrelated industries.
Like the Algorithms book it also provides value in terms of expressing and communicating these ideas and therefore ideas about software design/architecture in general.

### 5. JavaScript Alongee - Reginald Braithwaite
Instead of focusing on the good and bad parts of JavaScript, Braithwaite is focusing on its functional aspect. If you come from the whereabouts of C++/Java/C#, once you understand prototype-based inheritance you might think now you understand the language because you finally understand how to do all the things you learned about classes - in JavaScript. This book will deliver some news for you.
There is a lot of influence of functional thinking in today's JavaScript so maybe for some people it's obvious, but if you feel lost when you see second-order functions or React components, or, God save, combinators, consider this book and you will instantly become a better version of your developer self.
If you are not a complete beginner and will read just one book from this list pick this one.

### 6. The Little Lisper - Daniel P. Friedman, Matthias Felleisen
If you were to read JavaScript Alongee, you would want to check out The Little Lisper even just because Braithwaite drew inspiration from it and mentions this on multiple occasions. 
The Little Lisper is the oldest book in this list. It's a brilliant piece of literary and educational art. It will tempt you to run a few examples in Lisp (there's an app for that so you can write short lisp programs on your phone while bored on a plane or a picnic). It will take you further into the functional land. It's full of brain teasers and will tickle and talk to your inner child that long ago just wanted to play with computers and tech and dreamed of doing it for real. Someday.

Be warned: if you actually read enough of books 4 and 5 you will see Lisp jump out of JavaScript's C clothing and even bite you. Extremely susceptible individuals may feel the urge to always replace for loops with recursion. Resist the urge. There are reasons why functional libraries like lodash have for loops under the hood.

I'm sure everyone's mileage varies and was myself tempted to list more books, but they can be a topic for another post.

Which books did it for you and why?