Context

Reading was always incredibly important for me. It’s a great source of knowledge and inspirations. That’s why I decided to write down the books that pushed me forward as a Software Engineer with short description why do I think that they are valuable. I hope that this list will regularly grow and other people will be able to make use of it.

I’ve also decided to maintain reading queue so whenever something catches my eye I can prioritize it.

Currently reading

Observability Engineering: Achieving Production Excellence

Reading Queue

• Building Microservices: Designing Fine-Grained Systems

  Friend of mine recommended me this one. Because thanks to the same guy I readed Implementing Domain Driven Design which was super good - I know that this one won’t fail me 😁

• MongoDB: The Definitive Guide: Powerful and Scalable Data Storage

  Sometimes I regret during my daily work that I don’t know enough about MongoDb internals and how I could do some things better. Seeing that we have some work related to db optimization in next quarter it seems to be a good choice.

• Software Engineering at Google: Lessons Learned from Programming Over Time

  Heard a lot of good things about this one. I don’t have big expectations from it but maybe something will be enlighting ;)

• Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures

  This one just caught my eye when going through Kindle store.

Valuable Books I Have Read Before 2024

Assertiveness Training: How to Stand Up for Yourself, Boost Your Confidence, and Improve Assertive Communication Skills

What an eye opener! It’s not a tech book, but I think that good software engineer has to be assertive. I think that it deserves a bit longer explanation, that’s why the post “Assertiveness. The missing puzzle.” has been created.

A Philosophy of Software Design, 2nd Edition

This is a book about software complexity. Author explains why code becomes so complex after some time and gives lot of tips how to avoid this complexity. I liked especially how he used the terms of tactical and strategic programming, concept of shallow vs. deep classes and how he emphasised that software becomes complex incrementally so even bad naming of variables can lead to bugs in complex code base.

I found there also some controversional opinions like:

some things are impossible to be documented only in code and programmers are just looking for excuses not to write them

or

TDD hurts design and it should be used only in very specific cases.

It’s not that I heared those opinions for the first time, but I loved how author presented them. There was always a reference to opposite opinion (Uncle Bob in the first case) and why author disagree with that and also section Taking it too far, where he was showing how idea he was presenting could be overused (like too many comments in code).

Author also emphasizes that caring about design slows down at the beginning, but he promises that when you do it right later on you spend much less time chasing bugs and you can design even more things. I think he’s right.

Valuable Tech Books I Have Read Before 2023

Java Head First

The first book on programming I’ve ever read. It was already pretty outdated when I was reading that but I can still remember the author’s enthusiasm. And also it explains the basics of OOP pretty well. He was giving a lot of tips not only about Java but how to keep learning and not to get crazy - enouraging to learn before sleep so mind has more time to absorb the knowledge and many more. It was a great way to kick off my journey with programming and I can recommend this to anyone who is just starting.

Clean Code

It was the book that my cousin (who was already working as a software engineer back then) gave me as a gift and said that he wished he read it earlier. I must admit that it was a wonderful idea. I started to have some clues how to recognize bad code from the good one and some vision how to change the first one to another. I can’t say that I started to create awesome software right away - but at least I had this concious that you can always do better. Many tips may seem trivial like using descriptive names for variables and methods - however for the CS student, who used to go through walls of totally unreadable code written in C - it was shock!

As an addition it’s worth to see this article . I love the attitude of the author. If everyone is saying that the book is great - it’s super good to have an opposite voice. Some inaccuracies in the book are pointed and by diving in this article one can understand the subject of clean code even more.

Pragmatic Programmer

This one is an eye-opener! Andrew Hunt and David Thomas share their experiences about software engineering career - they cover so many various topics, that it’s hard to touch all of them in this short description, however what I remembered the most was that I knew about some threats of this job. That it is my responsibility (software engineer) not to stay overtime. That if I say to business, that feature will be ready till the end they really acknowledge that. And that it’s super easy to loose trust between software engineering team and business and then things get nasty. I remember also their brilliant stories about programming cowboys who mindlessly tried to push the project forward but instead were sabotaging these projects (working overtime, sleeping in a car to be faster in the job, coding many, many hours to just get things done without planning it, etc.).

I’m glad that I encountered this position pretty early in my career.

