# Why FDEs should read The Missing README out of order > Every engagement makes an FDE a new hire again, and Riccomini and Ryaboy's 288-page guide works as the checklist for that first week. Original: https://fdetimes.net/en/books-courses/missing-readme-book-for-fdes/ Every new engagement turns an FDE into a new engineer again. The codebase is unfamiliar, the review process is unfamiliar, and there is an extra manager who sits nowhere on your own organisation chart. Most career books assume you are a newcomer only once. *The Missing README: A Guide for the New Software Engineer* by Chris Riccomini and Dmitriy Ryaboy is no exception: No Starch Press published the 288-page paperback on 4 August 2021, written for people entering the profession. The book's official site promises to teach the software engineering skills your manager wants you to know. The Barnes & Noble description is blunter: knowing how to code is only half the battle, because many of the skills and processes that decide success or failure are not taught in any school or bootcamp. For those working as FDEs, or hoping to, the book's value lies elsewhere. It is a checklist for the "first week" you repeat at every client, and the faster you get through that first week, the sooner you create value. ## A coffee with a mentor, bound as a book Penguin Random House presents it as the book engineering leads wish every new engineer would read before day one, while Gwen Shapira likens it to a coffee with a senior mentor. According to Greg Wilson, the book ranges from continuous integration, refactoring and technical support to agile planning and working with managers. These are professional habits, the things an FDE has to relearn in each client's own way. ## Fourteen chapters, but do not read them in order The book has 14 chapters. The suggestions below are a reading plan based on the chapter titles and short descriptions the book publishes, matched to the rhythm of FDE work, not a page-by-page summary. A sensible order is chapter 2 before day one, chapter 10 before the first major feature, the section on writing operable code once your code starts running on the client's infrastructure, and chapter 9 before go-live. The material on working with managers is best read gradually across the engagement, because you have both your own manager and one on the client side. ## First idea: name what you do not know The title of chapter 2 alone, "Getting to Conscious Competence", is advice you can use immediately. Taken literally, it means getting the job done while knowing exactly where your understanding ends. On a client's team, the most dangerous newcomer is the one who does not know what they are missing. Picture your first week at a retail chain that needs an inventory forecasting pipeline. You draw a three-column table: understood (the language, the framework), partly understood (how they deploy), unknown (which table is the source of truth for stock levels). The third column is your list of questions for the first meeting. It is also what shows the client you are serious. **Key point:** On a client's team, the right questions in the first week are worth more than the first line of code. ## Second idea: a design doc starts with the problem definition Chapter 10 has the clearest description of any chapter: the design process, covering experimentation, problem definition, documentation and collaboration. At a client, problem definition is where customer discovery meets engineering, and where things most easily go wrong. The practical advice: before your first major feature, write a short document that opens with a problem definition the client has confirmed, then invite at least one engineer on the client side to review it. They will catch constraints nobody wrote down, and they will be the ones defending the design after you have left. ## Third idea: who gets paged at 2am? Once your code is running at the client, the material on writing operable code becomes practical: logging, metrics, configuration and defensive programming. Right after it comes chapter 9, "Going On-Call". When a book for newcomers devotes a whole chapter to on-call duty, the message is clear: production systems will break at some point, and newcomers must be ready too. For an FDE, these two parts should be read together, because the system runs on someone else's infrastructure and data. Take the retail example again, and suppose the pipeline fails the night before a promotion. Without logs, without metrics, and without agreement on who receives the alert, a technical incident becomes an incident of trust. What to do: before go-live, check what your code logs and where it sends metrics, then agree in writing with the client who is on call and who may see the logs. ## What the book leaves out Greg Wilson titled his review "What's Missing from 'The Missing README'". He points out that the book does not discuss privacy, algorithmic discrimination, workplace harassment, workers' rights or legal liability. For an FDE, this gap is bigger than for an in-house engineer, because you handle the client's real data and sometimes their customers' data too. After reading the book, add one question to your day-one checklist yourself: whom is this data about, what is it used for, and has the client confirmed that you may use it this way? ## Who should read it, and what to do next The book suits software engineers moving into FDE work best, especially those used to a single codebase for many years. Experienced FDEs can skim it, stopping only at chapters 2 and 10, the operable code section and chapter 9. When interviewing for an FDE role, ask two questions drawn from the book directly: who reviews design docs, and who is on call after go-live. The answers help you picture how far your responsibility will extend before you accept the job. On your CV, do not just write "deployed system X". If you have written a design doc with client engineers or been on call for a system running on real data, say so explicitly and add one concrete detail, such as who on the client side reviewed the document. The book was written to get you through your first year at work. An FDE meets that first year again at every new client, only with less time to get through it. **Try this week:** - Draw a three-column table (understood, partly understood, unknown) for the client system you are working on or about to start - Ask the client one question before go-live: when the system fails at midnight, who receives the alert, and which logs may you see - Rewrite one line of your CV to show that you have been on call or have written a design doc with client engineers ## Sources - [The Missing README: A Guide for the New Software Engineer](https://themissingreadme.com/) - [The Missing README by Chris Riccomini and Dmitriy Ryaboy](https://penguinrandomhouse.com/books/690695/the-missing-readme-by-chris-riccomini-and-dmitriy-ryaboy) - [The Missing README: A Guide for the New Software Engineer (Barnes & Noble)](https://www.barnesandnoble.com/w/the-missing-readme-chris-riccomini/1139537571) - [What's Missing from 'The Missing README'](https://neverworkintheory.org/2021/10/24/whats-missing-from-the-missing-readme.html)