Technical books have a shelf life that nobody prints on the cover.
A cookbook from 2018 still works. A history book from 2018 still works. A Laravel book from 2018 will teach you a middleware pattern that was replaced twice, recommend a package whose maintainer archived it, and show you a test suite in a syntax that no longer runs.
I've written a series of ebooks on PHP, OOP, SOLID, design patterns, Laravel conventions, testing with Pest, application architecture, and AI-assisted development. There are also two aimed at kids learning to code. Every one of them was correct when I wrote it. That is a much weaker claim than "correct now," and I'd rather find the gap myself than have a reader find it for me.
So: I'm opening the series to technical reviewers before the final edition ships. Applications close Sunday, 26 July.
Why I can't do this alone
Not because I lack the time. Because I lack the distance.
When you write a technical book, you build a mental model of the reader and then you write to that model for months. The model is always partly wrong, and you are the last person who can see how. You skip a step because it's obvious to you. You keep an example that made sense when you drafted the chapter and no longer matches the surrounding code. You cite a package because it was the right answer for a project you shipped two years ago, and you never checked whether it's still maintained.
None of this shows up on a reread. Rereading your own work is mostly pattern-matching against your own memory. You see what you meant, not what you wrote.
A reviewer who has never seen the manuscript reads what's actually on the page. That's the whole value, and it's not something more effort on my side can substitute for.
What the job actually is
You pick one book from the series. You read it properly — not skim it — and you flag what's broken.
Four things in particular:
Things that are outdated. The framework moved, the syntax changed, there's now a cleaner way to do the same thing. The advice isn't wrong exactly, it's just from an older world.
Things that are wrong. The code sample doesn't run. The explanation misstates how something works. This is the highest-value category and the one I most want to hear about.
Things that are abandoned. A package I recommended hasn't seen a commit in three years. A tool I told you to install no longer exists.
Things that are unclear. You read a section twice and still didn't follow it. That's not your failure, it's mine, and I need to know which sections do it.
You don't need to fix anything. Pointing is enough.
The feedback format
This is the part that's worth stealing even if you never apply.
Most book feedback arrives as prose: "Really enjoyed chapter 4, though I wondered about the routing bit." That's pleasant and almost impossible to act on. I don't know which page, what specifically, or what you'd rather see.
So reviewers use four columns. One row per issue.
| Chapter / Page | Status | What's wrong | What you'd do instead |
|---|---|---|---|
| Ch. 4, p. 61 | Outdated | Route::resource example uses Laravel 8 style | Show scoped route binding |
| Ch. 7, p. 118 | Broken | Code sample fails — missing import for expect() | Add use function Pest\Laravel\get; |
| Ch. 2, p. 24 | Unclear | Interface explanation stays abstract throughout | Replace with a payment gateway example |
Three things this does that prose doesn't.
It forces specificity. You can't write a row without naming a location, so vague impressions get filtered out before they reach me.
It separates severity from opinion. "Outdated" and "Broken" are different problems with different urgency. A prose paragraph blends them together and I have to guess which is which.
It converts directly into work. A filled-in sheet is already a to-fix list. I sort by status, work top to bottom, and reply to each row. Nothing gets lost in a thread.
If you ever run a review process — for docs, a spec, a design, a codebase — some version of this table will serve you better than asking for thoughts.
Who I'm looking for
Anyone who writes code. That's the entire filter.
Seniority helps for some books and actively hurts for others. If you're three months into PHP and a chapter loses you, that's the single most useful signal I can get — I wrote it for you, and it didn't land. A senior engineer will read straight past the same gap because they can fill it from experience without noticing they're doing it.
The one thing I do need is bluntness. If a chapter is weak, I need you to write "this chapter is weak" rather than "this chapter has potential." I'm not sentimental about any of it. If a section should be cut entirely, say so and I'll cut it.
Reviewers who tell me it's all great are, with respect, not useful to me.
What you get
The full series. Not just the book you review — all of it, free, permanently.
Your name in the acknowledgements. Printed in every copy of the new edition, under whatever handle you choose.
Let me be honest about the exchange: reading a technical book carefully takes somewhere between four and eight hours depending on which one you pick. What I think does cover it is early access to the whole series, a permanent credit, and — if you're the kind of person who enjoys this — a few hours of deliberate close reading in your own field, which is not the worst way to spend a weekend.
Timeline
| 26 July | Applications close |
| 2 August | Reviewers selected and books assigned |
| 3 – 24 August | Review window |
| Late August | Final edition ships |
Three weeks for the review itself. You can break it up however you like — nobody expects a single sitting.
Applying
The form takes about a minute. You'll pick which book you want, tell me roughly where your experience sits, and give me the handle you want in the acknowledgements.
Applications close Sunday, 26 July.
SOCIAL SHARE CARD GENERATOR