E se você escrevesse uma lista de "dicas gerais de desenvolvimento"? Então, você pode compartilhá-lo com todos uma vez, em vez de constantemente dar conselhos não solicitados.

Você também pode dá-lo a futuros alunos e, com sorte, fazer com que eles tenham um bom começo no primeiro dia.

O seu grupo de pesquisa tem reuniões semanais? Nesse caso, você pode dedicar de 5 a 10 minutos no início de cada reunião para hacks de fluxo de trabalho / desenvolvimento que você acha que seriam úteis. Se o seu grupo não tiver reuniões periódicas, pode valer a pena implementar algumas, mesmo que apenas com esse propósito. Os alunos podem não gostar disso no início, mas o aumento da produtividade líquida será benéfico para todos. Além disso, você não terá que apontar ineficiências individuais para vários alunos (pelo menos não com tanta frequência).

Eu implemento algo semelhante quando ensino, mas isso é mais voltado para coisas de graduação. Discuto coisas como como / onde se inscrever para bolsas de estudo e estágios, dicas para entrar na pós-graduação, navegar na política do local de trabalho e também algumas coisas simples de fluxo de trabalho de vez em quando. Os alunos comentaram que isso foi muito benéfico.

Gosto da ideia de @Nate Eldredge de apresentar uma lista de dicas gerais de desenvolvimento, mas acho que só isso pode ter algumas deficiências. Pode ser demorado escrever algo realmente de alta qualidade que cubra tudo. Alguns alunos podem nem mesmo lê-lo (mas esses alunos provavelmente não prestarão atenção a nada que você diga durante uma reunião). Outros alunos podem não entender suas sugestões até que as vejam na prática. Isso realmente aconteceu comigo outro dia. Eu conhecia o Emacs 'Tramp, mas nunca entendi como implementá-lo. Eu vi um tweet com um .gif animado demonstrando como funcionava, e tenho usado todos os dias desde então. Talvez discutir essas coisas em reuniões e construir uma lista de dicas de desenvolvimento ao longo do tempo funcione bem.

Você também pode fazer alguns requisitos de grupo que tornam sua vida mais fácil. Por exemplo, você pode exigir que seu grupo use o Dropbox (ou algo semelhante) para compartilhar documentos e, no processo, isso pode incentivá-los a usá-lo em seus próprios materiais. (Você poderia manter o documento de dicas de desenvolvimento em uma pasta compartilhada no Dropbox para começar!) Eu acho que apontar ineficiências pessoalmente pode valer a pena, mas você definitivamente teria que escolher suas batalhas e apenas fazer isso de vez em quando.

Alguns dos comentários indicaram que várias das recomendações do OP são "objetivamente erradas", mas acho que falta a ponto. Se um pesquisador mais experiente vir maneiras de seu grupo ser mais eficiente, provavelmente vale a pena compartilhar, mesmo sem possuir o fluxo de trabalho perfeito. Compartilhar código por meio do Dropbox pode não ser a melhor solução, mas certamente seria melhor do que enviar e receber arquivos por e-mail. (Nem tenho certeza se o OP estava sugerindo que o grupo compartilhasse o código no Dropbox; este é apenas um exemplo). Além disso, é possível que os alunos tenham sugestões para o grupo (ou até mesmo para o líder do grupo), e elas podem ser aprimoradas reunindo todos.

Um comentário também sugeriu não entrar em uma guerra santa do Vim / Emacs ... mas os alunos sabem sobre o Vim, Emacs, outros editores / IDEs e suas capacidades em primeiro lugar? Eu certamente não sabia sobre isso como aluno de mestrado, e desenvolver habilidades com um editor teria me ajudado tremendamente (não estou na área de STEM, então essas ferramentas são incomuns; não tenho certeza sobre a área de OP, mas, novamente, este é apenas um exemplo). Você poderia definitivamente discutir recursos e capacidades sem entrar em uma guerra santa. A mera exposição pode ser extremamente benéfica.

Minha abordagem seria muito mais sutil em comparação com o método de João. Em vez de dizer a eles o que fazer, eu mostraria meu fluxo de trabalho enquanto respondia a uma pergunta semelhante. Certifique-se de fazer isso no seu próprio computador, não 'dirija' no PC de outra pessoa.

Um exemplo seria mostrar a eles seu "método de desenvolvimento", com uma grande janela de código. Use atalhos ou a CLI enquanto observam o que você está fazendo. Você pode dizer algo como "foobar me economiza muito tempo", mas não muito. Os alunos que desejam maior eficiência em seu fluxo de trabalho irão naturalmente perceber o que funciona para eles.

"Você pode conduzir um cavalo até a água, mas não pode obrigá-lo a beber"

Pessoalmente, é o que digo aos meus alunos no início dos seus trabalhos e a minha justificação entre parênteses.

