5 books I recommend to developers

I have some conversations with my colleges at work about what should we learning or what we are missing at what’s happening in the industry. Even though those conversations tend to be around specific technologies, I tend to focus on methodologies, practices, and best practices. I am more about why we do this way rather than how to do this in this technology. Those Book recommendations are for any developer, regardless of their moment in their own journey. Either you’re in the begging or you have been in the software industry for a while. The next books I read every one or two years, and I always learn something new from them. 💯% worth to read them. I share them in the order that I consider can impact the most your career and your developer experience inside a team. Some of them are just the starting point giving you a solid base, so then you can choose better where do you want to go deep in an area or not. Test-Driven Development by Example https://amzn.to/3rIgoYn TDD… it takes years to master if you can even master it. This Book, Test-Driven Development by Example contains everything you need to understand TDD. The only thing that you need to know is that you need to read it several times in your career. If you’re in the early beginning of your career path, I would suggest you: Read the book meanwhile practicing. Start easy. Become familiar with the methodology and the naming around the Testing practices like Mock, Stub, Assertions, ... Pair Program with another person that can guide you I heavy recommend being at work, but in case it’s not possible you can also attend a safe space to practice like the Software Crafters Community. They are everywhere in the world, mine is based in Barcelona for example :) Read the book again and you find that you understand a lot better what’s TDD and you will also find that some “difficulties” you had might be because of a bad interpretation of what’s TDD. We all have been there… If you’re not in the early beginning of your career, I would recommend you to make these questions to yourself: Am I applying TDD to only coding? Can I apply TDD to System Design? Can I apply TDD to Software Architecture? Can I apply TDD at User Story Level? Which is the difference between outside-in TDD and inside-out TDD? Which are their consequences? When to use one and the other? How TDD related to SOLID? TDD might start as a way to make the coding more robust… but that’s only the surface, it’s about short feedback loops, and it can be applied to literally everything. Accelerate: Building and Scaling High-Performing Technology Organizations https://amzn.to/3iU0hD6 Today, a must-read. Do you want to be in a high-performing team? This is the book. It shows based on scientific evidence why certain practices help teams to improve their performance. From technical practices and how to measure the outcomes by: Software Delivery Performance or 4 Key Metrics Lead Time Deployment Frequency Mean Time to Restore (MTTR) Change Fail Percentage If you know how to improve those metrics, you will be familiar with concepts like: Continuous Integration / Continuous Deployment Feature Flags DevOps Monitoring and Observability Testing Trunk Based Development On the management practices, it shows: Lean Management Limit Work in Progress (WIP) Visual Management Feedback from Production Lightweight Change Approvals and last by not least Lean Product Development Work in Small Batches Make Flow of Work Viable Gather and Implement Customer Feedback Team Experimentation The book summaries and explains the why of well-known practices in the industry that back then it was so hard to explain why they were effective. They show empirical evidence of why they work, and it can give you a good set of arguments to start implementing those practices at work. I would say that even it explains a lot of things, let’s start small and where you have more influence. Maybe you can start with a good CI system, and then move to CD system. The good thing is that on each step, you can measure how it affects the 4 Key Metrics and the team performance 😄 The five dysfunctions of a team a leadership fable https://amzn.to/3BQivOs Given a point in any career, you tend to see that, even you know the best practices, how to make things well, the best technologies… as a team… you s*ck, and you produce sh*t that you are not proud of. This is not about the individual but the team. I found in this book a super great way to understand why we don’t work well as a team, and how to build a team that works well together. To me, I would just recommend you to give it an opportunity. Sometimes, even when you have the best intentions, you need to work on the team relationships before even start a unit test. My experience says that dedicating time to create great relationships with your peers pays off in the medium-long run. The book will tell you about: Trust Accountability Commitment Conflict Secure by Design https://amzn.to/2THgVNO You might already hear about Clean Code, Domain-Driven Design, Hexagonal Architecture, Microservices, and blabla… This book contains more useful material to start than the others, it’s NOT about security but about designing the software in a secure way, in the DDD way. It explains concepts like: Immutability done right Failure handling Domain Modelling SOLID principles How to do great abstractions Reduce Code Duplicity Well defined service boundaries How to create consistent services Encapsulation Well defined interfaces If I had to recommend a book about Domain-Driven Design, I will start with this one. When you get the ideas of this book plus TDD, then your codebase starts becoming a lot more maintainable. When you master the concepts in this book, then you can explore patterns like CQRS and EventSourcing, because the basics you already got them and you will find that a good and well-defined model do not need CQRS and ES, and still you applied Domain-Driven Design concepts. When you finish reading this book, I would like to propose some questions to you: How this helps when designing a microservices architecture? How does these concepts apply instead of a class level but at service level? Why it reduces code duplicity between microservices? Why it creates more secure and stable services? Building Evolutionary Architectures: Support Constant Change https://amzn.to/3xb6OhI Building Evolutionary Architectures was a mental switch for me. I went from I want to make decisions about architecture to let’s postpone all the architectural decisions as much as possible until we have all the relevant information mindset. Before reading the book, I was eager to take architectural decisions because I felt that it was important. Wrooooooong. Damn, how wrong I was. This book helped me to understand WHEN and HOW to make architectural decisions, and why it was so much important to think about the architecture in a way to make it adaptable to our needs, our known needs instead of based on our believes about we might expect about the future. This book saved tons of money on rushed not well-informed decisions or driven by the ego. BTW, it related a lot with the TDD mindset 😄 Thanks for taking your time to read the post! Share with your friends if it was useful and don’t hesitate to give feedback! Meme for you