Every hour you invest into Docker is an hour you could have
used to make your app better.
Except that your teammate has lost 2 hours setting up all the necessary things to work with the code for later realize half the errors were caused by mismatching Python versions.
After you solved all the development environment problems and then went on merrily on your code, comes the deployment time and then the company (doesn´t matter if it's you or an Ops team) loses lots of hours fixing problems with the code once put on Docker (I have seen things...) and making it ready to deploy it.
In my opinion, avoiding Docker at the initial steps it´s just kicking the can forward just to be hit in the face by it later. Coding inside Docker comes with a change of mindset for most developers I worked with. The mindset changed more to a production state code than "it´s my local code so I will just do this thing and fix it later".
Except that your teammate has lost 2 hours setting up all the necessary things to work with the code for later realize half the errors were caused by mismatching Python versions.
After you solved all the development environment problems and then went on merrily on your code, comes the deployment time and then the company (doesn´t matter if it's you or an Ops team) loses lots of hours fixing problems with the code once put on Docker (I have seen things...) and making it ready to deploy it.
In my opinion, avoiding Docker at the initial steps it´s just kicking the can forward just to be hit in the face by it later. Coding inside Docker comes with a change of mindset for most developers I worked with. The mindset changed more to a production state code than "it´s my local code so I will just do this thing and fix it later".
Totally with you on this one. Reproducible environments are amazing! And automation beats documentation, which is a clear win for using Dockerfiles.
My point is not about avoiding Docker, but about investing the right amount of energy at an appropriate time in the project's context.