Como converter um programador de copiar / colar / espaguete para ver a luz?

Esta questão foi inspirada por esta . Enquanto essa outra pergunta foi considerada localizada, acredito que o problema subjacente é algo extremamente comum em nosso setor. Eu sei que existem alguns desenvolvedores que lerão isso e acharão que estou inventando essas coisas, e eles poderão responder como todos se preocupam com o trabalho e querem aprender, mas apenas olhando para outras postagens de Programmers SE ( caso em questão ), Eu sei que isso não é universalmente verdade.

Então, digamos que você tenha alguém em sua equipe (ou talvez a maioria) que seja o procedimento operacional padrão para copiar / colar e que acredite que tudo pode ser resolvido se você adicionar variáveis ​​e chamadas de função suficientes. Essa pessoa nunca ouviu falar de TDD, DRY ou SOLID e, fora de 40 horas no trabalho, quando está ocupada trabalhando, nunca leu um único livro de metodologia / práticas / design.

No passado, eu (e outros) perguntamos como você ensina OOD . Mas agora estou pensando que essa não é a pergunta certa. A verdadeira questão é como você aborda essa pessoa / equipe e as deixa curiosas sobre a melhor maneira de fazer as coisas? Como você os inspira a aprender? Sem isso, parece que todo o ensino, reuniões, palestras e discussões são inúteis se eles estiverem perfeitamente felizes voltando para a mesa e fazendo o que sempre fizeram.

Eu trabalho com um monte de gente assim. Na verdade, eles são indivíduos bastante inteligentes, mas eu odeio quando ouço: "Eu terminei de codificar, só preciso refatorar e dividir em várias classes para tornar o DXM feliz". Eles não refatoram para um código mais limpo, legível e sustentável, mas apenas porque, caso contrário, serão repreendidos. Eu sei que eles são capazes de aprender, apenas parece que há uma falta geral de motivação.

Quando eu entrego trabalho, geralmente há muito menos erros e o trabalho que eu possuía nunca se tornou monstruosidade de 5000 linhas de uma classe. Outros gostariam de fazer comentários como "seu código é muito mais limpo e legível que o nosso", para que eles vejam a diferença. Mas, ao mesmo tempo, acho que eles acreditam que são pagos por 40 horas, independentemente do que fazem, e, na verdade, não se importam se passam três dias inteiros no controle de qualidade procurando um bug que não deveria ter sido introduzido no o primeiro lugar. Ou eles levam uma semana para modificar uma classe porque há tantas dependências que acabam tocando. O pensamento de que "talvez essa classe devesse ter sido escrita de maneira diferente" nunca parece aparecer.

Alguma coisa pode ser feita nessas situações? Alguém conseguiu? Ou é melhor isolar essa mentalidade em partes não críticas do projeto e minimizar os danos?

NOTA: Quando digo "falta de motivação". Não acho que seja falta de motivação para trabalhar ou fazer um bom trabalho, porque eles simplesmente pararam de se importar. A maioria de nossa equipe é exatamente o oposto. Eles definitivamente se preocupam com o produto. Temos caras que trabalham noites e fins de semana. A parte que estou tentando passar é com hábitos e habilidades aprimorados, eles realmente não precisariam trabalhar tanto. Eu acho que essa coisa de "40 horas" fez esse post parecer um pouco negativo demais.

Você se encontrou com o motivo: "Eu sei que eles são capazes de aprender, apenas parece que há uma falta geral de motivação".

Há pessoas apaixonadas pelo seu trabalho. E há outros que, por vezes competentes o suficiente, estão trabalhando apenas por dinheiro . Eles sabem o que fazem, mas não gostam do trabalho. Eles não gastam tempo extra fazendo refatoração adicional para tornar o código legível ou resolvendo um problema intrigante quando um hack rápido e feio pode fazer o trabalho.

Esse fenômeno existe em todos os empregos. Só que alguns trabalhos não são extremamente empolgantes (você já viu um contador que ama o trabalho e já sonhava com ele quando criança?), Mas na programação há muitas pessoas que realmente amam o que estão fazendo (caso contrário, Programmers.SE estará bem vazio). Isso significa que, como desenvolvedores apaixonados, que conversam diariamente com outros desenvolvedores apaixonados, temos mais chances de nos surpreender ao ver uma pessoa que faz programação apenas por dinheiro.

O que podemos fazer? Não muito. Em todos os casos, não é para você, mas para os recursos humanos escolher pessoas realmente motivadas¹. E demitir pessoas que não são.

Você pode tentar motivar seus colegas, mas é extremamente difícil. Se você lhes der livros para ler, eles os devolverão fechados algumas semanas depois. Se você lhes der um conselho, eles não ouvirão, porque não se importam².

