Sarcasm aside, I've worked with people who fulfil at least any 2 of these behaviours, often-times most of them.
Choice excerpts:
* co-ordinating code between team members by having everyone periodically copy their code to one team members personal google drive, where one of them would then spend a day fixing merge conflicts by hand. When asked why they were doing it like that, would they like any help, git can probably solve these problems, they asserted that this worked fine with them.
* Spinning up machines in EC2, then keeping track of keys (new one for every machine obviously) by storing the Pem files in an S3 bucket when they remembered. This didn't happen, so instead we had a dozen machines nobody could get into anymore after they left...
* Calling Python code in another file, by running os.spawn, calling a python interpreter with the given file, passing in parameters a cmd line arguments, and getting the result by waiting for a specifically named file to be written to disk. When asked "why are you doing this?" I was told "because it was easier".
* All the python they wrote eschewed functions were possible, with everything at root-indentation & no import guards (so it couldn't be imported safely). Functions, when they were used relied heavily on global variables and other objects/imports/etc being present implicitly. There were also logging and json serialisation functions that were hand written. When I asked why this teammate did this they replied "it only took me a couple of minutes and it works? What's wrong?" Unsurprisingly, it didn't serialised datetime objects correctly...
* Re-inventing the functionality offered by Pythons multiprocessing/ Joblib libraries-but worse- by shelling out (again) and manually calling a shell script to detect the number of CPU's and then using x-args to spawn the python processes. "Well we've written it now and it works but maybe next time". Unsurprisingly, these processes would fail, silently and lose data.
* Using eval() in production code because they "couldn't figure out a better way of getting the value of the attribute" despite being told that getattr is safer and faster.
* Maintaining a spark cluster full of Jupiter notebooks unhelpfully named things like STEP_301.ipynb, STEP_405.ipynb and not anything that told you _what_ they did. Figuring out which notebooks called which other notebooks and where any bit of code came from was, unsurprisingly literally kafkaesque. These eventually got checked into git (root credentials, embedded images and all), in a single commit with the message "add to repo".
* Instead of reading the documentation, or using something like SqlAlchemy, code samples of how to connect to various different types of database (mysql, Postgres etc) were stored in a random google doc (once again, one of their personal accounts) and access was passed around.