Reading The Pragmatic Programmer as an FDE: three habits for working alone at a client site

One of the first sections of The Pragmatic Programmer is called “The Cat Ate My Source Code”. It is exactly the kind of excuse a forward deployed engineer cannot offer in front of a client, because nobody there will take the blame on your behalf.

The book by David Thomas and Andrew Hunt first appeared in October 1999. Among the lessons its publisher lists outright is to take responsibility for your own work and career, and that is also the first thing an FDE has to learn when standing alone in front of someone else’s system.

If you are a developer with two to eight years of experience and are thinking of moving into FDE work, this book is worth reading before many more technical titles. It does not teach tools. It teaches habits, and habits are what decide whether you hold up when working on your own.

The edition to read is The Pragmatic Programmer, 20th Anniversary Edition: your journey to mastery (Addison Wesley, September 2019, 320 pages), a rewrite with new tips, new topics and revisions throughout. The book does not build a systematic theory; it gathers many short pieces of advice that are not tied to any language, framework or methodology.

Idea one: bring options, not excuses

The tip FDEs probably use most is “Provide options, not excuses”. It turns the point about responsibility above into concrete action.

Picture a scenario. A client wants an agent to read its entire archive of scanned contracts by Friday, but OCR quality on the older scans is poor. If all you say is “the data is bad, we won’t make it”, you are offering an excuse.

Bringing three options is different: run only on the newer scans; run on everything but flag low-confidence results for human review; or push the deadline back a week to clean the data. Now you are helping the client make a decision.

Record each of these moments in a work log, about three lines each time.

In an interview, that log entry can be rewritten as a STAR answer. Situation: the scanned contract archive was too old for the demo deadline. Task: deliver results by Friday. Action: proposed three options and spelled out the cost of each. Result: the client chose the human-review option and the demo went ahead on time.

The matching CV line might read: “Proposed three scope trade-offs when legacy scans blocked the pilot; shipped the human-review option on the original demo date.” A line like this conveys both the decision and the outcome, rather than just listing the technologies used.

Idea two: leave no broken windows, even in someone else’s system

Early in the book is a section called “Software Entropy”, which gives rise to the tip “No broken windows”: when you see bad design or bad code, fix it straight away. Dan Lebrero’s summary numbers this as Tip 5; other summaries number it differently.

For an FDE, the hard part is that the broken window usually sits in the client’s system. Suppose you find an ETL script with a password hard-coded in it.

You may not yet be allowed to fix it, but you should note it, tell the person responsible and propose a fix the same day. If the first breakage is ignored, the next ones become easier to ignore.

Idea three: build a tracer bullet in week one

Tip 20 in Lebrero’s summary is “Tracer Bullets”, also known as a walking skeleton. The idea is to build a thin path that runs through the whole system end to end, then flesh out each part.

On a client site, this means that in the first week a single document type needs to travel from upload to an answer on the client’s own screen.

Running on real data and real infrastructure surfaces problems such as firewalls, access permissions and unusual formats early. Discover them in week six and it is too late.

What if you apply them badly?

These three habits are easy to apply halfway. The most common mistake is offering options without stating the cost: “run everything but flag it” sounds good, but if you do not say who will review the results and how many hours it will take, the client still lacks the information to choose.

The second mistake is fixing a client’s broken window without permission. Pushing a patch straight to that ETL script could break another job you did not know about, turning goodwill into an incident. In someone else’s system, “fix it now” should mean report it now and propose a fix now.

The third mistake is building the tracer bullet on sample data or on your own machine. At that point it is no longer a tracer bullet, because it avoids precisely the things you need to discover early.

In what order should you read it?

Read all of “A Pragmatic Philosophy” first. It consists of seven short sections, moving from responsibility for your career and excuses, through software entropy, to good-enough software, the knowledge portfolio and communication. The “Good-Enough Software” section is particularly useful when a client wants perfect results in too little time.

Next, read the part on tracer bullets before taking on your first project. Once you start working with the client’s team, read “Pragmatic Projects”, which covers teamwork and keeping users happy.

The tip “Be a Catalyst for Change” fits this stage: rather than forcing the client’s team to change how they work, let them see what the new way would look like so that they want to change themselves.

Finally, there is “Invest Regularly in Your Knowledge Portfolio”. Every FDE project forces you to learn a new domain, so treat recording what you have learned as a regular investment, not something saved for when you have spare time.

The book is worth reopening exactly when you need it most: standing alone in front of someone else’s system, needing a better answer than “the cat ate my source code”.