front matter

 

preface

Even as a young boy, I was stubborn. When people would suggest simple ways of doing things, I would ignore advice, choosing to always do things the hard way. Decades later, not much changed as I shifted through increasingly challenging careers, eventually landing in the realm of data science (DS) and machine learning (ML) engineering, and now ML software development. As a data scientist in industry, I always felt the need to build overly complex solutions, working in isolation to solve a given problem in the way that I felt was best.

I had some successes but many failures, and generally left a trail of unmaintainable code in my wake as I moved from job to job. It’s not something that I’m particularly proud of. I’ve been contacted by former colleagues, years after leaving a position, to have them tell me that my code is still running every day. When I’ve asked each one of them why, I’ve gotten the same demoralizing answer that has made me regret my implementations: “No one can figure it out to make changes to it, and it’s too important to turn off.”

I’ve been a bad data scientist. I’ve been an even worse ML engineer. It took me years to learn why that is. That stubbornness and resistance to solving problems in the simplest way created a lot of headaches for others, both in the sheer number of cancelled projects while I was at companies and in the unmaintainable technical debt that I left in my wake.

acknowledgments

about this book

Who should read this book

How this book is organized: A road map

About the code

liveBook discussion forum

about the author

about the cover illustration