Você pode:

• Convença seu chefe a definir várias regras estritas em sua empresa: diretrizes de estilo etc. Isso não motivará essas pessoas a fazer um trabalho melhor, mas pelo menos elas não poderão confirmar o código-fonte que não corresponde aos requisitos .

• Trabalhe nos requisitos, especialmente requisitos não funcionais . Que tal um requisito que informa que um projeto específico deve conter menos de 5.000 linhas de código IL (não, não estou falando do LOC sem sentido ) ³? Que tal exigir obter resultados específicos com complexidade ciclomática ou acoplamento de classe ?

• Aumente o número de horas que você gasta em sua empresa fazendo revisões de código . Especifique o que foi revisado: se você possui uma lista de verificação, adicione os pontos relacionados à refatoração, legibilidade, comentários limpos e úteis, etc. Se você não tiver uma lista de verificação, deverá fazê-lo.

• Use [mais] programação em pares . Isso pode ajudar a melhorar a qualidade do código e motivar os colegas de trabalho menos motivados.

• Use o sistema de compensação semelhante ao usado em Fog Creek.

^{¹ É disso que se trata a entrevista: antes de contratá-lo, os recursos humanos devem agregar não apenas seu nível técnico, mas também sua motivação . Infelizmente, algumas empresas esquecem esta segunda parte da entrevista e contratam pessoas que não gostam muito de programar. Felizmente, na maioria dos casos, o trabalho nessas empresas nunca é agradável e o teste de Joel raramente excede 2.}

^{² Eles realmente não se importam, mesmo que ganhem menos dinheiro. Estou bem perto de um dos meus clientes (sou freelancer) que acredita que seu trabalho é desenvolver sites para seus próprios clientes. Ele também tem um designer. Eu falei várias vezes sobre como eles podem aumentar sua produtividade em 2 ou mais. Se eles contratassem alguém competente, aumentariam sua receita em pelo menos 3. Mas eles têm dinheiro suficiente e não se importam com a qualidade ou quanto custam aos clientes ignorantes, em comparação com alguém produtivo.}

^{³ O que quero dizer é o número de linhas de código IL que você vê nas Métricas de Código no Visual Studio , a métrica que realmente significa alguma coisa. O LOC real não importa e você não precisa medi-lo; é uma das métricas mais estúpidas de todos os tempos. A imposição de linhas de código IL significa que os desenvolvedores serão forçados a refatorar o código, e não apenas a recolher dez linhas de código em uma única linha ilegível.}

"Eu terminei de codificar, só preciso refatorar e dividir em várias classes para fazer o DXM feliz".

Essa linha de pensamento ali mesmo é um câncer em qualquer equipe e matará a motivação de toda a equipe se não for tratada imediatamente. Refiro-me, é claro, ao fato de, por antiguidade e / ou mérito, estar em uma posição de autoridade técnica, dando-lhe o poder de ajudar a influenciar e trazer boas práticas para sua equipe.

Tudo está muito bem, no entanto, se sua equipe foi claramente vendida nesses processos, eles não destacariam você em declarações como estas que mostram claramente uma falta de respeito pelo processo e uma falta de respeito em você. Eles ainda veem essas práticas recomendadas como um obstáculo causado por você e não como um processo de propriedade da equipe que sua equipe defenderá por seus próprios méritos.

Você mencionou nos comentários anteriores que outros membros da equipe estão realmente seguindo essas práticas e padrões e aplicando-os corretamente. Concentre a atenção primeiro em reforçar o apoio deles, pergunte o que funciona, o que não funciona, o que eles gostam e o que eles gostariam que mudassem. Se você fizer isso e levar a sério as opiniões deles, eles se sentirão muito diferentes sobre os padrões, como se fossem uma decisão da comunidade, em vez de um procedimento que lhes foi entregue por um superior.

Você reforça o suporte às melhores práticas e padrões, apontando para a equipe como eles melhoraram o processo de desenvolvimento de software ou a qualidade do software.

Poste uma votação sobre os assuntos para discussão e documente os resultados, idealmente, todas as decisões devem ser unânimes por uma questão de legitimidade, mas se você estiver lidando com obstrucionistas de linha dura, isso pode ser impossível e pode acabar com todos os problemas. Use um voto majoritário nesta situação. Se a maioria é contra os padrões e práticas propostos, você já perdeu a sala, basta desistir nesse momento.

Eles possuirão esses padrões e procedimentos e os aplicarão para que você não precise. Como líder em tecnologia, você não precisa declarar decretos e decretos, é uma maneira ruim de ser um líder.

Quando a equipe sentir que possui os procedimentos, os membros da equipe que começarem a rotular você para determinados procedimentos e práticas recomendadas ficarão ilegítimos. Sua equipe ajudará a corrigir essa atitude nos outros.

