# The Missing README ## Book Overview The Missing README is a practical guide for software engineers transitioning from academic knowledge to professional practice. Riccomini and Ryaboy address the gap between what computer science programs teach and what working engineers actually need to know on the job -- from navigating codebases and writing tests to managing technical debt and shipping software safely. The book covers the full spectrum of a developer's working life: onboarding at a new company, writing and reviewing code, understanding the software delivery lifecycle, working within agile teams, and communicating with managers and peers. It treats software engineering as a craft that blends technical skill with interpersonal awareness. Rather than prescribing a single methodology, the authors draw on Broadwell's four stages of competence to frame the learning journey. They emphasize front-loaded learning through doing, structured experimentation, and deliberate question-asking. The result is a guidebook that fills in what most README files leave out -- the human, procedural, and organizational knowledge that makes an engineer effective. ## Key Themes and Highlights ### Learning and Growth on the Job The book grounds professional development in a competence framework: "M. Broadwell defines four stages of competence in Teaching for Learning: unconscious incompetence, conscious incompetence, conscious competence, and unconscious competence." This progression shapes the entire onboarding philosophy. The authors push engineers to learn actively -- "Front-loaded learning does not mean sitting around reading documentation all day. We learn a little by reading and a lot by doing." They also stress effective question-asking: "Describe what you know when asking a question. Don't just share your raw notes. Outline what you've tried and discovered succinctly." ### Technical Debt and Code Quality A standout section dissects technical debt into four quadrants. "Prudent, deliberate debt is the classic form of tech debt: a pragmatic trade-off between a known shortcoming in the code and speed of delivery." Meanwhile, "Reckless, inadvertent debt comes from unknown unknowns." The book provides a concrete framework for discussing debt: state the situation factually, describe risk and cost, propose a solution, discuss alternatives, and weigh trade-offs. Code quality is reinforced by the "leave code cleaner than you found it" principle and by understanding code smell as "a term for code that isn't necessarily buggy but uses patterns known to cause problems." ### Software Delivery and Deployment Safety The delivery lifecycle gets detailed treatment across build, release, deployment, and rollout phases. The authors cover deployment strategies like feature flags ("on-off Booleans, allow lists, percentage-based ramps, or even small functions"), canary deployments, and blue-green deployments. They stress immutable releases: "Once published, never change or overwrite a release package." The section on configuration management is particularly practical -- "the cleverer your configuration scheme is, the more bizarre your bugs will be. Do not get creative with configuration." ## Analytical Reading - **Central Argument:** Software engineering competence requires intentional learning across technical, procedural, and interpersonal dimensions that academic programs don't cover. - **Key Evidence:** Four stages of competence framework, technical debt quadrant model, detailed software delivery lifecycle phases, agile ceremony breakdowns, and SBI feedback model. - **Methodology/Approach:** Pragmatic, experience-based guidance organized by career stage and activity type, with references to established frameworks (Scrum, Kanban, SemVer, SBI). - **Strengths:** Comprehensive scope that connects coding practices to organizational processes. The technical debt quadrant and the question-asking protocol are immediately actionable. The book treats testing, code review, and deployment as first-class engineering concerns, not afterthoughts. - **Limitations:** With so many highlights covering broad ground, some topics get surface-level treatment. The agile sections rehearse standard Scrum/Kanban concepts that experienced engineers may already know. The book is strongest when it offers opinionated advice and weakest when it catalogs general practices. ## Personal Reflection This book functions as a reference manual for the professional side of engineering work. The sections on asking questions effectively and timing interruptions are worth revisiting regularly -- they address a real friction point on engineering teams. The emphasis on time-boxing research before asking a question ("Set the limit before you start your research to encourage discipline and prevent diminishing returns") is a small habit that compounds over time. The technical debt framework connects well to the ideas in Your Code as a Crime Scene about hotspot analysis. Both books argue that understanding where and why code deteriorates matters more than chasing coverage metrics. The delivery lifecycle material also pairs with Team Topologies -- deployment safety nets like feature flags and canary releases depend on team structure and ownership boundaries. The SBI feedback framework (Situation-Behavior-Impact) near the end of the book is a useful tool beyond engineering contexts. Combined with the code review advice -- "Block off code review time in your calendar" and triaging review urgency -- it paints a picture of engineering as a discipline of structured attention. ## Action Items - [ ] Implement a personal time-box rule for research before asking questions (30 minutes default, adjust by urgency) - [ ] Use the technical debt discussion framework (situation, risk, solution, alternatives, trade-offs) in the next architecture review - [ ] Schedule dedicated code review blocks on the calendar instead of context-switching for each request