Desigining Event Driven Systems

Jakub Nabrdalik’s awesome talk about microservies encouraged me to reading this book. Event driven systems were totally unknown for me and this idea have literally blown my mind. Back then I was working on something reminding distributed monolith - no clear bounded contexts defined, pretty random splitting between services and synchronous calls everywhere. I was looking for some ways not to fight with the same problems again and again and when I saw this I knew that this is something I was really missing in my toolbox. It pushed me to look around for possibility of working with event-drived system and this book was super introduction what problems this approach solve and what problems it introduces.

Software Craftsmanship

This one gave me totally different point view on our profession and on my own carrer. What impressed me the most was the attitude of Sandro Mancuso - he encourages to take responsibility for your own career and for the software you create. It showed me that being a software engineer is not only about writing a code - it’s about communicating well, about solving problems, about partnership with the client. Sometimes, to make the best for your client you need to say no. If the patient goes to the doctor and says, that the doctor should cut his hand because the hand hurts him - what the doctor does? Of course he says no! And we as a software engineers should have such ethics as well - don’t mess the project only because client wants that. Just have enough courage to say “no - it does not make any sense!”.

Designing Data Intensive Applications

Not only incredible source of the knowledge about problems you can encounter when moving to distributed computing world but also great explanations of many fundamental ideas in software engineering - how data is stored in different databases, how indices work, how clocks in machines work… Many solutions propose for typical problems - when to use what tool, when to use synchronous communication and when to use asynchronouse one. I was so impressed how deep author went in many problems. Moreover, even the subjects he was explaining are pretty tough to grasp, he was able to express these ideas with great passion and made them really easy to understand. Must have to anyone who wants to work with data intensive (distributed) applications.

Effective Kotlin

Great addition to Kotlin official documentation . It really shows the practices that are used commonly by Kotlin developers, lists a lot of good practices and explain the reasons behind them. Must have to anyone who plans to use Kotlin language.

Apprenticeship Patterns: Guidance for the Aspiring Software Crafstman

Apprenticeship?! It was the first thought when I saw the title. When I started reading it, my title was saying “Software Engineer”. Can you hear that? Yup - that’s pride. This book showed me, that it’s no sense. If you want to grow you need to be able to wear white belt and learn new things. It’s worthy to be able to expose your ignorance, show that you are not the smartest person on the planet and just learn from others and grow. Sometimes, on your way you may unlearn something to learn something else. Place in your toolbox is rather limited and let’s be honest with yourself - does the fact that you were good at Scala one year ago makes you still good at Scala? This book really forces you to be honest with yourself and show many patterns how can you grow and become better over time.

By the way - this book was the trigger for me to start this blog.

Implementing Domain-Driven Design

Everyone is talking about DDD, right? Probably there is a reason behind that. I had a single attempt with famous blue book written by Eric Evans… and you can guess how did it end. Then I started woking in Allegro and one of my teammate - Radek - was dead serious about DDD. He noticed, that we don’t have the same understanding of DDD, so he organized Domain Driven Design Discussion Club (DDDDC in short - we were never able to pronunciate it anyway). On those meetings we were talking about different parts of DDD. Seeing how huge his knowledge was on this topic I just asked him how does he know all of that. He recommended this book and I was not disappointed. I was able to catch up the ideas of DDD. Vaughn Vernon did a great job explaining hard concepts in super easy way on the domain that is familiar to every modern software engineer - software for managing sprints (something like JIRA).

Refactoring: Improving the Design of Existing Code

I liked only a beginning of this book. It remainds why we do refactoring in the first place. Refactoring is a tool to speed up things - not to make code more beautiful. If you are creating solution that will be used only once or it’s just a prototype - maybe it doesn’t make sense to care so much. Another thing is that refactoring makes biggest sense when it’s done continously. Separate task for refactoring? It won’t happen. It should be counted into normal work of us - developers and we are resposnsible for quality of our work. So if after few months of creating system you go to the business and cry that new features are impossible to add because code is a crap and you need to do refactor… well - it’s most probably your fault.

Rest of the book talks about different refactorings (extracting methods, constants, variables, making classes to have one responsibility etc.) - nothing fancy, usual refactorings - most of them can be done with few keystrokes in modern IDEs.