Boa pergunta! Eu acho que a resposta depende de por que as pessoas não querem melhorar suas habilidades. Respostas possíveis são:

• Eles acham que estão ocupados demais para aprender algo novo ou acham que a nova maneira de fazer as coisas (como escrever todos esses testes) os levará mais tempo e não terão tempo para isso. Então a resposta óbvia seria: dê a eles mais tempo. Aprender algo ou tentando algo como TDD quando você tem coisas sempre feito de forma diferente vai demorar mais tempo do primeiro par de vezes. Se seus programadores não tiverem esse tempo, você não poderá culpá-los por não tentarem.
• Eles têm uma percepção diferente de suas próprias habilidades, ou seja, acham que são muito bons programadores produzindo código de alta qualidade. Este é um terreno psicológico difícil, porque destruir essa crença pode ser muito desmotivador. Talvez algum tipo de competição informal possa ajudar (quem produz o menor número de defeitos / recurso? O código mais curto? O menor número de WTFs / minuto em uma revisão de código?).
• Pode haver um problema de motivação real (ou seja, eles só querem "fazer o seu tempo e ficar sozinhos" até a hora de fechar). Felizmente, isso é muito geral / não relacionado à programação, porque eu realmente não tenho uma resposta para isso.
• Eles são iniciantes e não sabem melhor. Nesse caso, o treinamento, as revisões de código podem ajudar, ou um "clube do livro", em que um membro da equipe deve discutir um novo livro técnico todos os meses.
• Eles já viram balas de prata antes (e ficaram amargamente desapontados) e acham que o que quer que você esteja tentando vendê-las é apenas mais uma nova palavra da moda que soa bem na teoria e pouco serve na prática. Nesse caso, demonstrar as vantagens durante as revisões de código e as sessões de programação em pares pode funcionar. Tente não ser um total know-it-all quando fizer isso.

A melhor solução realmente depende do problema raiz: por exemplo, diretrizes formais de codificação, métricas e revisões podem funcionar para iniciantes, mas pessoas com "percepção errada de suas próprias habilidades" - a multidão pode lutar contra elas ou reproduzir as métricas porque vêem como obstáculos burocráticos contraproducentes à realização do trabalho.

A verdadeira questão é como você aborda essa pessoa / equipe e as deixa curiosas sobre a melhor maneira de fazer as coisas? Como você os inspira a aprender? Sem isso, parece que todo o ensino, reuniões, palestras e discussões são inúteis se eles estiverem perfeitamente felizes voltando para a mesa e fazendo o que sempre fizeram.

É isso aí! Esta é realmente uma pergunta real.

Para dar um pouco de apoio, nós simplesmente não temos tempo para colocar muito treinamento formal - mas, ocasionalmente, se eu fizer isso - ele ainda não vê luz. Também fiz parte das empresas em que o treinamento formal se torna um processo em si, e sou tão frequentemente uma testemunha que eles quase não os ensinam a pensar.

Então a pergunta que eu lhes proponho não é como ensiná-los - mas como fazê-los aprender? A diferença é sutil, mas é o que fará toda a diferença.

Não sei se estou certo; mas muitas vezes acredito no diálogo de Matrix, o filme - "É a pergunta que nos move!" O mais importante é fazê-los pensar, fazê-los perguntar o porquê! E, é claro, a maioria dos que pensam que já sabem tudo sobre alguns padrões de design porque obtiveram boas notas nos cursos universitários - são os mais difíceis por lá.

Como você faz essas perguntas? Minha abordagem geral é "que os jogue na lagoa se você quiser que eles aprendam a nadar" . Eu concordo que as pessoas possam discordar; e terei prazer em concordar em discordar deles. Quando você os joga na lagoa - eles realmente não aprendem a nadar automaticamente; mas desencadeia um instinto de sobrevivência que os faz pensar - uma vez que isso acontece, eles naturalmente pensam em COMO e POR QUE.

Um exemplo prático que eu dou às pessoas é colocá-las em um projeto significativamente complexo do que o que eles esperavam obter e deixá-las travar sua própria batalha. Quando eles começaram a desvendar o código e acham difícil rastreá-lo - você percebe que eles começam a fazer uma boa pergunta.

Isso pode parecer um pouco extremista, pode parecer desperdício de recursos . E tenho certeza, há muitos outros que me darão conselhos para não fazer isso. Mas isso funcionou para mim!

Não importa quais pacotes de pagamento e tags de RH que você atribuir não resolverão o problema básico de motivação . Pois esse único caminho é que eles são desafiados; Se você despertar esse espírito humano básico - tudo funcionará. Se você não pode, é um jogo frouxo.

