Coder Legion - Recent posts tagged bookreview

SHELL Method

Mon, 23 Feb 2026 09:03:21 +0000

I’m excited to share that Shell Method is now officially available.

This project has been years in the making.

Shell Method is a practical framework designed for solo creators, indie developers, and builders who want to actually finish what they start.

It focuses on:

Reducing start resistance
Building consistency without burnout
Managing energy instead of just time
Structuring projects in a way that makes shipping realistic

Everything inside comes from real-world experience - building games, writing books, and working on long-term projects alongside a full-time job.

This isn’t theory. Based on my over 26 years of experience working solo and in teams. It’s a field-tested approach shaped by trial, failure, iteration, and delivery.

If you're building something on your own and struggling with momentum or consistency, I hope this helps.

Why Programs Fail A Guide to Systematic Debugging by Andreas Zeller-A Book Review

Wed, 21 Jan 2026 20:25:39 +0000

Introduction
A while back, I was given a list of books to read in order to become a world class software engineer. I have done previous reviews here. One of these books is Why Programs Fail A Guide to Systematic Debugging by Andreas Zeller.

As experienced engineers may know debugging is an important aspect of our jobs. In complex codebases, this may form the majority of our work. Unfortunately, it isn't something that is usually taught in degrees and bootcamps and we must learn it through practical experience whilst on the job.

This book helps to ease our task by introducing us to techniques used in debugging. The book is divided into 15 chapters. Each chapter is divided into 5 sections.

The first section discusses the title of the chapter in detail, the second the core concepts that software engineers should take, the third the tools to use, the fourth points to what we can also read and the final is a number of exercises to do.

How Do Bugs Arise?
In my experience, bugs are usually caused by incorrect assumptions about the code. Due to programmers being under tight deadlines, bugs are usually discovered by end users. They can usually be very costly. The author discusses this briefly at the end of chapter 1.

The first chapter discusses how failures in software arise. The author thinks it takes place in 3 stages:
i) The programmer creates a defect in the programming code.
ii) The defect causes an infection in the programming state
iii) The infection causes a failure-an externally observable failure.

The author lists a series of steps with the acronym TRAFFIC to debug a program.
i) Track: Create a problem in the programming database. In the second chapter, the author discusses how to keep track of the problems.
ii) Reproduce: Reproduce the failure.This is discussed in chapter 4.
iii) Automate: Automate and simplify the test case.
iv) Find Origins: Follow back the dependencies from the failure to possible infection origins.
v) Focus
vi) Isolate: Use the scientific method (see Chapter 6) to isolate the origin of the infection. Continue isolating origins transitively until you have an infection chain from defect to failure.
vii) Correct: Remove the defect and verify the success of your fix.

How to fix bugs?
As experienced developers know, there can be a number of issues that may arise when fixing a bug. First, we need to know whether the issue is truly fixed. To do this we may a correct understanding of the problem (the problem database mentioned above). Secondly, we need to also ensure that the fix doesn't cause any more problems.

My approach to debugging which has been gathered from working on different codebases over the years is to understand the problem, read the codebase, understand the workflow using logging statements, make the fix and adapt so that nothing else is broken, verify that the fix works using unit and integration testing and verify that nothing else has been broken running previous unit and integration tests.

Whilst this does work, it can be time consuming. The author makes a series of recommendations throughout the book that involves both tools and techniques to make the process more efficient.

The tools he suggests are debuggers and one of the techniques is an adaptation of the scientific method in a process known as scientific debugging.
The steps in this method are
i) Observe a failure.
ii) Invent a hypothesis as to the failure cause that is consistent with the observations.
iii)Use the hypothesis to make predictions.
iv)Test the hypothesis by experiments and further observations.
v) Repeat steps 3 and 4 until the hypothesis can no longer be refined.

Applying the scientific debugging should help the programmer to find the issue. The author spends a number of chapters discussing in detail how to do so. Once this is done, we must fix the problem. The author discusses in chapter 15.

As I mentioned above, we need to verify the fix resolves the problem and that it doesn't cause new problems. Other books discuss how to do this. Experienced engineers should recognize that testing will help with both.

Conclusion
This is a valuable, practical book. It is well organized and the summaries at the end of each chapter make it easy for programmers to refer to if they should forget or to get summaries of the main deductions. I recommend this book for all software engineers from novices to seniors.

A Book Review of Working Effectively With Legacy Code by Michael Feathers

