Et si vous rédigiez une liste de "conseils généraux de développement"? Ensuite, vous pouvez le partager avec tout le monde une fois au lieu de donner constamment des conseils non sollicités.

Vous pouvez également le donner aux futurs étudiants et, espérons-le, les faire bien démarrer dès le premier jour.

Votre groupe de recherche tient-il des réunions hebdomadaires? Si tel est le cas, vous pouvez consacrer 5 à 10 minutes au début de chaque réunion à des hacks de flux de travail / développement qui, selon vous, seraient utiles. Si votre groupe n'a pas de réunions périodiques, cela peut valoir la peine d'en mettre en place, même uniquement à cette fin. Les étudiants peuvent ne pas aimer cela au début, mais l'augmentation nette de la productivité sera bénéfique pour tout le monde. De plus, vous n'aurez pas à signaler les inefficacités individuelles à plusieurs étudiants (du moins pas aussi souvent).

J'implémente quelque chose de similaire lorsque j'enseigne, mais cela est plus orienté vers les étudiants de premier cycle. Je discute de choses comme comment et où postuler pour des bourses et des stages, des conseils pour entrer dans les études supérieures, naviguer dans la politique du lieu de travail, et aussi quelques éléments simples de flux de travail de temps en temps. Les étudiants ont commenté que cela a été très bénéfique.

J'aime l'idée de @Nate Eldredge de proposer une liste de conseils de développement généraux, mais je pense que cela seul pourrait avoir quelques lacunes. Il peut être fastidieux d'écrire quelque chose de vraiment de haute qualité qui couvre tout. Certains élèves peuvent même ne pas le lire (mais ces élèves ne feront probablement pas non plus attention à ce que vous dites pendant une réunion). D'autres élèves pourraient ne pas comprendre vos suggestions jusqu'à ce qu'ils les voient en pratique. Cela m'est arrivé l'autre jour. Je connaissais Tramp d'Emacs, mais je n'ai jamais compris comment le mettre en œuvre. J'ai vu un tweet avec un .gif animé montrant comment cela fonctionnait, et je l'utilise tous les jours depuis. Peut-être que discuter de ces choses lors de réunions et construire une liste de conseils de développement au fil du temps pourrait bien fonctionner.

Vous pouvez également définir certaines exigences de groupe qui vous simplifient la vie. Par exemple, vous pouvez demander à votre groupe d'utiliser Dropbox (ou quelque chose de similaire) pour partager des documents, et dans le processus qui peut les encourager à l'utiliser pour leur propre matériel. (Vous pouvez conserver le document des conseils de développement dans un dossier partagé sur Dropbox pour commencer!) Je pense que souligner les inefficacités en personne pourrait valoir la peine, mais vous devrez certainement choisir vos batailles et ne le faire que de temps en temps.

Certains des commentaires indiquaient que plusieurs des recommandations du PO sont "objectivement fausses", mais je pense que cela manque le point. Si un chercheur plus expérimenté voit des façons dont son groupe pourrait être plus efficace, cela vaut probablement la peine d'être partagé même sans posséder le flux de travail parfait. Partager du code via Dropbox n'est peut-être pas la meilleure solution, mais ce serait certainement mieux que d'envoyer des fichiers par e-mail. (Je ne suis même pas sûr que l'OP suggérait que le groupe partage le code sur Dropbox; ce n'est qu'un exemple). De plus, il est possible que les élèves aient des suggestions pour le groupe (ou même le chef de groupe), et celles-ci pourraient être étoffées en rassemblant tout le monde.

Un commentaire suggérait également de ne pas se lancer dans une guerre sainte Vim / Emacs ... mais les étudiants connaissent-ils Vim, Emacs, d'autres éditeurs / IDE et leurs capacités en premier lieu? Je ne savais certainement pas à ce sujet en tant qu'étudiant à la maîtrise, et développer des compétences avec un éditeur m'aurait énormément aidé (je ne suis pas dans un domaine STEM, donc ces outils sont rares; je ne suis pas sûr du domaine de l'OP, mais encore une fois, ce n'est qu'un exemple). Vous pouvez certainement discuter des fonctionnalités et des capacités sans entrer dans une guerre sainte. Une simple exposition peut être extrêmement bénéfique.