PS: Aliás, eu postei uma resposta aqui https://softwareengineering.stackexchange.com/questions/127021/how-do-you-train-freshers/127034 - e recebi toda a contestação; principalmente a maioria das pessoas acredita que, de alguma forma, as empresas não podem desperdiçar recursos! Tenho certeza de que esta resposta pode receber tratamento semelhante aqui. Mas a verdade é que fazer as pessoas trabalharem e fazê-las acreditar em fazer um bom trabalho é um assunto da psicologia humana sobre como elaborar o plano de estudos do curso.

De qualquer forma, a tarefa que você está descrevendo aqui significa acender a paixão interior de fazer grandes mudanças. E quanto maior o sistema, mais difícil fica. Comece com colegas mais jovens que ainda estão construídos com o espírito de não fazer bom trabalho e desafie o status quo.

Como você ressalta, é a sua motivação. Não os confunda não cuidando deles não sabendo. Eles sabem claramente o que fazer. Eles simplesmente não se importam . Se for esse o caso, a verdadeira questão aqui é ... o que sua gerência está fazendo de errado que os mantém tão desmotivados? Você é o mais novo membro da equipe? Talvez eles tenham passado por tudo isso antes, com isso apenas levando a problemas de sua gerência. Portanto, eles continuam se esforçando para fazer a menor quantidade de trabalho necessária para manter o emprego, porque não acham que fazer mais será respondido pelo empregador.

Parece-me que este é um problema de gerenciamento e liderança - se for sua equipe, você poderá trabalhar para tornar a melhoria (pessoal e do código) um atributo essencial da sua equipe, a questão é se isso será suportado por sua gerência - porque você vai querer fazer coisas que levarão tempo (elas terão uma vitória líquida, pois você deve reduzir a nova dívida técnica e pagar a dívida técnica existente).

Então, você afirma que deseja que a equipe melhore, você concorda que isso é uma coisa boa (que a equipe, como um todo, trabalha para melhorar a qualidade de seu código) e então inicia um programa para fazer isso acontecer - parece tão fácil ... Estou ciente de que não!

Eu acho que há duas partes nisso - educação e práticas de trabalho.

• Educação Você pode começar um almoço por semana - todo mundo come junto, você faz uma apresentação de 20 a 30 minutos com perguntas e respostas. Você começa com o básico que deseja - o SOLID pode ocupar as primeiras 2 a 4 semanas - com o tempo, você faz a equipe falar em rotação e pode descobrir como decidir quem fala sobre o que entre você. Permita que os palestrantes tenham algum tempo de preparação no trabalho. Além disso, incentive a participação de grupos de usuários locais (tornando-o pelo menos parcialmente social, se possível)
• Práticas de trabalho ... bem, depende do que você faz agora e das ferramentas que possui, mas você pode querer concordar com os padrões de codificação, introduzir revisão de código por pares (é sólida), teste de unidade (não necessariamente testar primeiro) , executando um servidor de integração contínua e analisando testes mais automatizados (além de testes de unidade). Mas estes devem ser introduzidos substancialmente com consentimento / acordo (e não o servidor de build / CI!) E você precisa levar a qualidade adiante como uma equipe. Sempre há coisas que podemos melhorar (Kaizen)

Também vale a pena olhar para o Kanban (que é visto como um fator de mudança / melhoria).

Um último pensamento - sou programador profissional e gostaria que minha equipe fosse a mesma, mas trabalhar mais de 40 horas por semana não é realmente uma coisa boa, então o objetivo de alguém deve ser ter uma equipe que faça seu trabalho efetivamente e bem dentro da semana normal de trabalho e em relação a isso, o argumento para melhorar a prática de trabalho é que é mais provável, por exemplo: adicionar testes de unidade para demonstrar o caso de falha quando (antes) a correção de erros lhe dá confiança de que éfixo; ter um servidor de build dá a você confiança em sua capacidade de criar suas soluções de maneira limpa - se esse build também gerar pacotes de implantação, significa que a implantação é muito simplificada; O código SOLID é, por definição, mais fácil de modificar; e, em geral, quanto menos dívida técnica você incorre, menos tem que pagar ...

Eu caí na programação por acidente ~ 30 anos atrás. Fiquei motivado a aprender os princípios básicos de engenharia de software ao ser designado para manter / dar suporte ao código de outras pessoas. Nessas tarefas, aprendi como um leitor de código experimenta código - como ter empatia com o leitor de código. Eu não queria infligir a dor do meu código mal escrito a outras pessoas!

Essa prática de designar novos programadores para manter / apoiar o código de outras pessoas não é uma mágica e parece fornecer motivação para aprender a produzir código sólido com mais frequência do que nunca.