We deal with fairly large volumes of data on a frequent basis so it would not make sense for each data scientist to create a copy within their own environment. Everyone works off a centralized data source and we provide them with Jupyter/Spark in an internal cloud environment.
There are companies like the one I work for that are willing to hire experienced engineers and then train them on their chosen technical stack. The job engineering descriptions on the Rover.com career page include "Rover’s web app is written in Python and built on the Django framework. Nevertheless, we are willing to train people in Python and Django, so first and foremost are looking for good engineers who are eager to learn."
I think there's another aspect...which is that there is the job and the tools to do the job. The framework is the tools...the job is, in Rover's case, building a web site.
I disagree. Makefile syntax has been a barrier to entry for many engineers I've worked with. When I saw this I got very excited. I haven't used it yet, but I'm looking forward to playing with it next week.
Don't get me wrong, I love make, but I also can admit it's old and has some legacy warts. Phony targets, double dollar signs, the tab thing you mention. I've learned to be ok with it, but I've seen it be a barrier to adoption.
I'm not saying it should be a barrier, I'm saying it is a thing I have experienced in my career.
It sounds like you're both using it for different purposes. What the parent commenter meant is that this doesn't completely overlap with Make's feature set.
Make has intrinsic knowledge about how to build, compile, detect changes and recompile source code, and more. If you're using make solely as a task runner then yes, this could be a much more developer-friendly replacement.
