A strong foundation in context engineering is a key skill for agentic development.
Context Engineering Fundamentals: Learn Prompt Design, Context Memory, and Agent-Based AI with LangChain, RAG, and MCP for Next-Gen LLM Applications
by James Acklin focuses mainly on building LLM applications.
It covers prompt design, context and memory, RAG, MCP, agent patterns, and application architecture.
The book includes lots of exercises and code samples, mostly using LangChain,
which illustrate the concepts very well and help you understand how things actually work.
Even though this is not a book about coding agents directly, many of the concepts transfer.
For coding agents to be productive, they need the right context at the right time -
focusing on relevant information while ignoring what is not needed.
Understanding the fundamentals of context engineering helps a lot when thinking about how to provide that context.
The book also goes beyond managing the context window.
It explains how complete LLM applications are built and how the different pieces work together.
It finishes with a few case studies that put those concepts into practice.
Even if you are not planning to build an LLM application yourself, I found this part interesting.
It gives you a better idea of how LLMs can be embedded into real applications
and also a better understanding of how tools like GitHub Copilot work behind the scenes.
So, while this is not a practical guide for coding agents, I think it is well worth reading if you want to build a solid foundation in context engineering
and become better at working with agents.
If you are looking for a career in a larger software company beyond the traditional management track -
meaning: without moving into people management - then this book can be a useful guide.
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.
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.
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.
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.
