4 ms·

> folks I saw who did poorly it was because they didn't realize that you could be both the smartest person in the room and the least capable at the same time A

> folks I saw who did poorly it was because they didn't realize that you could be both the smartest person in the room and the least capable at the same time Any advice to deal with this kind of people would be much appreciated. I had a hard time trying to convey basic software engineering practices such as not hard-coding file paths, using version control instead of filenames to manage versions, removing dead code, keeping the code at least moderately DRY, more or less sticking to a code convention, etc. They would use all their reasoning power to refute what they would see as meaningless pet-peeves. It was tiring. I tried to provide pointers so they could find out for themselves but they gave it zero interest. At the moment I've given up. The simple fact the OP is asking this question here means she or he will almost certainly do greatly.

ChuckMcM 8y ago
Sadly it is very much a person by person process. In my experience with folks like this there are people they can "hear" advice from and those that they cannot. One option is to talk to their original PhD adviser (if they are still around) and get them on board. You and the adviser's interests are aligned, you both want the person to succeed and to do so they have to be able to hear your guidance on how to be better at the job. Sometimes they will be able to hear it from someone they have already put in the 'trusted advice' category.
AnimalMuppet 8y ago
If you have two such people, you might get there by making each of them the sole maintainer of the other's code. They might - might - see the problems when it's being done to them, instead of them doing it to others. More in general, the problem is that these people have been in an environment where programs were small enough that those practices didn't cause problems. They've moved into an environment where the scale is different, and those practices now cause real pain. Until they experience the pain (rather than just being told about it), they aren't really going to get it.

ChuckMcM 8y ago

Sadly it is very much a person by person process. In my experience with folks like this there are people they can "hear" advice from and those that they cannot. One option is to talk to their original PhD adviser (if they are still around) and get them on board. You and the adviser's interests are aligned, you both want the person to succeed and to do so they have to be able to hear your guidance on how to be better at the job. Sometimes they will be able to hear it from someone they have already put in the 'trusted advice' category.

AnimalMuppet 8y ago

If you have two such people, you might get there by making each of them the sole maintainer of the other's code. They might - might - see the problems when it's being done to them, instead of them doing it to others. More in general, the problem is that these people have been in an environment where programs were small enough that those practices didn't cause problems. They've moved into an environment where the scale is different, and those practices now cause real pain. Until they experience the pain (rather than just being told about it), they aren't really going to get it.