Thanks both, agree with a lot of the points made and great to hear about what you are doing for engineers who want to use python. Connor, I valued hearing your view on the feasibility of shared capacity checking modules and the advantages of developing a personal tool box, it is certainly a new perspective for me.
At my company I've been a big advocate and practitioner of using and developing well documented and interrogable shared python modules. These are hosted on our internal Gitea. The shared tools implement company specialised knowledge, contain reliable building blocks, and allows us to continuously improve across projects. In many cases they are quicker to use then setting up your own functions from scratch. Indeed, they are seen as one of the big advantages of using python in our field. Reinventing the wheel is generally discouraged. And since Engineers do not work in isolation, I would worry that everyone having their own toolkits and scripts makes it a lot harder for someone else to pick up or review the workflow, should that be required.
But it was helpful for me to consider that maybe default use and development of the shared tools (where they implement non project specific code) is not always the best option. As you note, not everything we do is intended to form part of the final calculation report, and engineers are often sole decision makers, so quick results for exploratory cases that the individual can trust does have value. I agree creating your own tools is great for personal skills development, can be more direct in certain circumstances and easier for the engineer using it (who also made it) to trust and understand. And you probably know better than most (!) the time and effort required to govern, document and package shared tools so that they are truly 'collaborative' and easy to integrate into the workflows of other engineers.
So my question is when should you create, contribute to and use a shared tool, and when should you do your own thing- and would you agree it is ok to have a shared package delivering capacity checking where interpretations are clearly documented and represents best practice as understood by the business unit owning the tool?
Thanks both, agree with a lot of the points made and great to hear about what you are doing for engineers who want to use python. Connor, I valued hearing your view on the feasibility of shared capacity checking modules and the advantages of developing a personal tool box, it is certainly a new perspective for me.
At my company I've been a big advocate and practitioner of using and developing well documented and interrogable shared python modules. These are hosted on our internal Gitea. The shared tools implement company specialised knowledge, contain reliable building blocks, and allows us to continuously improve across projects. In many cases they are quicker to use then setting up your own functions from scratch. Indeed, they are seen as one of the big advantages of using python in our field. Reinventing the wheel is generally discouraged. And since Engineers do not work in isolation, I would worry that everyone having their own toolkits and scripts makes it a lot harder for someone else to pick up or review the workflow, should that be required.
But it was helpful for me to consider that maybe default use and development of the shared tools (where they implement non project specific code) is not always the best option. As you note, not everything we do is intended to form part of the final calculation report, and engineers are often sole decision makers, so quick results for exploratory cases that the individual can trust does have value. I agree creating your own tools is great for personal skills development, can be more direct in certain circumstances and easier for the engineer using it (who also made it) to trust and understand. And you probably know better than most (!) the time and effort required to govern, document and package shared tools so that they are truly 'collaborative' and easy to integrate into the workflows of other engineers.
So my question is when should you create, contribute to and use a shared tool, and when should you do your own thing- and would you agree it is ok to have a shared package delivering capacity checking where interpretations are clearly documented and represents best practice as understood by the business unit owning the tool?