1. Use o Dropbox / GDrive / o que você tem para backups (se você perder o trabalho 1 semana antes do envio, você está ferrado).

2. Configure um wiki para a documentação do projeto no servidor da faculdade (se você não fizer anotações depois, você não sabe o que escrever na dissertação).

3. Use Mendeley para gerenciamento de referência (gaste tempo escrevendo .bib's ou escrevendo sua dissertação, à sua escolha).

4. Configure o LaTeX e escreva sua dissertação nele (o Word é bom para até 3 -página de documentos).

5. Use máquinas virtuais para seu ambiente de trabalho e mantenha backups regulares (não perca tempo configurando coisas novamente e novamente).

6. Envie e-mail para ambos os supervisores em CC e sempre use "Responder a todos" para e-mails relacionados ao trabalho (não posso ajudá-lo se não sei o que você está fazendo).

7. Apareça no laboratório com frequência (apenas conversando com pesquisadores experientes, você aprende as maneiras mais rápidas e inteligentes de atingir seus objetivos).

8. Envie-me relatórios de progresso frequentemente (se você você não pede comentários, não tenho ideia se o seu trabalho está pronto para eles).

(Opcional)

1. Obtenha um SSD para o laptop deles, se eles puderem pagar (paciência vale mais do que dinheiro).

Quanto a me impedir de apontar todas as pequenas coisas, é fácil: é o trabalho deles e a escolha deles fazer um bom ou não. Nas palavras de Morfeu, "Só posso mostrar a porta. Você é quem tem que passar por ela".

Escolha as poucas coisas que são importantes e contam como 'melhores práticas' (ser sensato ou ter algum padrão sobre nomes de arquivos e variáveis ​​parece muito mais importante do que o tamanho da janela de edição ou atalho de teclado para mim). Dê algumas regras ou exemplos que mostrem as diretrizes em ação e vá em frente e seja um pouco exigente com relação a elas.

As outras coisas - (usar uma janela de edição maior, atalho) não são realmente 'importantes' como prática recomendada. Ficar por cima do ombro de um aluno e dizer, pressione aquela tecla, etc etc, é realmente irritante e pode ser opressor se muitas informações / detalhes forem dados a ele. (Qual detalhe é importante, que é apenas você sendo útil?) E, na verdade, eles podem ter razões bastante válidas depois de algum tempo para fazer isso de maneira diferente (eles podem encontrar outros atalhos que funcionam melhor com seu 'estilo' ou que você achar útil se você observá-los.

No entanto, dito isso - é verdade que as técnicas que economizam tempo e que os poupam de frustrações não são imediatamente óbvias para os novatos. Descobri que a melhor maneira é deixar alguém brincar com as ferramentas primeiro para que eles possam se deparar com algumas das frustrações. Mas, principalmente, simplesmente responda às perguntas básicas e, se houver alguma pergunta específica sobre maneiras "mais fáceis" de fazer isso, diga a eles. Depois, faça o individual um para mostrar como você faria a tarefa, apontando suas próprias práticas e como elas evitam frustrações específicas. No entanto, nesse ponto, deixe então escolher fazer da maneira que achar melhor. Não é útil ficar sugerindo isso sempre você os está ajudando.

Embora não esteja envolvido no treinamento de alunos em codi ng, temos que treinar usuários novatos em equipamentos que são um pouco complicados e têm um longo período de treinamento para se tornarem especialistas, então o processo tem algumas semelhanças.

Escolha os aspectos que são quase inegociáveis ​​porque são importantes. Não se preocupe muito quando os novatos continuarem optando por ignorar as dicas que você deu a eles que se baseiam naquilo que os especialistas costumam considerar como estratégias "úteis" para tornar sua própria vida mais fácil.

@haff sugerido em um comentário:

Se o seu grupo de pesquisa tem reuniões semanais, você também pode dedicar 5 minutos ou mais no início de cada reunião para demonstrar hacks de desenvolvimento / fluxo de trabalho.

Uma ideia interessante! Agora, vamos variar um pouco:

Dedique algum tempo da reunião do grupo (não necessariamente 5 minutos apenas, e não necessariamente em cada reunião) para fazer round robin, dando aos alunos a oportunidade de compartilhar seus próprios hacks de fluxo de trabalho uns com os outros .

Avise-os por e-mail com antecedência para que possam pensar sobre quais hack (s) de trabalho desejam para compartilhar ou demonstrar. Em outras palavras, não os pegue de surpresa. E permitir que os indivíduos escolham não compartilhar algo.

Além disso, você pode ter algumas reuniões do tipo workshop em que alguém se voluntaria para assumir a cadeira de demonstração, desenvolvendo código ou testando rapidamente como uma master class em um departamento de música. Em seguida, convide os alunos a comentar de forma construtiva, com o objetivo de que cada aluno encontre algo para elogiar. Se eles quiserem fazer algumas sugestões construtivas sobre como depurar de forma mais eficaz ou eficiente, tudo bem, mas o objetivo principal deve ser aprender a fornecer feedback positivo aos colegas .

É é notável como as dicas e correções de um colega são muito mais eficazes em comparação a ter todas elas vindo do professor .

Não vejo nada de errado em fazer sugestões. Afinal você os está ensinando e não parece absurdo oferecer conselhos sobre como melhorar a forma como trabalham, principalmente se a sugestão é tornar algo objetivamente mais eficiente.

Eu concordo inteiramente que pode não ser uma coisa boa forçar os alunos a trabalhar de uma certa maneira se realmente não fizer sentido para eles. Certamente, minha experiência é que uma das coisas mais úteis sobre como trabalhar com alguém experiente (seja em um ambiente de ensino formal ou não) é que eles saberão muitos truques úteis que não são necessariamente intuitivamente óbvios.

Depois de fazer a sugestão, você pode deixar que eles decidam se querem ou não agir, mas pelo menos eles terão a informação.

TL; DR: Faça uma distinção entre 'dicas e truques' e 'diretrizes / boas práticas'. Dê dicas sobre o primeiro e tente aplicar o último.

Se for possível em sua situação, você pode querer organizar uma pequena apresentação. Algo como 'dicas e truques do EditorX'. Onde você pode compartilhar com eles algumas dicas e truques sobre como usar o editor de uma maneira melhor, sem apontar nenhum aluno em particular.

Isso não é muito diferente da indústria. Eu trabalho como engenheiro de software e temos palestras semanais onde podemos fazer uma demonstração de algo interessante na área. A cada poucas semanas, alguém fará uma pequena demonstração de algumas dicas e truques. Todos são encorajados a fazer isso.

O benefício dessa abordagem, para mim, é que você faz outras pessoas ver o benefício (desenvolvimento mais rápido, por exemplo) com uma pequena demonstração. Você também vai deixá-los curiosos para encontrar mais dicas e truques que possam compartilhar.

Dito isso sobre dicas e truques, há também outras coisas que não são apenas dicas e truques, mas sim diretrizes e boas práticas que devem ser seguidas. Se você usar um atalho ou não, é totalmente opcional, ou se você perceber que existe uma configuração de Digitação de latência zero no IntelliJ (um IDE) e quiser usá-la. No entanto, por outro lado, temos coisas como controle de versão, nomes de variáveis ​​sensíveis, mantendo alguma documentação, o que eles realmente deveriam estar fazendo. A maneira como eles o usam é mais uma vez na parte de 'dicas e truques', mas eles devem pelo menos saber as vantagens de usá-lo e ser fortemente encorajados a fazê-lo.

A maneira como fiz isso ao ensinar (ambiente acadêmico) foi reforçando o uso dessas coisas. Não tenho certeza se você pode impor isso em sua posição, mas se possível, eu o faria. Você pode definir algumas 'diretrizes' para o seu grupo? Nesse caso, aplique as diretrizes de codificação e tenha-as documentadas em algum lugar. Coloque qualquer coisa relevante nesse documento, como se você quiser uma caixa de cobra ou uma caixa de camelo. Dê algumas dicas sobre como encontrar bons nomes de variáveis ​​e classes. Aplicar push para git (svn, ..) e mostrar exemplos de boas mensagens de commit.

(Uma maneira de impor um bom estilo de código poderia ser usar uma ferramenta que verifica a sintaxe, os padrões de nomes de variáveis, etc. Existem alguns bons linters disponíveis para muitas línguas)

O aqueles a quem ensinei nem sempre viram o benefício dessas coisas - mas no final deram uma volta de 180 graus. Fiquei feliz em ver as diretrizes sendo respeitadas e os alunos realmente perceberem o benefício disso.

é um processo, concordo, mas se você não apontar os "erros", como eles saberiam que poderiam ser melhorados?

Pessoalmente, eu critico tudo e até agora tem funcionado bem. Também gosto de deixar claro esse ponto exato e lembrar de parabenizá-los quando eles realmente fizerem as coisas certas na primeira tentativa (caso contrário, parece que você se concentra muito no feedback negativo).

Claro, é importante lembrar que, em última análise, a decisão não é sua. Você apresenta todos os lados, prós, contras e eles decidem. Outra maneira de dizer isso é mencionando cada coisa três vezes, no máximo :)

Eu sugiro que você aborde esta parte do ensino da arte da programação como se você fosse um diretor de teatro.

Diga a seus alunos que você vai reservar algum tempo para observar cada um deles trabalhando e dar-lhes notas depois.

Observe um aluno e faça anotações. Fique em silêncio durante a observação.

Depois de sua observação, "faça suas anotações:" tenha uma conversa em que conte ao aluno suas observações sobre o trabalho dele e dê sugestões de melhoria. Dessa forma, você está oferecendo suas sugestões de forma estruturada, e não importunando-as. Certifique-se de dizer a eles que eles não estão sendo marcados ou avaliados nisso.

Você também pode incentivá-los a fazer isso uns pelos outros.

Vou tentar responder à pergunta que você está realmente fazendo - ou seja, as perguntas sobre você , não sobre seus alunos:

Como evitar interferir no trabalho ineficiente-mas-não-errado dos alunos?

... e ...

Existe um boa maneira de [...], mas não ficar nervoso, se os alunos não os usarem?

(E minha resposta é estritamente sobre conselhos que não foram solicitados, como no seu caso. Nada disso obviamente se aplica quando seus alunos perguntam a você como melhorar.)

Infelizmente, você está tramando algo muito profundo com suas perguntas. Existem dois fatos que podem tornar pessoas como você (ou eu), que têm técnicas muito eficientes para fazer coisas , muito infelizes por testemunhar outras pessoas caminhando dolorosamente devagar - por qualquer motivo, não necessariamente relacionado a sua inteligência em tudo.

1. Nem todas as técnicas (de usar um editor, ferramenta de upload ou qualquer outra coisa) funcionam da mesma forma para todas as pessoas. O que você pode achar muito óbvio (por exemplo, ter a maioria das teclas de atalho do Emacs corrigidas, ser capaz de imaginar uma boa macro de teclado instantânea fluindo diretamente de seus dedos durante a edição, etc.) pode ser totalmente impossível para outros. Você chegou às suas técnicas pensando muito e profundamente sobre elas, ou descobrindo intuitivamente algo que corresponda à forma como seu cérebro está conectado. Isso não é necessariamente aplicável a outras pessoas. Daí as guerras VI / Emacs, Windows / Linux, PC / Mac, etc.
2. Nem toda pessoa é realmente capaz de aceitar conselhos, por mais bem intencionados que sejam, e aplicá-los em seu próprio trabalho, por diferentes razões. Na verdade, em minha experiência em todos os aspectos da vida (universidade, trabalho, família, amigos), havia apenas muito, muito poucas pessoas que eram capazes de aceitar qualquer conselho não solicitado qualquer.

Agora. Não vou entrar nas razões específicas para esses dois fatos, porque são muitos, e isso não importa. Apenas um exemplo: para "1". a outra pessoa pode simplesmente não saber sobre isso; suas "rotinas de pensamento" podem simplesmente não coincidir com a forma como um editor trabalha, e assim por diante. Para "2", você pode simplesmente não ser capaz de explicar com as palavras que eles precisam ouvir, eles podem estar bloqueados pelo orgulho etc. Pode haver muitos outros motivos, mas minha resposta não é sobre esses motivos. Claro, para muitos deles, há uma maneira de contornar isso. Mas você sempre terminará na posição em que sentirá dor, porque deseja muito ajudar , mas eles simplesmente não entendem.

Como se conter

Simplesmente faça. Sente-se pacientemente enquanto eles fazem suas coisas ineficazes. Sim. Obviamente, você pode mostrar a eles como trabalha, mas, francamente, eles verão isso simplesmente observando você, se você estiver trabalhando em um ambiente semelhante. Você não precisa fazer uma "coisa" com isso. Eles são estudantes e devem ser usados ​​para usar seu cérebro; se eles virem você trabalhando extremamente rápido enquanto demoram muuuuuito, eles devem ser capazes de descobrir que algo está acontecendo. A questão é que não é você que precisa fazer algo. Não é você o responsável aqui.

Se eles virem que você está trabalhando rápido, eles podem

• pedir que você explique como você faz isso.
• Se sentir mal com isso e pratique em casa.
• Sente-se com os amigos e "compare notas".
• Compre algum livro e leia sobre ele, seja ele qual for.
• Baixe as ferramentas que você usa e descubra-as.
• Ou não se incomode com isso e se atenha à lentidão.

E provavelmente outras coisas.

Como não ficar nervoso se eles não usarem suas dicas

O segredo para não ficar nervoso é pensar nisso com antecedência e remover a ideia de que você pode de alguma forma mudar outra pessoa da sua cabeça. Você não pode mudar outro ser, nunca. Você pode persuadi-los, forçá-los, liderar pelo exemplo ou qualquer outra coisa, e pode aproveitar as situações em que eles realmente melhoram, mas não pode realmente fazer que mudem.

Então, por lógica pura, não faz sentido nenhum ficar nervoso. É o caso de não ver a realidade como ela é. Se você aceitar que as coisas são como são, com certeza você ficará nervoso.