Mon approche serait beaucoup plus subtile par rapport à la méthode de João. Au lieu de leur dire quoi faire, je leur montrais mon flux de travail en répondant à une question similaire. Assurez-vous de le faire sur votre propre ordinateur, ne «conduisez» pas sur le PC de quelqu'un d'autre.

Un exemple serait de leur montrer votre "méthode de développement", avec une grande fenêtre de code. Utilisez les raccourcis ou la CLI pendant qu'ils regardent ce que vous faites. Vous pouvez dire quelque chose comme "foobar me fait gagner beaucoup de temps", mais pas trop. Les élèves qui souhaitent une plus grande efficacité dans leur flux de travail choisiront naturellement ce qui fonctionne pour eux.

"Vous pouvez amener un cheval à l'eau, mais vous ne pouvez pas le faire boire"

Personnellement, c'est ce que je dis à mes élèves au début de leur travail, et ma justification entre parenthèses.

1. Utilisez Dropbox / GDrive / qu'est-ce que vous avez pour les sauvegardes (si vous perdez votre travail 1 semaine avant la soumission, vous êtes foutu).

2. Mettre en place un wiki pour la documentation du projet sur le serveur de la faculté (si vous ne prenez pas de notes plus tard, vous ne savez pas quoi écrire dans la thèse).

3. Utilisez Mendeley pour la gestion des références (passez du temps à écrire des .bib ou à rédiger votre thèse, votre choix).

4. Configurer LaTeX et y écrire leur thèse (Word est bon pour jusqu'à 3 -page documents).

5. Utilisez des machines virtuelles pour leur environnement de travail et effectuez des sauvegardes régulières (ne perdez pas de temps à configurer les choses encore et encore).

6. Envoyez un e-mail aux deux superviseurs en CC et utilisez toujours «Répondre à tous» aux e-mails liés au travail (je ne peux pas vous aider si je ne sais pas ce que vous faites).

7. Présentez-vous souvent au laboratoire (rien qu'en discutant avec des chercheurs chevronnés, vous découvrez les moyens les plus rapides et les plus intelligents d'atteindre vos objectifs).

8. Envoyez-moi des rapports d'étape souvent (si vous vous ne demandez pas d'avis, je ne sais pas si votre travail est prêt pour eux).

(Facultatif)

1. Obtenez un SSD pour leur ordinateur portable s'ils peuvent se le permettre (la patience vaut plus que l'argent).

Quant à m'empêcher de tout signaler, c'est facile: c'est leur travail, et leur choix faire un bon ou pas. Selon les mots de Morpheus, "Je ne peux que vous montrer la porte. C'est vous qui devez la franchir."

