For instance Docker is a problem instead of a solution if part of your system is a several-gigabyte language model that changes frequently.
Docker can be a headache at times, but being able to maintain a consistent environment is very handy. For the large binary resources (trained models, dataset, etc) I've found it easy enough to just use docker volumes to mount read only resources. Other people have resorted to leaving read only assets on the local network which might be fast enough for your needs. As long as you're not unintentionally copying data, mounting a TB of data read only takes no time in my experience.
for myself and many of my unhappy colleagues, we would love to push code to prod and build software but we're cut off from that part of the job due to the growth of data engineering and ML engineering roles as their own disciplines/roles.
instead we're left with the boring one-off 'make a slide deck report and some bar charts' type work instead getting the privilege of getting our hands dirty and actually building something.
i guess that just goes to your point that we're all unhappy in different ways.
I think:
1. The average data scientist thinks they are too good to have a reproducible build, use version control responsibly, or use software engineering practices to put their practice on wheels. You can get them to make a report but they hate the thought of making a system that makes reports. I always hear things like "I don't want to get my hands dirty"
2. I tell people (especially those who would hire or supervise a data scientist) that they need to make a training set of 1000 to 10,000 examples if they want to train a model. Often that's the last I hear from them. Otherwise I hear some guff about they are too good to do that. Good luck getting data from Kaggle to fit your business problem.
What anecdotes do you have?