Como podemos tornar as melhores práticas de desenvolvimento de software mais interessantes para pessoas sem experiência em software?

Onde trabalho, existem alguns desenvolvedores de software experientes com experiência em software, mas a maioria dos desenvolvedores são físicos ou químicos com excelente conhecimento de domínio, mas com experiência limitada no desenvolvimento de software de alta qualidade e manutenção. Para resolver isso, começamos a realizar palestras e workshops regulares.

Quais tópicos você acha que devemos discutir para ajudar a tornar essas pessoas desenvolvedores de software mais eficazes?

Em particular, estamos lutando para obter entusiasmo por essas conversações, já que muitos desenvolvedores não vêem o software como um assunto interessante. Como poderíamos tornar isso mais interessante para as pessoas sem experiência em software?

obrigado

Eu acho que vai ser difícil, então esteja preparado para uma luta - mas não impossível. No final do dia, a programação (especialmente a codificação não-cowboy-hack'n'slash) não será super emocionante para todos. Isto é especialmente verdade para pessoas que já trabalham em uma área que é intelectualmente desafiadora e recompensadora por si mesma.

Antes de tudo, divirta-se as palestras e as oficinas - comida de graça (certifique-se de que é uma boa comida!) E guloseimas semelhantes são um bom ponto de partida. Tente injetar um pouco de humor também e, pelo menos inicialmente, mantenha-os razoavelmente breves e o mais informal possível.

Em segundo lugar, verifique se as palestras e workshops são relevantes. Tente não torná-los muito abstratos (mesmo que os conceitos abordados sejam abstratos) e, se puder, garanta que eles possam experimentar o que foi coberto. Ainda melhor, verifique o que eles fizeram entre as sessões e forneça um feedback positivo. Se eles não são relevantes e não estão aplicando o que você discutiu, eles os visualizarão (corretamente) como uma perda de tempo.

Por fim, tente introduzir alguns padrões básicos de codificação, de preferência aqueles que não sejam muito intrusivos na forma como eles operam atualmente. Se você está no mundo .net, o Resharper é um bom começo, pois avisa sobre coisas como convenções de nomenclatura. Você pode levar isso adiante com o StyleCop (que pode ser integrado ao Resharper) - mas certifique-se de personalizar o conjunto de regras primeiro. Se você não está no .net, tenho certeza de que ferramentas semelhantes existirão em outros lugares. Não é muito, mas é um começo.

Não espere resultados instantâneos (exceto, talvez, por quaisquer padrões de codificação impostos automaticamente) - ouvi 6, 9 e 12 meses fazendo bandagens durante o tempo para introduzir as melhores práticas.

Até agora, eu o folheei até agora, mas parece haver bons conselhos relevantes e relevantes para você no próximo livro, Conduzindo a mudança técnica .

Se esses químicos e físicos não são desenvolvedores principalmente profissionais e não pretendem se tornar assim, eu sugeriria pensar de maneira diferente no problema.

Os desenvolvedores "reais" devem fornecer ambientes fáceis para eles se desenvolverem. Você deve fornecer orientação e deve fornecer uma revisão por pares de seu código com fortes incentivos para tornar o código bom o suficiente para passar em primeiro lugar.

Em outras palavras, não os trate como iguais, mas forneça tudo o que puder para que se destacem no que realmente fazem, que é a sua força.

Eu trabalho com engenheiros de rede muito inteligentes que não são desenvolvedores e não querem ser. Eu posso entender isso porque não quero ser um engenheiro de redes.

O que descobrimos que funciona bem é para o engenheiro e eu fazermos a programação em equipe. Estamos em sites separados, por isso, ligamos para o telefone, abrimos uma sessão de compartilhamento de tela geralmente com o screencomando e eliminamos o código.

Fizemos isso várias vezes e sentimos que funcionou muito bem. Estou entendendo como eles fazem melhor suas coisas, e o engenheiro está aprendendo como escrevemos código sustentável e testado.

Qual o papel que eles têm na empresa? Se você precisar de desenvolvedores, deixe-os ir se não forem bons desenvolvedores e não estiverem interessados ​​em se tornar bons desenvolvedores. Se eles deveriam ser físicos e químicos, você pode realizar oficinas, mas não espere que eles mantenham um alto nível de interesse. Se eles devem ser os dois, aumente as expectativas e verifique se você as está pagando o suficiente para justificá-las a assumir o papel de desenvolvedor de software, mantendo ao mesmo tempo conhecimentos e habilidades complexas.

A menos que parte do papel definido de alguém seja um desenvolvedor, ele provavelmente nunca estará tão interessado no desenvolvimento de software de alta qualidade. Só porque alguém está criando scripts e hacks rápidos não significa necessariamente que realmente quer ser um desenvolvedor de software, é apenas um meio para atingir um fim, como um contador que descobre fórmulas complexas do Excel. Se você precisar de um software de alta qualidade e manutenção, os desenvolvedores de software devem criá-lo.

mostre a eles os benefícios para eles . caso contrário, por que eles deveriam se importar?