Wed, 07 Jan 2026 15:52:25 +0000

Introduction

A large part of software engineering involves not only designing and creating new programs, but also working with existing codebases. Due to a number of reasons, we may need to make changes to the codebase.
There are codebases where changes lead to an increasing number of problems. This is often referred to as legacy code, which the author defines as codebases without tests. The book Working Effectively With Legacy Code discusses how to work with such codebases.

The Problem

Changes in the system can lead to a disruption in the existing functionality of the system. Why then do we need to make changes to the existing system? The book gives 4 reasons.
1.Adding a feature
2.Fixing a bug
3.Improving the design
4.Optimizing resource usage

The challenge when making these changes is to preserve the existing functionality of the system. Preserving the behavior involves some risk. This is because the codebase may have a lot of entanglements and the code to be changed may have some dependencies. Thus changes may result in unwanted changes.

According to the book to mitigate risk, we have to ask 3 questions.

What changes do we have to make?
How will we know that we've done them correctly?
How will we know that we haven't broken anything?
Writing tests can help us with the process of mitigating risks as we know what works.

Solution
To solve the problem described above, the author suggests a legacy code change algorithm of 5 steps. These are:

1.Identify change points
2.Identify test points
3.Break dependencies
4.Write tests
5.Make changes and refactor

The rest of the book contains lots of details on how to execute the steps above.

Conclusion
In a nutshell, the way to deal with legacy codebases is to introduce tests that allow us to understand how the system works,to map out dependencies and where possible break them.The book has lots of details on doing this.
This is a useful and practical book that discusses how to deal with legacy codebases that are too often prevalent in the real world. I recommend this book for experienced and advanced engineers.
The advice given can be useful regardless of the programming languages used.

A Book Review of A Philosophy of Software Design-how to create software that is easy to maintain

Wed, 19 Nov 2025 18:32:05 +0000

Introduction

A while back I was given a list of books to read in order to become a world class software engineer.One of these books was A Philosophy of Software Design by John Ousterhout. As the title implies, this book describes a way to design software. I would add how to design software that is easy to maintain.

As experienced engineers know, software engineering isn't just about creating software. User requirements may change in the future and new features may need to be added,bugs may be discovered in the existing functionality or changes in the existing codebase to make the code more efficient may be needed.

However, changing the existing codebase to incorporate these changes may interrupt existing functionality. This usually occurs because the code written was complex in the first place.

Complexity

The book describes two reasons for complexity:dependencies and obscurity. Dependency arises when one piece of code can't be changed without affecting others.Obscurity happens when important information isnt obvious.

The author also describes 3 symptoms of complexity.

1.Change Amplifications
A simple modification requires a lot of changes due to the fact that there are a lot of dependencies.

2.Cognitive Load
The developer needs to understand a lot of the codebase to make it easy to understand.

3.Unknown unknowns
It isn't obvious what pieces of code must be modified to complete a task or what information a developer must have to carry out the task successfully.In the author's opinion,this is the worst of the 3.

The author's proposed solution to eliminate or reduce code complexity is to make the code obvious. The book lists a number of ways that this can be done.

Programming Mindset

Software engineers are often in a rush to meet tight deadlines. As a result, they focus on writing code which works without thinking about the future. The author labels this as tactical programming and advises against it as due to its short sighted nature,it can lead to increases in the complexity of the code.

Instead the author recommends thinking with a strategic programming mindset. Here, developers must try not to introduce unnecessary complexity in the system. The focus must be on improving the design of the system where possible thus making it easier for other programmers to work in the future.

Modular Design

A technique the author recommends to reduce complexity is to use modules.This ensures that developers face a fraction of the system's overall completixy.The author advises to use deep modules-systems with a simple interface but a lot of complexity and advises against shallow modules-systems with a complex interface.

Information Hiding and Leakage

One way of creating deep modules is to use a technique known as information hiding. It involves providing other modules and users with a simple interface whilst hiding the implementation. People familiar with object oriented programming may know this as encapsulation.

In contrast, the author recommends against information leakage. This involves sharing of critical design information in multiple modules.This is a violation of the Dont Repeat Yourself principle of software engineering.

General purpose vs Special purpose Modules

Another approach the author proposes to reduce complexity is to use modules that are somewhat general purpose rather than special purpose. The former modules can cover a lot of use cases whilst the latter covers special cases. The difficulty is of course knowing what problems a module may solve today versus tomorrow.

Exception Handling

