Introduzindo novos tópicos para colegas de trabalho

Eu tenho tentado introduzir tópicos como teste de unidade, injeção de dependência, inversão de controle, etc ... para colegas de trabalho. Eu dei mini palestras, demonstrações e sugeri esses tópicos durante o almoço e os aprendizados. A recepção geralmente tem sido positiva e as pessoas veem valor nesses tópicos.

Embora pareçam atraídos por esses tópicos, a adoção tem sido muito baixa. Quando falo com eles sobre isso, a resposta geralmente é da seguinte maneira:

Vou tentar na próxima vez. Eu só quero levar esse projeto para a porta.

Sinto que é porque a maioria do que eles viram são apenas demonstrações do tipo palestra e eles não têm nenhuma experiência prática. O que posso fazer para ajudar a acompanhá-los? Eu não quero "forçá-los" a escrever código, se não quiserem, porque pode parecer "lição de casa" e pode deixá-los com uma má impressão.

Nossos projetos geralmente não deixam tempo para experimentação; portanto, as pessoas tendem a se afastar das novas tecnologias. Isso não deixa espaço para os desenvolvedores tentarem incorporar coisas novas durante a fase de desenvolvimento.

Existem exercícios divertidos ou interessantes (solo ou equipe) que lhes permitam ter mais experiência prática com esses tópicos? Espero encontrar algo que atinja o interesse suficiente para que eles estejam dispostos a agendar uma hora do dia para trabalhar em algo arrumado, ou atinja o interesse suficiente para que eles investiguem em seu próprio tempo.

Para "provar" e, portanto, realmente implantar uma idéia na cabeça de alguém, a teoria (conversação) nunca é suficiente.

Você precisa usar essas práticas em seu próprio código e fazê-las "descobrir" que resolveu os problemas de uma maneira agradável.

Isso implica que suas práticas devem ser eficazes e você deve torná-lo óbvio.

Dessa forma, a leitura do seu código os inspirará, pois eles "o verão em ação".

Não assuma que apenas contar como funciona será suficiente.

Falando por experiência própria, se eles não estão dispostos a aplicar o que você está tentando ensinar, significa que eles não se importam com isso. Você provavelmente está perdendo seu tempo tentando introduzir os temas a eles, porque se eles entenderam os benefícios reais desses tópicos que iriam querer aplicá-los, não dar desculpas por que eles não podem.

É como tentar introduzir algo melhor do que o que está sendo usado no momento e obter uma aparência em branco ou respostas imediatas por que não é possível fazer isso; é indicativo que a outra pessoa não a veja realmente como um benefício (porque se eles fossem capazes de ver o benefício, não estariam dando uma desculpa).

Triste mas verdadeiro. Talvez sua situação seja diferente, mas eu já me deparei com isso algumas vezes no passado e, no final, era dolorosamente óbvio que ninguém além de mim estava interessado nesses tópicos; Eu finalmente tomei a decisão de sair e tentar encontrar colegas de trabalho que se importam; o tipo de pessoa que não precisa que eu introduza os tópicos (porque eles já os conhecem / os usa) ou que aceitam aceitá-lo, em vez de dizer como não podem fazê-lo.

Eu já vi muitas "melhores práticas" desvalorizarem e nunca mais serem usadas. Existem muitos tipos de projetos e essas técnicas não são adequadas para todos os projetos. Verifique se as coisas que você está vendendo realmente ajudarão.

Se você começar a fazer isso e as pessoas puderem ver que você está sendo mais produtivo ou produzindo código de melhor qualidade, elas terão outra visão mais tarde. Pense bem, toda a sobrecarga extra realmente ajudará seu projeto? Nem todo aplicativo precisa.

Se você pode motivar seus colegas a participar, pode organizar o Coding Dojos . Esses são desafios de programação em que os participantes deliberadamente se concentram em melhorar a prática. Talvez participar de um dojo testado, por exemplo, leve seus colegas a ver os benefícios do TDD.

Alternativamente, às vezes essas coisas precisam ser impostas pela cultura. Parece-me que a cultura da sua empresa não precisa deles.

Se eles se tornarem um requisito de fechamento do projeto (provavelmente uma decisão de gerenciamento), você verá dificuldades, mas pelo menos alguma aplicação dessas ferramentas e a cultura começarão a mudar.

A melhor prática é no código de produção real. Katas são uma boa introdução, mas, na minha experiência, não mantenha o mesmo "Eureka!" Momentos como vê-lo feito de verdade .

No entanto, você apontou que as linhas do tempo "não permitem experimentação". É realmente uma solução simples. Você já está fazendo essas coisas que está tentando ensinar; portanto, deixe um convite aberto para se juntar a você enquanto implementa o incrível novo recurso X. Deixe-os sentar ao teclado e digitar enquanto estiver " condução no banco de trás ". Isso permitirá que eles construam alguma memória e confiança muscular.

Boa sorte em seus empreendimentos.