10 Essential Books for Serious Software Engineers

This resonates. The identity piece is real — when someone has spent decades developing intuition for how systems fail and what "good" feels like, that's not just skill, it's who they are. Telling them AI handles the typing now doesn't land, because that was never really the point. What I'd add is that pattern recognition is about to become genuinely scarce. Out-of-school engineers coming up today won't accumulate the same scar tissue that comes with learning, updating, and fixing code bases in the hundreds of thousands and millions of lines that veterans of this craft have—the lived intuition is going to concentrate in a smaller and smaller group. Your most resistant engineers may also be your most strategically valuable. Let AI do what it's genuinely great at—generating boilerplate at speed, surfacing options, and holding the syntax so you don't have to. The veteran's job is to be the judge. To know which of those options is actually right, where the generated code will break at scale, and what the right abstraction really is. That judgment can't be prompted. It has to be earned.

In the world of software engineering, we often obsess over the latest frameworks, the cleanest syntax, or the fastest runtime. But after years of building complex systems, I’ve realized that the most powerful tool in a developer’s arsenal isn't a specific language, it’s analytical capacity. We often treat "soft skills" as something reserved for meetings and networking. However, there is a specific "soft skill" within the code itself: the ability to deconstruct a problem before a single line of text is written. Many people ask how my background in Philosophy relates to being a Full Stack Engineer. At first glance, they seem worlds apart. But in reality, Philosophy is the ultimate training ground for logic, ethics, and structured thought. Studying the great thinkers taught me how to: - Identify First Principles: Stripping a bug down to its core logical fallacy. - Deconstruct Arguments: Treating a failing function like a flawed syllogism. - Master Formal Logic: Understanding that code is simply the physical manifestation of an abstract logical structure. The most complex bugs aren't solved by trial and error, they are solved in the mind. By applying critical thinking and analytical rigor, I’ve found that I am significantly more productive. When you spend 30 minutes analyzing the "why" and the "how" of a system's architecture, you save 3 hours of aimless coding. Philosophy provided me with the mental frameworks to bridge the gap between abstract business requirements and concrete technical implementation. The takeaway? Don't just learn to code; learn to think. The better you understand the logic of the world, the better you will write the logic of your software. #fullstack #softwareengineer #philosophy #think #thinkandcode #planning

Three years ago, I wrote my first LinkedIn post about using GPT-3.5 for coding. Today, we have rolled out OpenCode to more than 200 developers. That alone shows how fast this space has moved: from “review every generated line carefully” to coding agents becoming part of real software delivery. But that is exactly where the hard questions begin. How do you use coding agents well as an architect? As an engineer? And how do you move from vibe coding to professional, governed software delivery? I wrote down my experiences and learnings in my book: ❕ The Agent-Native Architect I wrote it at a time when many software engineers and computer scientists are asking themselves a real question: ❔ What is my role when coding agents can suddenly do so much of the hands-on work? My answer is simple: strong engineers are still needed. But the role is changing fast from writing every line yourself to being the conductor, you need to evolve to an agent-native architect. Those who adapt can dramatically increase their impact. Those who do not will struggle, not because engineering matters less, but because the way we build software is changing right in front of us. This book is for people who want to understand that shift seriously: from software architects and senior developers to hands-on coders who started with vibe coding and now want to work at a truly professional level. It is about how to work with coding agents responsibly, how to design trustworthy repository and control-plane structures around them, and how to move from improvisation to governed, high-quality software delivery. The goal is to help engineers adapt to this new era with clarity, structure, and real architectural discipline. #AI #GenAI #SoftwareEngineering #SoftwareArchitecture #CodingAgents #AIEngineering #TechLeadership https://lnkd.in/dkpG3ceR