Choisissez les quelques éléments qui sont importants et comptent comme «bonnes pratiques», (être sensé ou avoir des normes sur les noms de fichiers et de variables me semble beaucoup plus important que la taille de la fenêtre d'édition ou du raccourci clavier). Donnez des règles ou des exemples qui montrent les directives en action et allez-y et soyez un peu pointilleux à ce sujet.

Les autres choses - (utilisez une fenêtre d'édition plus grande, un raccourci) ne sont vraiment pas «importantes» en tant que bonnes pratiques. Se tenir au-dessus de l'épaule d'un élève et dire, appuyer sur cette touche, etc. est vraiment irritant et peut être accablant si trop d'informations / de détails leur sont lancés. (Quel détail est important, qui est juste que vous êtes utile?) Et, ils peuvent avoir des raisons assez valables après le temps de le faire différemment (ils peuvent trouver d'autres raccourcis qui fonctionnent mieux avec leur `` style '' ou que vous trouvez utiles si vous observez-les.

Cependant, cela étant dit - il est très vrai que les techniques qui leur permettront de gagner du temps et qui leur éviteront la frustration ne sont pas immédiatement évidentes pour les novices. J'ai trouvé que le meilleur moyen est de laisser quelqu'un jouer avec les outils d'abord afin qu'ils puissent rencontrer certaines des frustrations. Mais surtout, répondez simplement aux questions de base et s'il y a une question spécifique sur les moyens `` plus faciles '' de le faire, dites-leur. Puis plus tard - faites le one-on- un pour montrer comment vous feriez la tâche en soulignant vos propres pratiques et comment ils évitent des frustrations particulières. Cependant, à ce stade, laissez-le ensuite choisir de le faire comme il le trouve le mieux. Il n'est pas utile de continuer à le suggérer à chaque fois vous les aidez.

Bien que je ne sois pas impliqué dans la formation des étudiants au codi ng, nous devons former les utilisateurs novices sur un équipement un peu délicat et qui nécessite une longue période de formation pour devenir expert, de sorte que le processus présente quelques similitudes.

Choisissez les aspects qui sont presque non négociables car ils sont importants. Ne vous inquiétez pas trop lorsque les novices continuent de choisir d'ignorer les conseils que vous leur avez donnés qui sont basés sur ce que les experts ont généralement trouvé des stratégies `` utiles '' pour se faciliter la vie.

@haff a suggéré dans un commentaire:

Si votre groupe de recherche tient des réunions hebdomadaires, vous pouvez également consacrer environ 5 minutes au début de chaque réunion à la démonstration des hacks de développement / workflow.

Une idée intéressante! Maintenant, modifions un peu les choses:

Consacrez du temps de réunion de groupe (pas nécessairement 5 minutes seulement, et pas nécessairement à chaque réunion) au round robin, en donnant aux élèves la possibilité de partager le leur des hacks de flux de travail les uns avec les autres .

Informez-les à l'avance dans un e-mail afin qu'ils puissent réfléchir au (x) type (s) de workhack qu'ils aimeraient à partager ou à faire une démonstration. En d'autres termes, ne les surprenez pas. Et permettez aux individus de choisir de ne pas partager quelque chose.

En outre, vous pouvez organiser des réunions de type atelier où quelqu'un se porte volontaire pour être dans le fauteuil de démonstration, en train de développer du code ou de tester à la volée, en quelque sorte comme une classe de maître dans un département de musique. Invitez ensuite les élèves à faire des commentaires constructifs, l'objectif étant que chaque élève trouve quelque chose à féliciter. S'ils veulent faire des suggestions constructives sur la façon de déboguer plus efficacement ou plus efficacement, c'est bien, mais l'objectif principal devrait être d'apprendre à fournir des commentaires positifs aux pairs .

Il Il est remarquable de voir à quel point les conseils et corrections d'un camarade sont plus efficaces que de les faire tous venir du professeur .

Je ne vois rien de mal à faire des suggestions. Après tout, vous leur enseignez et il ne semble pas déraisonnable de donner des conseils sur la façon d'améliorer leur façon de travailler, surtout si la suggestion est de rendre quelque chose objectivement plus efficace.

Je suis tout à fait d'accord sur le fait que ce n'est peut-être pas une bonne chose de forcer les élèves à travailler d'une certaine manière si cela n'a vraiment pas de sens pour eux. Mon expérience est certainement que l'une des choses les plus utiles dans le travail avec une personne expérimentée (que ce soit dans un cadre d'enseignement formel ou non) est qu'elle connaîtra beaucoup d'astuces utiles qui ne sont pas nécessairement intuitivement évidentes.

Une fois que vous avez fait la suggestion, vous pouvez leur laisser le choix d’agir ou non, mais au moins, ils ont les informations.

TL; DR: Faites une distinction entre «trucs et astuces» et «directives / bonnes pratiques». Donnez des indices sur le premier et essayez d'appliquer le second.

Si c'est possible dans votre situation, vous voudrez peut-être organiser une petite présentation. Quelque chose comme «trucs et astuces EditorX». Où vous pouvez partager avec eux quelques trucs et astuces pour mieux utiliser l'éditeur, sans signaler aucun étudiant en particulier.

Ce n'est pas si différent de l'industrie. Je travaille en tant qu'ingénieur logiciel, et nous avons des conférences hebdomadaires où nous pouvons faire une démonstration sur quelque chose d'intéressant dans le domaine. Toutes les quelques semaines, quelqu'un donnera une petite démo de quelques trucs et astuces. Tout le monde est encouragé à le faire.

L'avantage de cette approche, pour moi, est que vous faites en sorte que d'autres personnes voient l'avantage (développement plus rapide, par exemple) avec une petite démo. Vous les rendrez également curieux de trouver d'autres trucs et astuces à partager.

Ceci étant dit à propos des trucs et astuces, il y a aussi d'autres choses qui ne sont pas simplement des trucs et astuces, mais plutôt des directives et des bonnes pratiques qui devraient être suivies. Que vous utilisiez ou non un raccourci est tout à fait facultatif, ou que vous vous rendiez compte qu'il existe un paramètre de saisie sans latence dans IntelliJ (un IDE) et que vous souhaitiez l'utiliser. Pourtant, d'un autre côté, nous avons des choses comme le contrôle de version, des noms de variables sensibles, la conservation de la documentation, ce qu'ils devraient vraiment faire. La manière dont ils l'utilisent est à nouveau dans la partie "trucs et astuces", mais ils devraient au moins connaître les avantages de l'utiliser et être fortement encouragés à le faire.

La façon dont je faisais cela lorsque j'enseignais (dans le cadre scolaire), c'était en imposant l'utilisation de ces choses. Je ne sais pas si vous pouvez appliquer cela à votre place, mais dans la mesure du possible, je le ferais. Pouvez-vous définir des «directives» pour votre groupe? Si tel est le cas, appliquez les directives de codage et faites-les documenter quelque part. Mettez tout ce qui est pertinent dans ce document, par exemple si vous voulez un étui de serpent ou un étui de chameau. Donnez quelques conseils pour trouver de bons noms de variables et de classes. Appliquez le pushing vers git (svn, ..) et montrez un exemple de bons messages de commit.

(Un moyen d'imposer un bon style de code pourrait être d'utiliser un outil qui vérifie la syntaxe, les modèles de noms de variables, etc. Il existe de bons linters disponibles pour de nombreuses langues)

Le ceux à qui j'ai enseigné n'ont pas toujours vu les avantages de ces choses - mais à la fin ont tourné autour de 180 degrés. Cela m'a fait plaisir de voir les lignes directrices respectées et de voir les étudiants en voir les avantages.

c'est un processus, je suis d'accord, mais si vous ne signalez pas les "erreurs", comment sauraient-ils qu'elles pourraient être améliorées?

Personnellement, je pinaille tout, et jusqu'à présent cela a bien fonctionné. J'aime aussi clarifier ce point précis et n'oubliez pas de les féliciter quand ils font des choses correctement du premier coup (sinon, il semble que vous vous concentrez trop sur les commentaires négatifs).

Bien sûr, c'est Il est important de se rappeler qu'en fin de compte, ce n'est pas votre décision. Vous présentez tous les côtés, les avantages, les inconvénients, et ils décident. Une autre façon de dire cela est de mentionner chaque chose au plus trois fois :)

Je vous suggère d'aborder cette partie de l'enseignement de la programmation comme si vous étiez metteur en scène de théâtre.

Dites à vos élèves que vous prendrez le temps d'observer chacun d'eux travailler et de leur donner des notes par la suite.

Observez un élève et prenez des notes. Gardez le silence pendant l'observation.

Après votre observation, «donnez vos notes:» discutez avec l'élève de vos observations sur son travail et proposez vos suggestions d'amélioration. De cette façon, vous proposez vos suggestions de manière structurée et ne les harcelez pas. Assurez-vous de leur dire qu'ils ne sont pas notés ou notés à ce sujet.

Vous pouvez également les encourager à faire cela les uns pour les autres.

Je vais essayer de répondre à la question que vous posez en fait - c'est-à-dire les questions sur vous , pas vos élèves:

Comment éviter d'interférer avec le travail inefficace mais pas mal des élèves?

... et ...

Y a-t-il un bon moyen de [...] ne pas être déconcerté si les élèves ne les utilisent pas?

(Et ma réponse concerne strictement les conseils qui n'ont pas été demandés, comme dans votre cas. Rien de tout cela ne s’applique évidemment lorsque vos élèves vous demandent comment vous améliorer.)

Malheureusement, vos questions vous préparent à quelque chose de très profond. Il y a deux faits qui peuvent rendre des gens comme vous (ou moi), qui ont des techniques très efficaces pour faire des choses , très mécontents en voyant d'autres personnes avancer extrêmement lentement - pour une raison quelconque, pas nécessairement liée à leur intelligence du tout.

1. Toutes les techniques (d'utilisation d'un éditeur, d'un outil de téléchargement ou autre) ne fonctionnent pas de la même manière pour chaque personne. Ce que vous pouvez trouver très évident (par exemple, avoir la plupart des raccourcis clavier d'Emacs, être capable d'envisager une bonne macro de clavier à la volée directement de vos doigts pendant l'édition, etc.) peut être totalement impossible pour les autres. Vous êtes arrivé à vos techniques en y réfléchissant longuement et sérieusement, ou en trouvant intuitivement quelque chose qui correspond à la façon dont votre cerveau est câblé. Cela ne s'applique pas nécessairement à d'autres personnes. D'où les guerres VI / Emacs, Windows / Linux, PC / Mac, etc.
2. Tout le monde n'est pas réellement capable de prendre des conseils, aussi bien intentionnés soient-ils, et de les appliquer à leur propre travail, pour différentes raisons. En fait, d'après mon expérience dans tous les lieux de la vie (université, travail, famille, amis), il n'y avait que très, très peu de personnes capables de suivre tout des conseils non sollicités quoi que ce soit.

Maintenant. Je n'entrerai pas dans les raisons spécifiques de ces deux faits, car ils sont nombreux et cela n'a pas d'importance. Juste un exemple: pour "1." l'autre personne pourrait tout simplement ne pas le savoir; ses «routines de pensée» pourraient ne pas correspondre au fonctionnement d'un éditeur, et ainsi de suite. Pour "2.", vous ne pourrez peut-être pas l'expliquer avec les mots qu'ils ont besoin d'entendre, ils pourraient être bloqués par l'orgueil, etc. Il peut y avoir beaucoup d'autres raisons, mais ma réponse ne concerne pas du tout ces raisons. Bien sûr, pour beaucoup d'entre eux, il existe un moyen de contourner le problème. Mais vous vous retrouverez toujours dans la position où vous ressentez de la douleur parce que vous voulez vraiment aider mais ils ne comprennent tout simplement pas.

Comment se retenir

Faites-le. Asseyez-vous patiemment pendant qu'ils font leur travail inefficace. Oui. Évidemment, vous pouvez leur montrer comment vous travaillez, mais franchement, ils le voient simplement en vous regardant, si vous travaillez dans un environnement de pairs. Vous n'avez pas besoin d'en faire une "chose". Ce sont des étudiants et devraient être utilisés pour utiliser leur cerveau; S'ils vous voient travailler à une vitesse fulgurante pendant qu'ils prennent un temps fou, ils devraient être capables de comprendre qu'il se passe quelque chose. Le fait est que ce n’est pas vous qui devez faire quelque chose. Ce n’est pas vous qui êtes responsable ici.

S'ils voient que vous travaillez rapidement, ils sont libres de

• Vous demander de vous expliquer comment vous le faites.
• Vous vous sentez mal et s'entraîner à la maison.
• Asseyez-vous avec leurs amis et "comparez vos notes".
• Achetez un livre et lisez-en quelque chose à ce sujet.
• Téléchargez les outils que vous utilisez et découvrez-les.
• Ou ne vous en faites pas du tout et tenez-vous-en à leur lenteur.

Et probablement d'autres choses.

Comment ne pas s'énerver s'ils n'utilisent pas vos astuces

Le secret pour ne pas être déconcerté est de penser à cela d'avance et de supprimer l'idée que vous pouvez en quelque sorte changer quelqu'un d'autre de votre tête. Vous ne pouvez jamais changer un autre être. Vous pouvez les persuader, les forcer, donner l'exemple ou autre, et vous pouvez profiter des situations où ils s'améliorent effectivement, mais vous ne pouvez pas vraiment les faire changer.

Donc, en pure logique, cela n'a aucun sens d'être énervé. C'est un cas de ne pas voir la réalité telle qu'elle est. Si vous acceptez que les choses sont telles qu’elles sont, le fait de devenir énervé diminuera, à coup sûr.