Most programming books teach you one thing deeply: a language, a framework, a database. Very few explain how all of those things fit together inside an actual team, or why the product manager keeps asking you for estimates, or what the designer is doing for three weeks before you get a single mockup.
Software Development From A to Z by Olga Filipova and Rui Vilão (Apress, 2018) tries to fill exactly that gap. I finished it recently, and here's my take.
What the book is about
The premise is simple: follow one small team building one product, an online learning platform, from "hey, I have an idea" all the way to maintaining it in production. Each chapter is narrated from the seat of a different role:
- Having an idea (and turning it into an MVP)
- Roles, responsibilities, Scrum and Kanban
- The product manager: requirements and deadlines
- The designer: user-centered design
- The backend engineer
- The frontend engineer
- The QA engineer
- DevOps: going live
- Maintaining and improving what you shipped
It's around 300 pages, and it moves fast.
What I liked
The running example actually runs. A lot of "big picture" books stay abstract. This one doesn't. You watch the requirements table get written, the personas get invented, the Spring Boot backend get scaffolded, the Vue/Nuxt frontend get wired up, and the whole thing get deployed to Heroku through Travis CI. Seeing the same feature (user registration, for example) pass through the hands of five different roles is the single most valuable thing in the book.
It's honest about messy reality. There's a whole section admitting that role titles mean different things at different companies and that it's normal to be confused. The Scrum-vs-Kanban comparison doesn't pick a winner; it rates each on a strictness scale and then shows the hybrid the authors actually use. That felt refreshingly practical.
The interviews. Several chapters include short interviews with a real product manager, designer, and DevOps engineer. The "biggest screw-up / biggest success" questions in particular give the book a human texture that pure tutorials lack.
The MVP chapter. If you've never internalized the difference between delivering a wheel and delivering a skateboard, chapter 1 will fix that. It's the clearest explanation of "minimum viable" I've read in a book aimed at developers.
What I didn't love
Depth is uneven. The backend and frontend chapters go fairly deep into code, while the DevOps chapter stays more conceptual. If you're reading for the technical content, you'll find the engineering chapters meatier than the rest. If you're reading for the big picture, the code may feel like a detour.
The stack is dated. Java/Spring Boot and Vue 2 with Nuxt are still perfectly reasonable choices, but Travis CI and Heroku's free tier are not what they were in 2018. Read the tooling chapters for the ideas (CI on every push, automated deploys from the main branch, platform-as-a-service tradeoffs), not the specific buttons to click.
It's an overview, by design. No chapter will make you a designer or a DevOps engineer. That's fine, but set expectations accordingly: this is the map, not the territory.
Who should read it
- Bootcamp grads and juniors about to join their first team. This will decode half the meetings you'll sit in.
- Career changers (QA, support, design, product) who want to understand what engineers actually do all day.
- Solo founders planning to build an MVP and wondering which hats they'll need to wear.
- Experienced devs who want something to hand to non-technical colleagues. It's approachable without being condescending.
Skip it if you already have a few years on cross-functional teams; you'll nod along but learn little.
Verdict
4 / 5. Not a reference book, and not the place to learn any single technology. But as a guided tour through how software gets made, and especially through how the people who make it depend on each other, it's one of the better ones out there. I'd put it on the same shelf as The Phoenix Project, just less narrative and more hands-on.
Have you read it? What's your go-to "how teams actually work" book for new developers? Drop it in the comments.
Top comments (0)