Books for developers

Negotiation from an FBI hostage negotiator, and far more practical than that sounds. The useful parts for engineers are listening techniques and how to ask a question that gets a real answer, which apply to salary conversations, scope discussions and disagreements with a tech lead.

Writing is most of a senior engineer's job: design docs, incident reports, pull request descriptions, the message that convinces a team to change direction. This is the standard book on writing clear non fiction, and applying even a third of it will make you noticeably better at the part of the job nobody trains you for.

Under 300 pages and it teaches you a language plus what memory actually is. Worth doing even if you will never write C professionally, because pointers, the stack and manual allocation stop being scary words once you have used them. The clearest technical writing on this list.

A book about how to think about computation rather than how to use a language. It will change how you see abstraction, and it will be hard, and those two facts are related. Free online. Best done slowly with the exercises, alongside a real job rather than instead of one.

The reference, not the tutorial. Rigorous, mathematical, and the place to go when you need an algorithm's proof rather than its shape. Own it, look things up in it, and do not try to read it front to back unless you are taking a course alongside.

What is actually happening below the query. Part one covers storage engines, B trees and log structured merge trees, so you finally understand why write heavy and read heavy databases are built differently. Part two covers replication and consensus. Dense, but it turns database choice from guesswork into reasoning.

Architecture books usually give you patterns. This one gives you the trade off analysis, which is the actual skill. It works through decomposing a monolith, splitting data ownership, and choosing between saga styles, and it refuses to hand you a right answer where none exists.

The honest book on services, including the long section on why you probably should not split yet. It covers the parts that actually hurt: breaking apart a shared database, testing across service boundaries, and the team structure that has to change alongside the architecture.

The argument that most software problems are people problems wearing a technical costume: interruptions, office layout, turnover, teams that never got to gel. Useful long before you manage anyone, because it gives you language for why a workplace feels productive or does not.

Written in 1975 and still the best explanation of why adding people to a late project makes it later. Short essays on communication cost, second system syndrome and why estimates go wrong. If you have ever watched a team grow and slow down at the same time, this tells you what you were looking at.

The book that gave the industry a shared vocabulary for structures we were all inventing separately. Some patterns have aged into language features and some are overused, but knowing the names still makes design conversations shorter. Read it to understand the trade off each pattern is making, not to apply them all.

A thick, thorough handbook on the act of writing code: variables, control flow, defensive programming, how to structure a routine. Not a book to read cover to cover. Keep it nearby and read the chapter that matches whatever you are currently doing badly.

Almost every job you take will hand you a large codebase with no tests and a deadline. This book is about that exact situation: how to get a seam into untested code so you can put a test around it before you change anything. Nothing else covers this ground as well, and you will use it in your first month somewhere new.

Opinionated, sometimes dated, and still the fastest way for a junior engineer to start noticing why some code is painful to change. Take the naming, function size and comment chapters seriously; treat the rest as one experienced person's preferences rather than law. Argued about more than almost any book on this list, which is itself a reason to have read it.

A catalogue of small, safe, named moves for changing code without changing what it does. The value is not the list, it is the habit it builds: you stop rewriting things in one heroic go and start improving them in steps small enough that you never lose a working state. Read the first three chapters even if you never touch the catalogue.

From the author of The Illustrated Transformer, so the diagrams do a lot of the teaching. It goes from tokens and embeddings through search, classification and fine tuning, ending at agent patterns, with code you can run at each step. The best paper book for someone who wants intuition rather than equations.

The official Git book, free in full, covering everyday use and then the internals that explain why Git behaves the way it does. Read chapter ten and Git stops being frightening.

A book about the craft rather than any language, covering pragmatism about tools, orthogonality, automation, testing and the professional habits that separate a good engineer from a productive one. Updated for its twentieth anniversary and still relevant.

A short book with a single argument: complexity is the enemy, and deep modules with simple interfaces are how you fight it. It disagrees productively with a lot of received wisdom about small functions and comments.

A career book built around the idea of learning in public, covering how to build a reputation, find mentors and sponsors, and progress from junior to senior. The most practical treatment of the networking side written for engineers.

The practical companion to the staff engineer question: how to pick what to work on, how to influence without authority, and how to lead technical work across teams you do not manage. Specific rather than inspirational.

The standard book on engineering management, structured by level from being mentored through tech lead, manager, director and beyond. Read the chapter one level above where you are.

A book that teaches programming through JavaScript rather than JavaScript through examples, with real projects and exercises you can run in the page. Free online, and better written than most paid material.

A book series that goes deliberately deep on the mechanics of JavaScript, including scope, closures, coercion, the object system and asynchrony. Read it when you are tired of language behaviour surprising you.