I've seen a few posts appear on my feed in the last couple of weeks claiming that we can stop worrying about good engineering practices and writing readable, maintainable test code. All because 'LLMs do not need it'. These thoughts frighten me. There's a lot of room for improvement in a significant portion of human-written test code, especially those parts that are publicly available on GitHub. Knowing that models are trained on this data, I think talking about and practicing good engineering practices and writing readable, maintainable test code has never been more important than it is now. If we don't, all we're doing is training future models on ever so slightly lower-quality data. To quantify the effects of this degradation of code quality, if the quality of your code base degrades by only a single percent every week (and at the speed with which many code bases change with LLM-assisted coding, I don't think that is a fictional number), next year, your overall code quality will be at less than 60% of where you are now. And new models will be trained on that lower-quality code, sending us into a downward spiral. Unless we're OK with the quality of our code slowly going down the drain in the name of 'acceleration', let's not stop talking about good engineering practices. In fact, let's spend more time talking about them and learn how to apply them. Doesn't matter if you're using LLMs to write your code or not.

I agree with the message below that we have to be careful with code that is produced by LLM's. They can be handy, but always double check and verify.

I’ve been seeing a take lately that honestly… should concern more people: “We don’t need readable, maintainable code anymore—LLMs don’t care.” That’s not a hot take. That’s a warning sign. Because LLMs don’t replace engineering discipline— they amplify whatever discipline (or lack of it) we bring. If your code is messy, unclear, and fragile… you’re not moving faster. You’re just accelerating entropy. And here’s the part people are missing: We’re not just writing code anymore. We’re training the systems that will write the next generation of code. So when we normalize lower-quality practices in the name of speed, we’re not saving time—we’re compounding technical debt into the future. Even small degradation adds up fast: Q(t)=Q0(1−r)tQ(t) = Q_0 (1 - r)^tQ(t)=Q0(1−r)t A 1% drop per week doesn’t leave you “slightly worse” in a year. It leaves you with something fundamentally degraded— and now your tools are learning from it. If waste is a bug, then unreadable, unmaintainable code is one of the most dangerous ones we ship. It just doesn’t fail immediately. LLMs don’t lower the bar for engineering. They make it visible who was already cutting corners. #SoftwareEngineering #CleanCode #TechLeadership #AI #LLMs #ResponsibleAI #Craftsmanship #ArchitectureMatters #WasteIsABug #BuildBetter

🚀 Code that works locally can still break in production. That’s one of the biggest lessons real-world development teaches you. Over time, debugging production issues has changed the way I think as a developer. It taught me that solving issues is not only about finding bugs — it’s also about understanding how real systems behave under real conditions. A few things this taught me: 🔹 Don’t assume — verify 🔹 Logs are often more useful than guesses 🔹 Small issues can come from unexpected places 🔹 Understanding data flow matters a lot 🔹 The faster you narrow the problem, the faster you solve it Working with logs, monitoring, and dashboards like Grafana made me realize that debugging is not just a coding skill — it’s also a systems-thinking skill. One thing I’ve learned clearly: 💡 A good developer is not someone who never faces production issues. It’s someone who can stay calm, investigate clearly, and solve them with confidence. Still learning this every day. 🚀 #SoftwareEngineering #Debugging #ProductionIssues #FullStackDeveloper #DevOps #BackendDevelopment #Grafana #LearningInPublic

SOLID Principles — Learn Once, Apply Everywhere (Real Dev Mindset) Most developers memorize SOLID. But the real edge? Using it while writing code under pressure (interviews + production). Let’s make it simple, practical, and unforgettable 🔹 S — Single Responsibility Principle “One class = One job” Example: OrderService → only handles order PaymentService → only handles payment Why it matters: Less bugs. Easier debugging. Cleaner code. 🔹 O — Open/Closed Principle “Don’t modify. Extend.” Example: Add new payment method → just create new class No breaking existing flow Why it matters: Safer deployments. Zero regression fear. 🔹 L — Liskov Substitution Principle “Replace without breaking” Example: All payment types return valid response (Success/Failure/Pending) No NotImplementedException surprises ❌ Why it matters: Prevents runtime failures in DI & microservices. 🔹 I — Interface Segregation Principle “Keep interfaces small & focused” Example: Split IPayment and IRefund Don’t overload one interface Why it matters: Cleaner implementations. Better maintainability. 🔹 D — Dependency Inversion Principle “Depend on abstraction, not concrete” Example: Use interfaces + Dependency Injection Swap DB / API / Logger without changing business logic Why it matters: Testable. Scalable. Flexible. How to ACTUALLY Learn SOLID Stop memorizing definitions ❌ Start asking these 5 questions while coding: ✔ Is this class doing too much? (S) ✔ Can I extend without modifying? (O) ✔ Will replacement break anything? (L) ✔ Is my interface too big? (I) ✔ Am I tightly coupled? (D) Real Impact (From Production Systems) ✔ Clean microservices architecture ✔ Faster feature delivery ✔ Fewer production bugs ✔ Easy onboarding for new developers Final Thought: Bad code works today. SOLID code survives tomorrow. #SOLID #CleanCode #SoftwareArchitecture #DotNet #BackendDevelopment #Microservices #InterviewPrep #Coding #Developer

There was a time when I thought becoming a better developer meant simply writing more code. But the deeper I went into software engineering, the more I realized that great programming is not just about syntax — it’s about discipline, design, habits, and mindset. Over time, five books reshaped the way I think about code. 📘 From Code Complete by Steve McConnell, I learned that: «“Good code is its own best documentation.” “Programming is a craft.” “Write the code as clearly as possible.”» These ideas taught me that coding is not about making things work — it’s about making them understandable. 📗 Then Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides showed me: «“Program to an interface, not an implementation.” “Favor object composition over class inheritance.” “Encapsulate what varies.”» This changed how I design software — from rigid code to flexible architecture. 📙 Effective Python by Brett Slatkin reminded me: «“Explicit is better than implicit.” “Know the difference between bytes and strings.” “Use comprehensions instead of map and filter.”» These lessons taught me that simplicity and clarity create powerful code. 📕 Clean Architecture by Robert C. Martin gave me a bigger vision: «“A good architecture allows major decisions to be deferred.” “The goal of software architecture is to minimize the human resources required.” “The database is merely an implementation detail.”» This made me realize architecture exists to serve maintainability, not complexity. 📒 And finally, The Pragmatic Programmer by Andrew Hunt and David Thomas changed my daily habits: «“Care about your craft.” “Don’t live with broken windows.” “Make it easy to reuse.”» That’s when I understood: great developers are built by consistent craftsmanship, not shortcuts. Every quote from these books points to the same truth: ➡️ Write clearly ➡️ Design wisely ➡️ Keep learning ➡️ Care about the craft Because in the end, software engineering is not just about building applications. It’s about building the mindset behind the applications. #SoftwareEngineering #Programming #CleanCode #DesignPatterns #Python #SoftwareArchitecture #ThePragmaticProgrammer #DeveloperMindset #CodingJourney #BackendDevelopment

Keen is now roughly 20k lines of Go code. Throughout the development of this project, I used several SOTA coding agents. They did all the heavy lifting. From the experience, my conclusion is that human review STILL matters—probably more than you think. A few behaviours I noticed worth mentioning: - Agents frequently over-engineer stuff where a simpler solution exists. It happened more often than I expected. I had to actively discard such over-engineered solutions. - Agents have a bias towards achieving goals ,  sometimes overlooking code quality and best practices. Due to the post-training (RLHF/RLVR), agents tend to push hard for getting things done. I frequently noticed that they would not refactor logic into separate functions, use magic values directly instead of setting them as configs or package level constants, extend existing packages or files instead of creating new ones where makes sense, and so on. There are, in fact, signs of such behaviour in Keen. - Agents are bad at deciding tradeoffs — so human judgement is critical. Tradeoffs are inevitable in software engineering. These are not always obvious even to humans. I have found relying on agents for such decisions is not a good idea. - LLMs have knowledge cutoff which may steer towards wrong directions. In fact, I once overlooked such a case where agent suggested older version of a core dependency simply because it was not trained on it. - Bad codebase leads to bad code generated by agents. They are trained to follow existing pattern of a codebase. Whenever a file or a package has lower quality of code, agents tend to amplify the issue. Perhaps, human in the loop matters less in multi-agent orchestration. For Keen, I didn't use such a framework.