33 books force feed by my managers and directors
Activity is cheap and seductive. Results are hard and the only thing that counts.
- Outcomes over output — INSPIRED, Accelerate, The Goal, An Elegant Puzzle
- Flow / find the constraint — The Goal, Phoenix Project, Kanban, Team Topologies
- Feedback loops & cost-of-change — XP, TDD, Tidy First, Modern SW Eng, Accelerate
- Tests/safety as the license to change — Legacy Code, TDD, SWE@Google, Evolutionary Architectures
1. Value and Outcomes
why we build at all?
INSPIRED
by Marty Cagan
- You are not paid to ship features. You are paid to solve problems that produce outcomes. 1/2 of your ideas will fail no matter how smart you are.
- Stop falling in love with your roadmap and fall in love with the problem instead.
- Before any coding, prove the idea against four risks. Will they use it (value), can they figure it out (usability), can we build it (feasibility), does it work for the business (viability).
- Empowered teams handed a problem beat feature factories handed a spec, every single time.
- Output is cheap and seductive, outcomes are hard, and only outcomes matter.
The Goal
by Eliyahu Goldratt
- Every system exists for a single goal, and if you cannot name it, every “improvement” you make is a guess.
- A system’s output is capped entirely by its slowest constraint. Making any non-bottleneck faster does not speed up your team. It’s like a highway no-limit after a police check.
- Keeping everyone 100% busy is not efficiency. It is the most common way organizations quietly destroy themselves.
- Improve by focusing. Find the constraint, wring everything from it, subordinate everything else to it, then elevate it, and repeat forever.
- Local optimums lie. Only throughput against the goal tells the truth.
Accelerate
by Forsgren, Humble, and Kim
- Speed and stability are not a trade-off. The teams that deploy fastest are also the most reliable, and the data proves it.
- Four metrics predict not just engineering health but company profitability: deploy frequency, lead time, time-to-restore, and change-fail rate.
- “Work harder” is the management reflex that backfires. Pushing speed without fixing architecture and automation costs you stability.
- The leverage is in capabilities, not in effort or heroics. Loose coupling, trunk-based development, test automation, small batches.
- How you build is a measurable, improvable competitive advantage, not a cost center.
2. Process and Empiricism
how teams plan and run work
The Agile Manifesto
by Beck, Fowler, Cockburn, et al.
- Individuals and interactions over processes and tools, working software over documentation, customer collaboration over contracts, and responding to change over following a plan. when they clash the first half wins.
- Progress is measured in running software delivered early and often, not in artifacts that merely describe software.
- Welcoming change late in development is a competitive weapon, not a failure of planning.
- Trust motivated people, give them what they need, and get out of the way.
The Scrum Guide
by Schwaber and Sutherland
- Scrum is “purposefully incomplete.” It gives you a frame, not a recipe.
- It runs on empiricism: transparency, inspection, adaptation. So you decide from what you observe, not what you assumed.
- A small self-managing team cycling through sprints will out-learn any detailed up-front plan on a complex problem.
- Scrum does not fix your team. It makes your dysfunction visible so you can no longer ignore it.
- The framework is the easy part. The discipline to actually inspect and adapt is the whole game.
Essential Scrum
by Kenneth Rubin
- Product development is too uncertain to plan up front, so replace prediction with empirical control.
- The sprint is the engine: a short timebox that always produces a done, integrated, potentially-shippable increment.
- Real feedback comes only from something that works, never from a document describing what will work.
- There is no universal best practice to copy. Each team must close its own learning loops and find its own path.
- The plan is not what steers you. The feedback is.
Scrum: The Art of Doing Twice the Work in Half the Time
by Jeff Sutherland
- Detailed Gantt-chart plans are fantasy. You cannot know how fast a team goes until it actually starts.
- Keep teams tiny. Communication channels grow as n(n-1)/2 and the human brain holds only a few things at once.
- Relentlessly remove impediments, because every blocker is Toyota-style waste stealing your velocity.
- Do not blame people, fix the system they work in. The Fundamental Attribution Error is the manager’s trap.
- Done right, Scrum compounds. Teams genuinely do twice the work in half the time, not by working longer but smarter.
The Scrum Field Guide
by Mitch Lacey
- Scrum is simple, not easy. The hard part is unlearning the instinct everyone is raised on: plan everything up front, then go execute it.
- Run it by the book long enough to understand why each practice exists before you customize it.
- Marry Scrum to real engineering practice (TDD, CI, pairing) or you will sprint toward shippable software you cannot actually ship.
- Expect the messy first year, two steps forward and one back, and survive it instead of abandoning ship.
- Scrum surfaces buried dysfunction. The only question is whether you confront it or hide behind “custom Scrum.”
Agile Estimating and Planning
by Mike Cohn
- Estimate the size of work in relative points. Never guess dates directly.
- Derive the schedule by dividing size by velocity, and that division quietly self-corrects your estimation errors over time.
- A wrong first guess still converges on a true finish date, so you never need certainty up front.
- Planning is not a one-time act of prediction. It is plan-do-adapt, revised every iteration as you learn.
- Success is delivered value, not loyalty to a number you committed to before you knew anything.
Planning Extreme Programming
by Beck and Fowler
- We plan not to predict the future but to stay coordinated and always working on the single most important thing.
- A plan is a steering snapshot you will revise constantly, never a contract you defend.
- Split authority cleanly. The customer owns scope and priority, engineering owns estimates, and neither side gets to lie to itself.
- Every short iteration must end in a fully tested, production-ready system.
- This brutal honesty about who-owns-what is what prevents the slow-motion failures that up-front plans hide until it is too late.
User Stories Applied
by Mike Cohn
- Capture requirements as short user stories, not exhaustive “the system shall” specs that get skimmed and later weaponized for blame.
- A story is just a placeholder for a conversation: Card, Conversation, Confirmation. The details are deferred until you actually need them.
- Make every story INVEST: independent, negotiable, valuable, estimable, small, testable.
- The point is behavioral. Stop writing about requirements and start talking about them.
- Shared understanding lives in the conversation, not in the document.
Kanban
by David J. Anderson
- Do not impose a new process. Start exactly where you are and change as little as possible.
- Visualize the workflow, limit work-in-progress, manage flow, and make your policies explicit.
- Limiting WIP turns a push system into a pull system and exposes precisely where work jams.
- Because change is incremental and self-chosen, resistance evaporates and improvement becomes a continuous habit (kaizen).
- Evolution beats revolution. Small relentless improvement outlasts every big-bang transformation.
3. Engineering Discipline and Feedback
keeping change cheap
Extreme Programming Explained
by Kent Beck
- The cost of change does not have to rise over time. Push ordinary good practices to the extreme and you flatten the curve.
- Build tight, mutually reinforcing feedback loops: test-first, continuous integration, pairing, weekly iterations.
- Take baby steps so the system is always deployable and defects surface in hours, not months.
- XP is really social change. It asks you to be vulnerable, play full-out, and stop holding back the last 20%.
- Practices without values are hollow. Communication, simplicity, feedback, courage, and respect are the real engine.
Extreme Programming Installed
by Jeffries, Anderson, and Hendrickson
- There is no silver bullet. Just common-sense practices that, used together, let you deliver value continuously.
- A feature does not exist unless there is an automated test for it.
- Build the simplest thing that could possibly work, then refactor as the design reveals itself.
- Because the system stays integrated and tested at all times, change stops being dangerous.
- The customer steers in real time instead of betting everything on an up-front plan.
Test-Driven Development by Example
by Kent Beck
- The goal is clean code that works, reached by just two rules: write code only to pass a failing test, and remove all duplication.
- The rhythm is red-green-refactor. Fail, make it pass by any means, then clean up.
- Design emerges from running code feeding back into your next decision, instead of being guessed in advance.
- TDD is fundamentally a way of managing fear. Each passing test is a tooth in a ratchet that locks in progress.
- You will trust code you tested into existence far more after a year than the code you wrote starry-eyed at the start.
Refactoring: Ruby Edition
by Fields, Harvie, Fowler, and Beck
- Refactoring is changing a program’s internal structure without changing what it does, and you never refactor and add features at the same time (the two hats).
- Work in the smallest possible steps, running tests after each, so a bug is always seconds from being caught and one step from being undone.
- Code smells like duplication and long methods tell you where and when to act.
- Quality is a continuous team habit. Clean the patch of code you are about to touch, ideally in pairs.
- The three-month big-bang rewrite is a recipe for disaster. Nibble instead.
Tidy First?
by Kent Beck
- Do not clean messy code in one heroic refactor. Apply tiny tidyings that make the very next behavior change easier.
- Keep structure changes and behavior changes in separate commits, always.
- Coupling and cohesion, not aesthetics, are what actually drive the cost of software.
- “Tidy first vs. after vs. never” is an explicit economic bet, weighed by discounted cash flow and optionality, not by taste.
- Design becomes a minute-to-minute personal habit, so change stays cheap continuously instead of being deferred forever.
Working Effectively with Legacy Code
by Michael Feathers
- Legacy code is simply code without tests. No matter how clean, untested code is dangerous to touch.
- Without a test net you cannot even tell whether a change made the system better or worse.
- Find seams, places to alter behavior without editing in place, and break the dependencies that block testing.
- Pin down what the code actually does with characterization tests before you dare change it.
- Install the safety net incrementally around exactly what you are touching, and confidence grows with every edit instead of eroding.
Modern Software Engineering
by David Farley
- Software engineering is the application of an empirical, scientific approach to practical problems. A real discipline, not an art or a craft.
- It rests on two competencies: becoming experts at learning and experts at managing complexity.
- Learning means working iteratively and incrementally, with fast high-quality feedback, experimentally and empirically.
- Managing complexity means modularity, cohesion, separation of concerns, abstraction, and controlled coupling.
- Let either pillar slip and you get big balls of mud, runaway debt, and teams too afraid to change their own code.
4. Design and Complexity
structuring systems that survive
A Philosophy of Software Design
by John Ousterhout
- The entire job of design is fighting complexity, anything that makes a system hard to understand or modify.
- Complexity never arrives in one disaster. It accumulates from hundreds of tiny dependencies and obscurities until the codebase is a swamp.
- The master move is the deep module: a simple interface hiding a large, messy implementation.
- Be strategic, not tactical. Treat great design, not merely working code, as the goal.
- Tactical teams ship 10 to 20% faster at first and pay every bit of it back as complexity grinds future work to a crawl.
The Pragmatic Programmer
by Hunt and Thomas
- Your craft and your career are yours to own. Take responsibility, admit ignorance and error, and do not make lame excuses.
- Keep one authoritative source for every piece of knowledge. DRY is about duplicated intent, not just copied lines.
- Keep things orthogonal so changing one thing never ripples into unrelated things.
- When knowledge is not duplicated and components do not bleed into each other, fixes stay local and risk drops.
- That is what lets a codebase keep adapting instead of calcifying, and the same is true of you.
Domain-Driven Design
by Eric Evans
- Complex software succeeds only when its design is built around a model that deeply mirrors the business.
- The code itself must express that hard-won understanding, not a technical translation of it.
- Forge a ubiquitous language: one rigorous vocabulary used by experts and engineers everywhere, in conversation, tests, and code.
- No single model stays coherent at scale, so carve the system into explicit bounded contexts.
- Where you draw those boundaries is ultimately an organizational decision about who owns what.
Designing Data-Intensive Applications
by Martin Kleppmann
- No single database, queue, or tool serves every workload. Real systems are always stitched from specialized parts.
- Judge every design against three goals: reliability, scalability, and maintainability.
- Each tool earns its guarantees through specific internals, so understand them instead of trusting black boxes.
- There is no one right answer, only trade-offs appropriate to different circumstances.
- Treat one store as the system of record and derive everything else from it, designing for inevitable faults and change.
Building Evolutionary Architectures
by Ford, Parsons, and Kua
- Architecture is never “done.” A good one supports guided, incremental change across many dimensions at once.
- Make evolvability itself a first-class design goal, not something bolted on later.
- Encode what matters as fitness functions: automated tests that fail the build the moment the architecture degrades.
- This swaps slow, subjective governance (review boards) for continuous, machine-enforced feedback.
- Coupling is the real lever. Decoupled systems can change one part at a time, while a big ball of mud cannot evolve at all.
5. Delivery and Operability
shipping and running reliably
Grokking Continuous Delivery
by Christie Wilson
- A feature is not done when it is coded. It is done when it is released.
- Your software must be provably in a releasable state at all times.
- Model the pipeline as just two kinds of tasks: gates that verify code is safe to ship, and transformations that build and deploy it.
- Releasing then becomes a push-button routine instead of a rare, high-stakes ritual.
- “Always shippable” decouples from “how often you ship,” dissolving the dev/ops divide.
Site Reliability Engineering
by Beyer, Jones, Petoff, and Murphy (Google)
- Treat operations as a software problem and refuse to accept manual, repetitive toil as the cost of running a service.
- 100% reliability is the wrong target. An SLO defines exactly how unreliable a service is allowed to be.
- The leftover is your error budget: the objective currency that decides whether you ship features or freeze to fix stability.
- A shared number replaces politics, fear, and hope between product and ops.
- Cap toil at 50% so engineers keep engineering instead of drowning in operations.
The Phoenix Project
by Kim, Behr, and Spafford
- IT work is plant work, and a struggling org is a factory floor drowning in invisible work-in-progress.
- Make all four types of work visible: business projects, internal projects, changes, and the silent killer, unplanned work.
- Find the constraint, the one person everything routes through, and protect their time above all else.
- Untamed unplanned work spawns a capacity death spiral that crowds out everything planned.
- The cure is flow: small batches, one direction, fast feedback, and quality built in early.
6. People, Teams, and Org
the human system
The Manager’s Path
by Camille Fournier
- Management is a distinct, learnable craft, not a prize you win for being the strongest coder.
- It is a series of levels (tech lead, manager, manager-of-managers, and up) and each new level demands skills you have never used before.
- Master the concrete basics at every level: real 1-1s, direct feedback on growth, clearing roadblocks, “yes, and” trade-off negotiation.
- Most managers fail because they think the next level up is just “more of what I did before.” It is not.
- Naming what actually changes at each step is what lets engineers grow into leaders instead of breaking.
An Elegant Puzzle
by Will Larson
- Engineering management is a systems problem, not a series of heroic rescues.
- Teams fail one sprint at a time as stockpiles of work and technical debt quietly accumulate.
- Diagnose each team’s state (falling behind, treading water, repaying debt, or innovating) and apply the one correct system fix.
- System fixes are slow but durable. Reorgs and quick wins mostly just launder accountability.
- The manager’s real job is holding the line on a plan long enough for it to actually work.
Team Topologies
by Skelton and Pais
- Conway’s Law is inescapable. Your software will copy your communication structure, so team boundaries are the architecture.
- Design teams deliberately as the fundamental unit of delivery, not around an architecture drawn in isolation.
- Use four team types and three interaction modes as a small reusable vocabulary for org design.
- Run the reverse Conway maneuver: shape the teams to match the architecture you want to emerge.
- Respect every team’s finite cognitive load, or your own success becomes its bottleneck.
The Mythical Man-Month
by Fred Brooks
- Effort and progress are not the same. The “man-month” is a lie wherever work cannot be cleanly partitioned.
- Adding people to a late project makes it later, because training and communication overhead swamp the new hands like dousing a fire with gasoline.
- Conceptual integrity is the single most important property of a system.
- Achieve it by separating architecture from implementation, so the design proceeds from one mind, or a few resonant ones.
- Many hands can build, but a coherent vision must come from few.
Software Engineering at Google
by Winters, Manshreck, and Wright
- Software engineering is programming integrated over time. The job is sustaining a codebase for decades, not just writing it.
- Anything you do repeatedly must scale sub-linearly with people, or it eventually crushes you.
- So replace human effort with policy and automation: comprehensive tests, mandatory review, a single source of truth.
- The Beyonce Rule, “if you liked it, you should have put a test on it,” is what lets infrastructure teams change billions of lines safely.
- Engineering health is an organizational property decided by culture and tooling, not by individual brilliance.
Agile Software Development: The Cooperative Game
by Alistair Cockburn
- Software development is a cooperative game of invention and communication, not engineering-by-blueprint.
- Every project has two goals at once: deliver this software, and set up for the next game.
- The real bottleneck is conveying ideas between minds, so maximize communication richness. Put people in a room with whiteboards.
- Documents are the least effective channel. Face-to-face and osmotic communication are the hottest.
- There is no one right process. Run the lightest, “barely sufficient” methodology that still works.
PS
I might have forgotten some books, I read many but i will come back and add more.
And also this list will become shorter as I learn more about the world.
Figuring out how to read people is a hell of a challenge ;)
