The ML book that teaches FDEs the work nobody shows off

On the page introducing his book, Emmanuel Ameisen offers a figure that unsettles many newcomers to ML. In his account, data scientists spend 95% of their time narrowing product use cases, handling data and deploying. Training models, the thing most courses are almost entirely about, is the small remainder.

Building Machine Learning Powered Applications: Going from Idea to Product (O’Reilly, 2020) is written for that 95%. Ameisen describes it as practical tips for the less-noticed stages of ML: building and labelling datasets, debugging models and deploying them.

For a forward deployed engineer, that list reads almost like a job description. Customers rarely lack algorithms. What they lack is a well-framed problem, a usable dataset and a system that keeps working once it meets real users.

The model is only one link

According to one reader’s notes on GitHub, the book’s running argument is that training a model is not enough to get an ML product to users.

The companion repository, hundredblocks/ml-powered-applications, has three parts: Jupyter notebooks illustrating the book’s concepts, an ml_editor library holding the case study’s core functions, and a Flask app. They map onto three familiar stages of FDE work: experiment, package as a library, then build an app for users.

The data you found may not be the data you need

The first idea worth keeping is a short warning in the book: people often confuse the dataset they found with the dataset they need. On a customer site this mistake surfaces in the first week, when someone hands over a database export and says “here’s the data”.

Picture a customer support company that wants “AI to help staff answer tickets better”. Taken literally, you would set out to generate whole replies, a problem that is broad, hard to measure and hard to debug.

A narrower framing is to predict whether a draft needs editing. The input is the draft, the output is a label, and the metric is the share of drafts a team lead rewrites.

Here is the trap. The ticket store the customer provides may keep only final replies, not the drafts before editing. There is plenty of data, but it lacks exactly the input-label pairs the problem requires.

So the first thing to do is ask whether the system records edit history. Ask that before promising the customer any number.

Look with your own eyes before trusting a metric

A review on Substack notes that getting labelled data can be very hard. It also cites a habit the book borrows from Monica Rogati: skim through lots of examples looking for anything odd. The advice is so simple it is easy to ignore, but it is cheaper than any dashboard.

Applied to the ticket example: before opening a notebook, read a few dozen real drafts. You may find things no column of numbers would flag, such as duplicate tickets, canned replies pasted verbatim or tickets written in several languages. Each finding becomes a concrete question for the next customer meeting.

When the system is wrong, make the model simpler

The third idea, according to the same reader’s notes, is to replace the model with something simple and then debug the whole pipeline. It sounds backwards, but it is the fastest way to learn whether the fault lies in the model or in everything around it.

For the ticket problem, the temporary “model” can be a single rule: flag as needing edits every draft shorter than some threshold.

If that rule produces absurd results in the interface, the bug is in data loading, field joins or display, not in the algorithm.

Only once the pipeline runs cleanly end to end does it make sense to swap the rule for a real model.

Where the book has aged

The book came out in 2020, before the LLM wave. The Substack review remarks that in the LLM era the book is due for an update but still useful. That is fair: the three ideas above do not depend on the type of model and still hold when the model is just an API call.

The second weakness FDEs should know about: a review on DEV Community faults the book for being thin on deployment detail. If you can fill only one gap, start with monitoring and rollback, because those two decide whether a deployment survives its first week on a customer site.

In the ticket example, monitoring means tracking the share of drafts team leads edit after go-live, so you see the model degrading before the customer complains. Rollback means returning to the simple rule or the previous model version with a single configuration change. Build both before the first demo.

Who should read it, and how

The book suits software engineers who know Python and basic ML but have never shipped a model to real users. Keep the repository open and run the notebooks alongside the chapters.

After that, spend most of your time on ml_editor and the Flask app. That is where the model has to become something other people can use, the part closest to what you will do for customers.

If you want the book to become a line on your CV, do not stop at rerunning the author’s repository. Apply the same three-part structure to a different public data source.

Write down where the data you found differed from the data you needed, and which bugs the simple baseline helped you catch. In FDE interviews, those decisions persuade more than any accuracy figure.

Algorithms will change many more times. The work nobody shows off, framing the right problem and looking at the data yourself, remains the reason customers hire FDEs.