Matt Sharp defines clean code by how quickly another person, or your future self, can understand it.
2
Data scientists should write clean code during exploration because quick analyses are often copied into later work.
3
Shopify's Merlin platform gives data scientists a managed path from machine learning projects to online inference services.
Summary
Matt Sharp argues that data scientists should treat programming as part of their craft, even when their main work involves statistics, analysis, or research. He defines clean code as code that another person can understand quickly, with clear names and a structure that supports collaboration. He recommends using notebooks for fast iteration while keeping cells sufficiently self-contained to move code into scripts or libraries later. Matt also describes Merlin, Shopify's machine learning platform, which is built on Ray and supports distributed processing, project setup, dependencies, deployment, and online inference. Shopify uses machine learning for work such as content filtering, recommendations for new merchants, internal analysis, and product workflows that use GPT. The conversation ends with Matt's forthcoming book, LLMs in Production, which he is writing with Chris Brousseau for engineers who need to deploy and maintain language models rather than study only their theory.
Matt Sharp defines clean code by how easy it is to understand. He asks whether someone can return to the code six months later and catch up within seconds or minutes. The same test applies when another person joins the project. Naming is one of the largest parts of this work. Matt gives the example of a table called "locations" that contained zip codes, merchant addresses, and online locations. The broad name caused people to reuse it incorrectly, and nobody wanted to remove it after it had been integrated into other systems. Names should be specific enough to explain what they contain while broad enough to cover their intended use cases.
Data scientists need software engineering habits from the start
Matt says Shopify expects clean code immediately, including from interns. The company does not expect an intern to solve every problem, but it does expect the person to write understandable code. He contrasts this with data science environments where code is often treated as acceptable once it works. In his experience, that led to bugs and wasted time because there was nobody nearby who understood the coding side of the work. He describes data scientists as specialized programmers who use statistics and research, and says their value reaches other people through the code they write.
Notebook cells should be organised so they can become project files
Matt still sees value in Jupyter notebooks because they make it easy to inspect data and iterate quickly, but he dislikes their kernels and the hidden state that can make a notebook hard to reproduce. He recommends treating a cell like a file in a Python project rather than forcing every cell to do only one small thing. A cell can contain its own imports, a class, or a related group of functions. If each cell runs independently, moving the work into a Python script or library becomes a matter of copying the cells and adjusting imports. He also recommends keeping a notebook of cleaned-up reference code for future analyses.
Exploratory analysis deserves clean code because it gets reused
Matt rejects the idea that clean code only matters once a project reaches production. He says exploratory analysis is often copied from an earlier notebook, then edited and repaired as new work develops. Poor code gets carried forward through that process. His suggestion is to maintain a notebook of reusable, cleaned-up functions and notes, so copying code starts from a dependable reference. He points out that analysts read their own code far more often than they write it. Even five minutes later, clear names and structure make it easier to understand what was done. He also encourages data scientists to open an IDE and learn the code completion and inspection tools available there.
Clean code supports clean data and reliable data work
Matt describes a controversial LinkedIn post titled "clean code is greater than clean data." His reasoning is that data ultimately comes through code, including databases, pipelines, and other systems that create or transform it. Poor code can therefore produce poor data and make analysis and model training harder. He connects this view to data contracts and the work Chad Sanderson discusses around models and APIs. Matt is direct that clean code requires effort from data scientists, which is one reason some resist it. He says the community has become more receptive to these practices than when he first started writing about them.
Merlin gives Shopify teams a managed route to online inference
Matt describes Merlin as Shopify's machine learning platform. It is built on Ray, with a head node and worker nodes that make parallel processing easier for large datasets. Merlin provides command-line tools to create a project, manage dependencies, build images, and define resource needs without requiring each data scientist to manage Terraform. It also handles autoscaling. Matt's work focuses on online inference, including helper functions that create a REST API and place a model inside the Shopify ecosystem. The platform includes a pipelines library for retrieving data, transforming it, and distributing the work through Ray.
Shopify applies machine learning to merchant and platform workflows
Matt names several applications running under Shopify's platform. The team works on filtering that can keep unsuitable or violent content from appearing in unrelated shopping experiences. Models also recommend next actions to new shop owners by learning what type of store they are building and following their progress. Internal models help Shopify understand its own data, trends, promotions, and outreach. Shopify has also integrated GPT into product creation workflows, where it can suggest descriptions for products such as sunglasses and generate tags. Matt presents these as examples of many possible projects that must be prioritised by their expected value.
The LLMs in Production book focuses on deployment and maintenance
Matt is writing LLMs in Production with Chris Brousseau, who works at MasterCard and brings natural language processing experience. Matt brings experience in getting models into production and making them usable outside a project workspace. The book is aimed more at machine learning and data engineers and software engineers than at readers who only want the theory behind training large models. Planned projects cover cloud deployment, a chatbot or similar application, code completion using a model tuned on private data, and running a small language model on a Raspberry Pi. The authors are publishing early access through Manning's MEAP programme.