The author gives some advice that is controversial which is to define errors out of existence. This is because exceptions and errors may increase the code needed to deal with them and thus their complexity. However, this may not be always practical. I would say to minimize the errors you are dealing with where necessary.

Comments

The author makes another recommendation that is controversial. For those of us familiar with the book Clean Code by Uncle Bob, we were advised there to avoid comments where unnecessary. The author takes the opposite approach and recommends using comments as part of the system's design. We should start with comments.

He gives the reasons people give for not using comments and a reply as to why you should. He does raise some valid points. My recommendation having read both schools of thought is to use comments to explain design decisions and where the code may not be obvious. This should decrease the cognitive load.

Usage of Proper Names in Variables

The author recommends the use of variable names that are easy to understand, consistent and that create the right image in the minds of developers. This is one of the clean code guidelines recommended by Uncle Bob.

Consistency

The author recommends the use of consistency in naming, coding styles, interfaces, design patterns and invariants. This should reduce the cognitive load on developers. Those of us familiar with working on complex codebases will appreciate how much consistency helps.

Code Optimization

As experienced engineers know, the speed and memory usage of software is important when designing and implementing software. The author agrees but he does not think that this should come at the expense of increased code complexity.

Conclusion

The book argues that software design is an important part of the software engineering process. Designs where the code is obvious will make future work on that codebase easier. In contrast, code that is complex increases future work and makes bugs likelier.

This is something I agree with. Some of the recommendations are a bit controversial. You should look at the pros and cons of the error handling and comments advice before deciding.

The ideas put forward in this book are clear and practical. The book is short along with the chapters. In conclusion, I recommend this book for all software engineers.Which of Ousterhout’s design principles do you think is hardest to apply in your codebase, and why?

Designing Data-Intensive Applications [Book Review]

Wed, 05 Nov 2025 16:20:50 +0000

Introduction

Most backend developers eventually reach a point where they realize: learning another framework won’t meaningfully move them up to senior level. You can know Spring, Quarkus, Node, Nest, Django, whatever – and still not actually understand the deeper architectural forces that make large scale systems reliable.

That’s where “Designing Data-Intensive Applications” (DDIA) hits like a hammer.

This book doesn’t care about trends or hype. It forces you to understand the realities behind storage engines, distributed systems, data pipelines, fault tolerance, replication, consistency, and durability. And when you get this – you start thinking like a system designer, not just a code implementer.

This is a review, but also a recommendation: if you want to level up from mid-level to senior backend, this book should be on your “mandatory” list.

Why I read this Book

I follow many software engineers on LinkedIn and Twitter. One of them gave a list of books that I would need to become a world class engineer. This book was on that list. As the title suggests this book is about designing applications that process huge amounts of data-possibly limitless.

The single biggest value of the book

DDIA teaches you that modern backend engineering is less about functions and classes… and more about data flow and correctness across failure conditions. It is about building systems that can be reliable under any conditions, that are maintainable and easy to change and that can handle large amounts of data easily.
Most production systems are not CPU-bound.

They are data-bound.

Data movement.
Data reliability.
Data transformations.
Data structure evolution over time.

This book explains how real world systems survive reality: partial failures, retries, network partitions, schema drift, state synchronization, and replayability.

It gives you the mental model to see why large systems behave the way they do.

Topics Covered

The book is divided into 3 parts. Part I is titled Foundations of Data Systems. It is composed of 4 chapters. Chapter 1 introduces the concepts of reliability, scalability and maintainability. Chapter 2 discusses data models and compares relational and non relational databases. Chapter 3 discusses briefly the internals of databases. Chapter 4 discusses encoding data.
Part II is titled Distributed data and is divided into 5 chapters. Chapter 5 discusses Replication of databases across distributed systems and the issues involved. Chapter 6 discusses partitioning databases across distributed systems and the problems involved. Chapter 7 discusses the concept of transactions in databases. Chapter 8 discusses the problems encountered with distributed systems and chapter 9 discusses consistency and consensus.
Part III is titled Derived Data is divided into 3 chapters. Chapter 10 discusses batch processing, Chapter 11 discusses stream processing and Chapter 12 discusses the future of data systems.

5 concepts from DDIA that permanently improved how I think

1.Immutable logs create sanity and replayability.
Append-only logs aren’t just a Kafka pattern – they are a way to make systems auditable, recoverable, and debuggable.

