Book Review: Radical Candor
30 Mar 2026If you want to become a better people manager –
or if you wish your manager would improve –
this is definitely a book worth looking at 😉

If you want to become a better people manager –
or if you wish your manager would improve –
this is definitely a book worth looking at 😉

When I was researching how to improve my problem-solving skills - which are an essential part of being a software engineer - I somehow came across this book. Of course the second part of the title immediately caught my attention.
At first I could not make much sense of the first part of the title, but I bought the book anyway. After reading the introduction it suddenly made perfect sense, because already there I learned:
In systems thinking, a system is more than just the sum of its parts.
A system is something that maintains its existence and functions as a whole through the interaction of its parts.
Your body is the perfect example. It consists of many different parts and organs, each acting separately yet all working together and each affecting the others.

The Art of Systems Thinking: Essential Skills for Creativity and Problem Solving
Software projects are almost always executed in teams.
When you work in a great team, it’s one of the most enjoyable aspects of the job. But when teams don’t function well, the amount of friction can be enormous.
A key factor behind great teams is great technical leadership.
Good tech leads are not only strong in technical topics. More importantly, they need leadership skills.
In that regard, military teams and software teams are not so different. Both operate under pressure, must coordinate complex work, and rely heavily on trust and clear communication.
If you want to understand what truly matters in leadership, this book is an excellent resource.
That’s why I picked this book, and if you are a tech lead - or want to become one - I highly recommend reading it.

Most of us see the huge advantage AI gives us - when used wisely.
We can use it as intelligent auto-completion, or ask it to implement entire features.
But to get good results, we need to engineer good prompts.
That’s why I picked up Prompt Engineering for LLMs. Here’s what I learned.

Prompt Engineering for LLMs: The Art and Science of Building Large Language Model-Based Applications
AI can get your project 70% done in minutes.
But what about the hard 30% - the part where real engineering begins?
Beyond Vibe Coding cuts through the hype and draws a sharp line between short-term velocity and sustainable AI-assisted engineering.
It explains why prompting is really about expressing intent, why fundamentals still matter, and how juniors, mid-levels, and seniors must adapt differently in the AI era.

Pull Requests (PRs) were invented for Open Source projects. They allow “untrusted contributors” to suggest changes and ask “trusted committers” to pull them in. Committers review these requests on their own schedule, leave comments, demand changes, or simply reject the “pull request” altogether. For this reason, PRs work extremely well in Open Source.
Work in commercial teams is fundamentally different. Team members collaborate long-term, share goals, and trust each other. Changes are not “suggested” but planned - it’s rarely a question of whether but how something gets done.
PRs were not made for this. They optimize for control and gatekeeping, while commercial teams optimize for flow and delivery speed without sacrificing quality.
Using pull requests for code changes by your own team members is like having your family members go through an airport security checkpoint to enter your home. It’s a costly solution to a different problem.
Kief Morris, Why your team doesn’t need to use pull requests
Even though it was written 50 years ago, if you’re a software engineer and haven’t read this book yet, put it on top of your reading stack. The Mythical Man-Month is one of those timeless engineering classics every developer should read at least once in their career.

Instead of imagining that our main task as programmers is to instruct a computer what to do, let us concentrate instead on explaining to human beings what we want a computer to do.
Donald Knuth

Code Is For Humans - A Guide To Human-Centric Software Engineering
I got caught by the title — and I’m glad I did.
The subtitle (“Trade-Offs in Distributed Architectures”) might scare off some folks who don’t work with distributed systems. That would be a mistake. This is one of the best books on software architecture I’ve read in the last 10 years.

Technical debt is a reality for every software developer. We all know some “dark corners” of our codebases - those problematic areas we dread touching. But some challenges are less obvious. This is where Software Design X-Rays by Adam Tornhill comes in.

Have you read “Clean Code” by Robert C. Martin? Then “A Philosophy of Software Design” by John Ousterhout should be next on your list. It shares the same goal—writing better, maintainable software—but sometimes takes a very different path to get there.

While VSCode and DotNet generally works on FreeBSD, the “C# Dev Kit” does not due to the following issue: FreeBSD build of C# Dev Kit
Knowing that FreeBSD jails support running an almost full features linux system and also X11 apps, I was curious whether it would be possible to run VSCode including “C# Dev Kit” in a jail.
Here is what I learned.
What is software craftsmanship?
Craftsmanship is the state of knowing, how to do something well and is the outcome of good tutelage and lots of experience.
– Robert C. Martin, Clean Craftsmanship

I’ve been interested in software architecture, particularly in Clean Architecture, for many years. I discovered this book a while ago and kept it on my reading list until recently, when I finally found the time to read “Get Your Hands Dirty on Clean Architecture” by Tom Hombergs.
