sometimes twenty-nine. That's February: a short month.
About four weeks is normal. About twenty working days. To a large extent, not much progress is made in these 4 x 5 days. And yet, as always, more is being done each day. A few tests run. A few ideas are rejected. A few conversations move things forward. A few code changes turn out to be more important than expected.
Looking back over the past month, I found three lessons that stood out to me in the world of ML research and engineering:
- Sharing with others is important,
- documents are often overlooked until it is too late,
- and MLOps only make sense if they fit the environment in which they are to be used.
1. Exchange with others
If you read ML papers regularly, you know the pattern: for citations, usually only the first author's name is shown. Some names appear in the reference section only. Does that mean the first author did it all by himself?
It's rare. It is only in the special case that one author only writes the paper.
Most research lives on trade-offs. It lives on in conversations with co-authors, in the comments of your colleagues, in questions that force you to sharpen your thinking, and in close lessons that bring ideas that your field would not have produced on its own. Good research is often like getting into other people's places and learning just enough in their language to bring back something useful.
But this is not only true for academic papers. It is equally true in everyday engineering work.
A short conversation with your partner can save you hours of wandering down the wrong path. A five-minute conversation at the coffee machine can provide the one missing piece that makes your setup click. Even informal speech is important. Not every useful conversation begins in an organized meeting with a polished slide deck. Sometimes it starts with “by the way, I saw something unusual in the woods.”
This month reminded me of that again. A few small exchanges cleared things up much faster than meditation alone would have. Nothing spectacular, nothing noteworthy – just the usual, quiet amount of talking to other like-minded people.
2. Documents
Have you made any changes to your code?
Of course you did.
And you'll still remember the next day why did you make those changes? I hope so – it's only one day, after all. But what about a week later? After one month? After half a year?
That's when things don't seem right.
Most of the changes to the codebase are small and inconsequential. Not all bug fixes need a long explanation. If you're renaming a variable, fixing a bug, or fixing a harmless logging problem, that usually doesn't require special documentation. The same often goes for bug fixes that don't change any relevant conclusions from previous results.
But some changes are different.
Some changes change thinking. Others change the way data is pre-processed. Some relate to aspects of training, the logic of evaluation, or even description of the results. Those changes should be noted down, because they are the ones you will have forgotten when you return to the project later.
This month I was reminded once again, that documents are not primarily future collaborators. Your future is made for you. Today, when you are deep in the code, everything seems obvious. In three months, it won't. Then you'll look at a line, or a setting, or a mysterious data change, and ask yourself: “Why on earth did I do it this way?”
That's an easy question to ask.
3. MLOps are implemented
The goal of most ML research is, in some way, to generate trained models.
But I would bet that only a few of these types are actually used.
Most models remain where they were born: in books, on research servers, in internal presentations, or in papers. To go beyond that and put the model to productive use, you need more than the model itself. You need infrastructure, processes, monitoring, reproducibility, implementation strategies — in other words, tools and principles from MLOps.
If you read job ads in that area, MLOps often appear to be closely related to cloud providers: AWS, GCP, Azure, cloud native pipelines, managed services, distributed deployment environments. And yes, those tools matter. They are important, and in many settings they are the right choice.
But it's worth asking a simple question: is the target environment a cloud environment?
Take automated quality control into an industrial environment. Let's say the model is used directly in production, next to the machines that create the product. Do we really think that all relevant data is simply distributed from the company to some cloud? Especially if that data reflects the company's core processes and thus becomes part of its competitiveness? I doubt many companies are fully comfortable exposing critical manufacturing conditions in that way.
This is where a more focused view of MLOps becomes important.
MLOps are useful, yes. But it is not a collection of specific tools, but rather a collection of how to replicate the tool under changing conditions. Also, it should fit the area it is intended to be used in – not the other way around. The goal is not to force the entire shipping problem into the shape of any fashion application. The goal is to make the models usable under real constraints–to create the necessary tools for the problem at hand.
Sometimes that means cloud pipes. Sometimes it means being sent to a place. Sometimes it means restricted areas with limited connectivity, strict access control, or hardware constraints at the edge. In all these cases, the principles remain the same: versioning, reproducibility, monitoring, safe release, robust performance. But the implementation may look very different.
Concluding the thought
February was short, but empty. Like every other month of the year, there are plenty of lessons to learn:
- progress in ML often depends on interacting with others, not just thinking on your own,
- documentation is very important when you think you won't need it,
- and MLOps become valuable only if they adapt to the real environment.
I bet, next month, there will be another set of those lessons. They're not necessarily fancy, but the quiet lessons of “oh, yeah, that's probably a good way” mean it's done every day.