2.Consistency is not binary.
There isn’t just “strong vs eventual”. There are reliability tradeoffs you choose. Most developers never consciously choose their consistency model. Seniors do.

3.Protocols matter more than frameworks.
When systems break across nodes or services, the protocol is what saves you. APIs are not just endpoints. They are agreements. Durable ones.

4.Batch vs stream is a philosophical divide.
Batch is a snapshot of the past. Streaming is the present unfolding in motion. Great systems often use both.

5.Schema evolution is a design problem, not an afterthought.
If you design your data structures to evolve safely… you avoid entire categories of distributed bugs.

You can take any one of these ideas and elevate your code review intuition immediately.

DDIA changes how you study and practice engineering

.This book indirectly forces a career mindset shift:

.Senior dev interviews? They’re testing these concepts.

.Architecture discussions at real companies? They’re anchored in these tradeoffs.

Debugging production outages? Almost always related to assumptions this book teaches you how to avoid.

It moves you away from “coding tasks” and into “system outcomes”.

That is literally the identity shift between mid-level and senior.

Who should read this book?

*mid-level backend devs who want to do proper system design

*people preparing for senior interviews or staff level interviews

*anyone going into infrastructure, distributed systems, or data engineering

future AppSec engineers (yes, security without understanding distributed systems is incomplete)

You don’t need to read it in one shot. This is a book you study over months and revisit repeatedly.

Final thoughts

“Designing Data-Intensive Applications” is not a coding book. It’s a “how the real world actually works” book.

If you want a single resource to help you break out of “framework-level thinking” and start thinking as a distributed systems engineer – this is it.

This book is where backend engineering grows up.

Book review: Writing for Developers

Thu, 29 May 2025 07:18:24 +0000

Disclaimer: This post includes affiliate links; I may receive compensation if you purchase the book from the different links provided in this post.

This review is about Writing for Developers by Piotr Sarna and Cynthia Dunlop from Manning.

I started my blog as a hobby seventeen years ago, in April 2008. At the time, I had no clue about technical writing. I'm pretty sure it was not even a thing back then: the only content aimed at developers was technical documentation. Since then, the landscape has changed a lot, to the point that companies hire for technical writer positions.

I was curious to compare what I learned by doing to the structured approach of a book. I ordered the book last year when it was still being written. It was published only early this year, and I was already reading (and reviewing!) DuckDB in action. I put it on the top of my reading pile list; I finally finished it: here's my review.

Facts

17 chapters, divided into four parts
2 appendices
345 pages
$39.99 (eBook)

Chapters

Part 1 - Fundamentals

Why write
What to write
Captivating readers

Part 2 - Nailing the writing process

Creating your working draft
Optimizing your draft
Getting feedback
Ship it

Part 3 - Applying the blog post pattern

The "Bug Hunt" pattern
The "Rewrote It in X" pattern
The "How We Built It" pattern
The "Lessons Learned" pattern
The "Thoughts on Trends" pattern
The "Non-markety Product Perspectives" pattern
The "Benchmarks and Test Results" pattern

Part 4 - Promotion, adaptation, and expansion

Getting attention
From blog post to conference talk
So you want to write a book

Pros and cons

In the first chapter, the authors list the most common reasons developers mention not to write posts. I have heard many of these reasons and can confirm their existence. Then, the authors address each of them and provide multiple counter-arguments.
Part three is dedicated to blog post patterns; each chapter describes a pattern in detail. Reading this made me realize that most blog posts fall into a specific and easily identifiable category. The authors structured each pattern-chapter into the following sections:
- Purpose: what's the idea (or ideas) behind the pattern
- Audience: who does the pattern target
- Examples: a couple of existing blog posts that embody the pattern
- Characteristics: common traits found among the posts of this type
- Dos and don'ts
I do love typologies, and I found this breakdown very useful.
I found part four less relevant, especially since cross-posting has been part of my workflow for ages, and I reuse writing content for conference talks. If you never considered these options, you'll benefit from these chapters.
The only con I found is that the authors remind us that you should ask your company before you reveal trade secrets. I understand that you would like to warn people, but when it's repeated several times throughout the book, I got the feeling they're writing to dummies–not something I'm fond of.

Summary

If you're a technical writer, a Developer Advocate tasked with technical writing, or a regular developer who wants to start a blog or contribute to a company blog, I recommend getting this book. The exhaustive description of common patterns is a huge asset for beginning writers and can help even seasoned ones.

Originally published at A Java Geek on May 25^th, 2025