Twelve short chapters to help you make better decisions, write better software, communicate better and build the evidence that you work at senior level.
PDF + EPUB · DRM-free · Free updates within 1.x
| INSIDE | QTY | PAGES | — |
|---|---|---|---|
| CHAPTERS | 12 | 12–89 | |
| CONCEPTS | 134 | 142–204 | |
| CHECKLISTS | 8 | 124–126 | |
| TEMPLATES | 4 | 127–138 | |
| BUILD PLAN | 1 | 91–122 | |
| TOTAL | 206 pages · PDF + EPUB | ||
| ALSO INCLUDEDTornar-se engenheiro sénior · 220 pages · PDF + EPUB | |||
FROM CHAPTER 01 · P. 13
Earlier in a career, success often means completing assigned tasks correctly. Senior work is different.
The senior question is not only, “Did I build the thing?” It is also:
Real projects rarely have perfect information, perfect time, or perfect requirements. Seniority is the ability to make good decisions anyway.
Common constraints:
A senior developer is not merely someone who knows more syntax. A senior developer reliably improves outcomes in uncertain situations.
Technical depth
You understand code, systems, data, testing, performance, and operations.
Product judgment
You can connect engineering choices to user and business outcomes.
Delivery skill
You can break work down, reduce risk, and finish valuable increments.
Leadership behavior
You improve the people and system around you without needing authority first.
This handbook trains those capabilities in parallel.
Read the Introduction and Chapter 1 free →Real pages and the cover’s own figures, set to music. There’s no voice-over; the transcript is below the video.
Every chapter ends with a practice exercise, and each exercise leaves something behind: a note, a plan, a test, a measurement. As the book puts it: “Evidence is what separates vague confidence from senior-level proof.” (p. 8)
| # | YOU’LL HAVE MADE | FROM |
|---|---|---|
| 01 | A one-page decision note: the options you considered, why you chose one, and what would make you change your mind.Ch. 01 · p. 17 | Ch. 01 · p. 17 |
| 02 | A pre-build note: the domain concepts, the boundaries, the invalid states to rule out, and what done means.Ch. 02 · p. 23 | Ch. 02 · p. 23 |
| 03 | Two schema designs, drawn before any code: order returns and post revisions.Ch. 03 · p. 32 | Ch. 03 · p. 32 |
| 04 | A one-page design note for a low-stock alerts feature, clear enough for another developer to challenge.Ch. 04 · p. 39 | Ch. 04 · p. 39 |
| 05 | The tests for “add line item to order”, designed before the implementation.Ch. 05 · p. 45 | Ch. 05 · p. 45 |
| 06 | A controller method refactored in three passes: Form Request, Action or Service, Resource.Ch. 06 · p. 51 | Ch. 06 · p. 51 |
| 07 | A performance note with before-and-after numbers, measured on 10,000 seeded orders.Ch. 07 · p. 57 | Ch. 07 · p. 57 |
| 08 | A runbook that lets others succeed without needing you in the room.Ch. 08 · p. 64 | Ch. 08 · p. 64 |
| 09 | One decision written three ways: for developers, for product stakeholders and for future maintainers.Ch. 09 · p. 70 | Ch. 09 · p. 70 |
| 10 | A leadership note on one recurring friction, and one small change you act on.Ch. 10 · p. 76 | Ch. 10 · p. 76 |
| 11 | A project plan for a first MVP slice: outcome, risks, acceptance criteria and demo steps.Ch. 11 · p. 83 | Ch. 11 · p. 83 |
| 12 | An evidence-log.md file with one entry a week.Ch. 12 · p. 89 | Ch. 12 · p. 89 |
Your portfolio should eventually tell a coherent story:
“I can identify an important problem, design a practical solution, implement it with quality, communicate trade-offs, reduce operational risk, and help others understand or extend the work.”
You’re a full-stack developer who wants to operate at senior level. That’s exactly who it’s written for.
You learn by doing. Every chapter ends with a practice exercise, the book asks you to apply each chapter to a real project, and Part IV gives you a complete plan to build if you don’t have one.
You can give it a few hours a week. The book suggests 8 to 12 hours a week, one chapter or part of one at a time, and the same shape at a smaller volume if you have less time.
You want something to keep open. 8 checklists, 4 fill-in templates and 134 concepts from A to Z that the chapters link to.
You want interview prep. There’s nothing on algorithms, coding interviews or salary negotiation.
You want a promise of promotion. The book trains how you decide and helps you collect evidence of it. It doesn’t promise a title or a pay rise.
You need React, Node or Python code. The code samples are short PHP and Laravel snippets, and the build plan uses Laravel, Vue, MariaDB and Docker Compose. The reasoning carries over; the code won’t.
You’re after microservices or Kubernetes. The build plan picks a modular monolith on purpose: “No microservices. No Kubernetes.” (p. 118)
You want a quick read. The chapters are short, but the book asks you to practise between them: “Do not try to consume everything quickly.” (p. 8)
Twelve short chapters in three parts, then the practical half of the book: a complete build plan, a toolkit and an A–Z reference.
| IN THIS CHAPTER | PAGE |
|---|---|
| The shift from output to outcomes | 13 |
| Seniority is judgment under constraint | 13 |
| The three horizons | 14 |
| Ownership without control | 14 |
| Taste in engineering | 15 |
| The senior failure modes | 15 |
| A practical senior decision framework | 16 |
| Practice exercise | 17 |
“A senior developer does not wait for all uncertainty to disappear. They reduce uncertainty intentionally.”
| IN THIS CHAPTER | PAGE |
|---|---|
| Fundamentals are not beginner topics | 19 |
| Code should express intent | 19 |
| Keep units small enough to understand | 20 |
| Make invalid states harder to represent | 20 |
| Boundaries matter | 21 |
| Feedback loops | 21 |
| Debugging discipline | 22 |
| The definition of done for senior work | 23 |
| Practice exercise | 23 |
“Debugging is not guessing loudly. It is narrowing uncertainty.”
| IN THIS CHAPTER | PAGE |
|---|---|
| Data models are product decisions | 26 |
| Start with language | 26 |
| Relationships | 27 |
| Constraints are design tools | 28 |
| Normalization and denormalization | 29 |
| Status fields need clear meaning | 29 |
| Soft delete or hard delete? | 30 |
| Data design checklist | 30 |
| Schema sketch for the two examples | 31 |
| Practice exercise | 32 |
“[D]enormalization is not wrong, but it should pay rent.”
| IN THIS CHAPTER | PAGE |
|---|---|
| Architecture is about change | 34 |
| Start with forces | 34 |
| Modular monolith thinking | 35 |
| Layering | 35 |
| Avoid premature abstractions | 36 |
| System design questions | 36 |
| Architecture decision records | 37 |
| Example decision: Notification system | 37 |
| Architecture smells | 38 |
| Practice exercise | 39 |
“Good architecture is not the biggest possible design. It is the smallest structure that keeps important options open.”
| IN THIS CHAPTER | PAGE |
|---|---|
| Tests are a design tool | 41 |
| The testing pyramid, practically | 41 |
| Behavior over implementation | 41 |
| What to test first | 42 |
| Test names should teach | 42 |
| Factories and data setup | 43 |
| Integration tests are valuable | 43 |
| Avoid fragile tests | 43 |
| Regression tests | 44 |
| Testing strategy note | 44 |
| Practice exercise | 45 |
“Senior engineers know that testing everything is not the same as testing wisely.”
| IN THIS CHAPTER | PAGE |
|---|---|
| Legacy code is code you are afraid to change | 47 |
| First, understand behavior | 47 |
| Characterization tests | 47 |
| Small refactoring moves | 48 |
| Separate refactoring from behavior change | 48 |
| When not to refactor | 49 |
| Refactoring a legacy order workflow | 49 |
| The Boy Scout rule, carefully | 50 |
| Refactoring checklist | 50 |
| Practice exercise | 51 |
“Small moves reduce fear.”
| IN THIS CHAPTER | PAGE |
|---|---|
| Performance starts with measurement | 53 |
| Common web app bottlenecks | 53 |
| Scalability is not only traffic | 54 |
| Caching | 55 |
| Performance budgets | 56 |
| Read the query plan | 56 |
| Practice exercise | 57 |
“Senior developers do not optimize from vibes alone.”
| IN THIS CHAPTER | PAGE |
|---|---|
| Code runs somewhere | 60 |
| Local development is part of reliability | 60 |
| Configuration | 61 |
| Migrations are operational events | 61 |
| Observability basics | 62 |
| Incident thinking | 62 |
| Deployment and rollback | 63 |
| Reliability trade-offs | 63 |
| Practice exercise | 64 |
“A good runbook is a leadership artifact: it lets others succeed without needing you in the room.”
| IN THIS CHAPTER | PAGE |
|---|---|
| Communication is part of engineering | 66 |
| Clarity beats completeness | 66 |
| Writing for different audiences | 67 |
| Status updates | 68 |
| Code review communication | 68 |
| Disagreement | 69 |
| Documentation that gets read | 69 |
| Practice exercise | 70 |
“The goal is not to win. The goal is to improve the decision.”
| IN THIS CHAPTER | PAGE |
|---|---|
| Leadership is creating better outcomes through others | 72 |
| The senior multiplier | 72 |
| Mentoring | 73 |
| Psychological safety and standards | 73 |
| Delegation | 74 |
| Leading technical change | 74 |
| Handling conflict | 75 |
| Leadership evidence | 75 |
| Practice exercise | 76 |
“Safety without standards becomes comfortable mediocrity. Standards without safety become fear.”
| IN THIS CHAPTER | PAGE |
|---|---|
| Project management is risk management | 78 |
| Define the outcome | 78 |
| Break work into slices | 79 |
| Dependencies | 79 |
| Estimation | 80 |
| Risk register | 80 |
| Project rhythm | 81 |
| Scope control | 81 |
| Definition of ready and done | 82 |
| Practice exercise | 83 |
“Estimates are not promises. They are forecasts under uncertainty.”
| IN THIS CHAPTER | PAGE |
|---|---|
| Seniority must become visible | 85 |
| Evidence categories | 85 |
| The senior story | 87 |
| Monthly evidence routine | 87 |
| What counts as good evidence | 87 |
| Self-assessment questions | 88 |
| Practice exercise | 89 |
“The point is not vanity. The point is clarity.”
Project manager app — flagship build plan (v1)See the plan ↓
Checklists · ADR template · Design doc template · Evidence log · Project plan templateSee the toolkit ↓
Glossary · Concept companionSee the reference ↓
These pages come from the PDF you download, typeset in Archivo and IBM Plex Mono. Open any of them full size.
p. 12 / 206 · Chapter 01 opener · The shift from output to outcomes
Pages 6 to 17 of the book, word for word in your browser, or the book’s first 17 pages as a PDF. No email, no sign-up.
| IN THE SAMPLE | QTY |
|---|---|
| Pages | 6–17 |
| Introduction · sections | 8 |
| Chapter 01 · sections | 8 |
| Practice exercise | 1 |
An excerpt from Chapter 01
The senior failure modes
Watch for these traps:
Across the chapters, advice often comes with a weak example next to a stronger one. Here are three, word for word:
p. 68
WEAK
STRONGER
“The invoice creation endpoint is implemented and passing feature tests. Applying partial refunds is blocked by an unclear rule about whether already-settled invoices can be modified or must spawn a credit note. I recommend forbidding direct edits and creating an explicit credit note instead, which keeps audit history clean. Next I will add the credit-note flow tests unless we choose differently.”
p. 68
WEAK
STRONGER
“This controller now handles validation, persistence, and response formatting. Could we move validation into a Form Request and the write behavior into an Action? That would make the endpoint easier to test and keep future controller changes smaller.”
p. 88
WEAK
STRONGER
“Reduced order detail query count from 17 to 4 by adding targeted eager loading and response shaping. Documented why full eager loading was avoided on the order list endpoint, where the cost was higher than the benefit.”
“Review is not a place to display superiority. It is a place to improve the code and the team.”
A project manager web app, planned the way a senior would plan it: outcomes, domain model, database schema, API contract, architecture, tests, operations, performance, security, risks, a sliced roadmap and a demo script.
| — | IN THIS PLAN | PAGE |
|---|---|---|
| — | TL;DR | 92 |
| §1 | Vision and outcomes | 92 |
| §2 | Domain model | 93 |
| §3 | Database schema | 95 |
| §4 | API contract | 98 |
| §5 | Application architecture | 102 |
| §6 | Frontend architecture | 103 |
| §7 | Workflows (user journeys as slices) | 105 |
| §8 | Testing strategy | 109 |
| §9 | Operations | 110 |
| §10 | Performance budget | 113 |
| §11 | Security and authorization | 114 |
| §12 | Risks and trade-offs | 116 |
| §13 | Implementation roadmap (slices) | 118 |
| §14 | Definition of done (project-wide) | 119 |
| §15 | Demo script | 120 |
| §16 | Agent execution notes | 120 |
PINNED IN THE PLAN
MariaDB 11.4 LTS · PHP 8.4 · Laravel 13 · Vue 3.5 · Docker Compose
It’s a written plan, not source code: building it is the exercise. Every slice names the chapters it puts into practice. Versions are pinned as the plan was written, and the book itself says to check current documentation before relying on any detail in production.
“The plan is organized so a human can read it as a senior-grade design document and an implementation agent can execute it top to bottom.”
| IN THE PLAN | QTY |
|---|---|
| Roles | 3 |
| Entities | 8 |
| Invariants | 6 |
| Database tables | 9 |
| REST endpoints | 27 |
| Workflows (W1–W10) | 10 |
| Delivery slices (S1–S14) | 14 |
| Demo script steps | 10 |
| Ordered steps for an implementation agent | 21 |
| FROM / TO | todo | in_progress | blocked | done | cancelled |
|---|---|---|---|---|---|
| todo | — | yes | yes | no | yes |
| in_progress | yes | — | yes | yes | yes |
| blocked | yes | yes | — | no | yes |
| done | yes | no | no | — | no |
| cancelled | yes | no | no | no | — |
§11 · p. 115 · Illegal transitions return 409 Conflict.
The toolkit is the part you’ll reuse: 8 checklists and 4 fill-in templates. Try the first checklist here.
TOOLKIT · P. 124
0 of 7 ticked
Try it on a decision you’re making this week. Nothing is saved.
| CHECKLIST | ITEMS |
|---|---|
| Senior decision | 7 |
| Feature readiness | 8 |
| Code review | 8 |
| Testing | 7 |
| Data modeling | 7 |
| Performance | 7 |
| Operations | 7 |
| Leadership | 7 |
| TEMPLATE | PAGE |
|---|---|
| ADR templateTitle · Status · Context · Decision · Alternatives considered · Consequences · Review trigger | 127 |
| Design doc templateProblem · Goals · Non-goals · Users and workflows · Proposed solution · Data model · API design · Frontend design · Testing strategy · Operational notes · Risks · Open questions · Acceptance criteria | 130 |
| Evidence logDate · Work completed · Senior skill practiced · Artifact created · Decision or trade-off · What I learned · What I would improve · Proof link or file | 134 |
| Project plan templateOutcome · Scope · Milestones · Dependencies · Risks · Acceptance criteria · Test plan · Demo plan · Communication plan · Retrospective questions | 136 |
The templates are pages inside the PDF and the EPUB, laid out to be filled in, with ruled lines to write on. They aren’t separate editable files.
Each concept has its own entry: a one-line summary, a fuller explanation, an example, a common trap, a practice prompt and, where it applies, the places in the book where it appears. Underlined terms throughout the chapters link straight to it.
ALSOreversibleirreversible
Reversibility describes how hard it is to undo or change a decision later.
Highly reversible decisions can be made faster. Hard-to-reverse decisions deserve more design, communication, and evidence. Senior engineers adjust decision process to reversibility instead of treating every choice the same.
Every name, with the page its entry starts on. The summaries, examples, common traps and practice prompts are in the book.
Includes every 1.x update, free, from your account.
ORDER
€19
Final price · both editions, both formats
EN 206 pp. + PT 220 pp. · PDF + EPUB · version 1.1 · 3.5 MB
Card, MB WAY, Multibanco and more · Not sold to buyers in the United Kingdom
| YOU GET | DETAIL |
|---|---|
| English edition | 206 pages |
| European Portuguese edition | 220 pages |
| Formats | PDF + EPUB 3, each edition |
| Tagged, with bookmarks and clickable cross-references | |
| EPUB | Validated with EPUBCheck: 0 errors |
| DRM | None |
| Files | 4 · 3.5 MB in total |
| Updates | Every 1.x version, from your account |
| Edition | First edition, 2026 · version 1.1 |
| Typeset in | Archivo and IBM Plex Mono |
| Published by | Feitura |
| TOTAL | €19 |
You pay on Stripe’s secure page.
Once your payment is confirmed, your four files are on the next page, and the links arrive by email.
Your account keeps the newest 1.x files, ready whenever you need them.
NO REVIEWS YET: JUDGE IT BY THE PAGES. See the pages ↑
Four DRM-free files: Becoming a Senior Engineer as a PDF (206 pages) and an EPUB 3, and its European Portuguese edition, Tornar-se engenheiro sénior, as a PDF (220 pages) and an EPUB 3. Version 1.1, first edition, 2026. There’s no printed edition. It’s a handbook, not a novel: the Introduction and the twelve chapters run to page 89, and the build plan, the toolkit and the A–Z reference fill most of the rest.
Yes. The Introduction and Chapter 1 are free here in your browser, word for word, or as a PDF of the book’s first 17 pages. No email needed.
Read the Introduction and Chapter 1 free →The files are standard EPUB 3 and PDF, for reading apps and devices that support those formats. The EPUB reflows to fit your screen, which suits a phone. The PDF keeps the book’s page layout, which suits a tablet or a computer. We haven’t tested specific e-readers or apps, so we don’t promise any: open the free sample PDF on your device first.
Read the Introduction and Chapter 1 free →No, but it helps. The chapters are about decisions, design, delivery and leadership, and the book is written to be useful in any project you happen to be working on. Where it shows code, it uses short PHP and Laravel snippets. The build plan in Part IV is pinned to the versions it was written for: Laravel 13, PHP 8.4, Vue 3.5, MariaDB 11.4 LTS and Docker Compose. There’s nothing on React or Python, or on Node as a back end. Tools change, as the book’s copyright page says, so check current documentation before relying on any detail in production.
No. It’s a written plan, §1 to §16: outcomes, domain model, database schema, API contract, architecture, workflows, tests, operations, a performance budget, security, risks, a sliced roadmap, a definition of done, a demo script and 21 ordered steps for building it. No repository comes with the book: writing the code is the exercise. The plan is written so that, in the book’s words, “an implementation agent can execute it top to bottom”: a coding agent can follow those steps, from creating the project to tagging the release v1.0.0. It reads just as well as a design document if you build it yourself. The book doesn’t teach AI tools.
Yes. Tornar-se engenheiro sénior is the European Portuguese edition of the English original, with the same chapters, build plan, toolkit and 134 concepts. Its concept dictionary also gives the original English term for each entry.
Feitura, a web studio in Portugal, publishes the book and is credited as its author. There’s no personal byline. The best way to judge it is the free chapter.
Read the Introduction and Chapter 1 free →The book is at version 1.1. Every 1.x version is free: when one is published, we email you and your account at feitura.com/conta serves the new files, in both languages and both formats. Updates beyond 1.x aren’t included. You don’t need an account before you pay: when you buy, we create one for your email address (the email includes a link to choose a password), or add the purchase to the Feitura account you already have.
The files are delivered as soon as your payment is confirmed. So when you order, you ask for immediate delivery in a separate box and acknowledge that you lose the 14-day right of withdrawal. Your 2-year legal guarantee of conformity still applies: if a file is faulty or doesn’t match this page, reply to your order email and we’ll put it right, free of charge. If we can’t, if we don’t within a reasonable time, or if the fault is serious, you’re entitled to a price reduction or, unless the fault is minor, to end the contract and get your money back.
You pay on Stripe’s secure payment page, by card, Apple Pay, Google Pay, MB WAY, Multibanco, Klarna, Revolut Pay, Bancontact, Amazon Pay, Satispay or Link. We never see your card details. Feitura issues a fatura-recibo (invoice-receipt) for every order and sends it to your email; to have a tax number or a company name on it, open “Invoice details” before you pay. Buying doesn’t sign you up to any newsletter.
Each purchase is a personal copy for one reader: you can keep the files on your own devices and print them for yourself, but not share or resell them. The book’s copyright page doesn’t allow reproducing or distributing it without permission, apart from brief quotations and certain other non-commercial uses the law permits, so each reader needs their own copy.
No. €19 is the price. There are no launch discounts, countdowns or struck-through prices.
Selling ebooks to consumers in the UK would require Feitura to register for UK VAT from the first sale, and it isn’t registered there. So we can’t take UK orders. The free sample is open to everyone.
Read the Introduction and Chapter 1 free →Better websites. Smarter software.Made for you.
Feitura designs and builds websites, online stores and web apps, combining senior engineering with AI-accelerated delivery. The habits in this handbook (clear outcomes, small reversible slices, tested behavior, visible trade-offs) are the ones we practice on every build.
MADE IN PORTUGAL.