I’ve had that inkling for a while that it’s difficult to explain the nuance, but also make it appealing on the internet at the same time. It may not be difficult to explain it, but it seems really difficult to sell it.
Running some code whenever your Jupyter notebook starts is handy and easy.
Up-to-date info on language identification libraries usable in production. Accuracy, language coverage, speed and memory consumption. Everything you need as an ML engineer to pick a library quickly.
Github Actions: how to use pyenv's python version - one from .python-version file.
If you're using only requirements.txt to manage your dependencies, you're in trouble.
The smallest conda cheatsheet you'll find around.
I briefly describe each tool (pip, venv, pip-tools, pyenv, conda, pipenv, poetry and Docker), why it’s created and the problems it’s tackling. You can find a table summarizing all the information and the usual setups people use.
You've entered the data scientist role and nobody told you that you actually have to write code like a software engineer? It's classic. CS and data engineers complain that your code isn't written "the right way". Worst of all, you know they're onto something, but nobody can help you apart from saying you'll have to learn software engineering.
Yes, you already know Jupyter notebooks enable bad code design. They often have some hidden state, you execute cells out of order so notebooks are often not even runnable from scratch. And engineers running production complain. They often throw your code away and rewrite everything from scratch because it’s not “production code.”
“Every time my notebook shuts down and restarts, I lose notebook extensions and have to reinstall them from the terminal”, my teammate said. Eventually, he gave up reinstalling them.