Inspirando um colega de trabalho a adotar melhores práticas de codificação?

Na pergunta Como lidar com meus colegas de trabalho antiquados , várias pessoas discutiram estratégias para lidar com colegas de trabalho que não desejam integrar seu fluxo de trabalho ao da equipe.

Eu gostaria, se possível, de aprender algumas estratégias para "ensinar" um colega de trabalho que é apenas ignorante das técnicas e ferramentas modernas, e possivelmente um pouco apático.

Comecei a trabalhar com um programador que, até recentemente, trabalhava em relativo isolamento, em uma parte diferente da empresa. Ele possui amplo conhecimento de domínio e, mais importante, demonstrou boas habilidades para resolver problemas , algo que muitos candidatos parecem não ter.

No entanto, o código (C #) real que eu vi é um retrocesso para os dias do VB6. Estrutura processual, notação húngara, variáveis ​​globais (abuso de static), sem interfaces, sem testes, não uso de genéricos, jogando System.Exception... você entendeu.

Esse programador é um pouco mais velho do que eu e, pelo menos pelas primeiras impressões, não busca ativamente mudanças positivas. Não vou dizer que é resistente à mudança, porque acho que é em grande parte uma questão de como o tópico é abordado e quero estar preparado.

Os programadores tendem a ser pessoas teimosas, e entrar com armas em punho e instituir análises de código rip-it-to-shreds e políticas rigorosamente aplicadas provavelmente não produzirá o resultado final que eu quero. Se fosse um novo contratado, um programador júnior, eu não pensaria duas vezes antes de adotar uma postura de "mentor", mas sou extremamente cauteloso ao tratar um funcionário experiente como um novato sem noção (o que ele não é - ele simplesmente não acompanhou certos avanços no campo).

Como posso elevar o padrão de qualidade de código desse desenvolvedor da maneira Dale Carnegie, por meio de persuasão suave e incentivos não materiais? Qual seria a melhor estratégia para efetuar mudanças sutis e graduais, sem criar uma situação adversa?

Outras pessoas - especialmente desenvolvedores líderes - já passaram por esse tipo de situação? Quais estratégias foram bem-sucedidas em estimular o interesse e criar uma dinâmica de grupo positiva? Quais estratégias não foram bem-sucedidas e seria melhor evitar?

Esclarecimentos:

Eu realmente sinto que várias pessoas estão respondendo com base em sentimentos pessoais sem realmente ler todos os detalhes da pergunta. Observe o seguinte, que deveria estar implícito, mas agora estou explicitando:

• Este colega de trabalho é apenas meu "mais velho" em virtude da idade. Eu nunca disse que seu título, esfera de influência ou anos na organização excedem os meus e, de fato, nenhuma dessas coisas é verdadeira. Ele é um programador de LOB que foi absorvido pela principal loja de desenvolvimento. É isso aí.

• Não sou um novo contratado, programador júnior ou outro idiota ingênuo com grandes planos de transformar a empresa da noite para o dia. Eu sou basicamente responsável pelo processo do software, mas, como muitos que trabalharam como "leads" sabem, as responsabilidades nem sempre se correlacionam com precisão com o organograma.

• Estou não pedir às pessoas como fazer do meu jeito, venha o inferno ou água alta . Eu poderia fazer isso se quisesse, com o resultado líquido sendo que essa pessoa ficaria ressentida e / ou desistir. Por favor, tente entender que estou procurando um método social e cooperativo de promover mudanças.

• A menção de "... variáveis ​​globais ... sem testes ... jogando System.Exception" teve como objetivo demonstrar que os problemas não são apenas superficiais ou estéticos . Práticas que podem funcionar para aplicativos CRUD relativamente pequenos não funcionam necessariamente para aplicativos corporativos grandes e, de fato, nenhum dos códigos até agora passou nos testes de integração.

Por favor, tente aceitar a pergunta pelo valor de face, aceite que eu realmente sei do que estou falando e responda à pergunta que realmente perguntei ou siga em frente.

PS: Minha mais sincera gratidão àqueles que - ofereceram conselhos construtivos em vez de discutir com a premissa. Vou deixar isso em aberto por mais algum tempo, pois espero ouvir mais no caminho das experiências do mundo real.

O ponto de partida é conhecer o seu público . Parece que você já entendeu isso porque sabe a diferença entre orientar um colega de trabalho júnior e influenciar um colega de trabalho sênior.

Você ainda precisa descobrir o que motivará esse indivíduo em particular. O que funciona em um velhote antigo (como eu) pode não funcionar no seu velhote antigo.

Se ele gosta de orientar / ensinar outras pessoas, você pode abordar um problema fazendo perguntas como "por que você faz dessa maneira?" Isso pode gerar um diálogo em que você pode pedir que ele avalie abordagens mais recentes e dê sua opinião.

Se isso não funcionar, você pode apontar erros que podem ser evitados usando as práticas ou estilos que você gostaria que ele adotasse. Isso requer muito mais trabalho, porque você precisa encontrar os bugs e mostrar como os comportamentos que você deseja incentivar ajudariam.

Se ele parece disposto a ajudar os outros, você pode apelar ao desejo dele de ajudar os novatos . Explique que "as crianças de hoje" não estão acostumadas a ver seu estilo de codificação e terão mais probabilidade de quebrar seu código por causa disso.

Às vezes, você pode ter que entrar na cara dele e forçar o problema. Você precisa escolher essas batalhas com cuidado. Certifique-se de começar com um tópico em que saiba que pode provar a ele que você tem uma maneira melhor.

Eu acho que você tem a atitude certa. Apenas certifique-se de apontar todas as coisas legais que você já disse - Ótimas habilidades para resolver problemas, compreensão do negócio, etc. e apenas peça um pouco do seu tempo para mostrar os padrões atuais de que o grupo é. usando e dê a ele a chance de fazer algumas perguntas sobre eles.

Quando você se reunir, traga-lhe um café ou algo assim, e deixe-o saber que trabalhar com os padrões o beneficiará, facilitando o suporte ao código existente e facilitando a ajuda de alguém, caso ele fica coberto de trabalho (uma grande vantagem para alguém que trabalha isoladamente) etc.

Certifique-se de que ele esteja noivo e obtenha boas explicações sobre por que você faz as coisas que você faz e não se concentre em por que ele não deve fazer as coisas que ele estava fazendo. Posicione-se disponível posteriormente, se ele tiver alguma dúvida e acompanhamento com alguns lugares aos quais ele pode se referir para obter exemplos de seus padrões.

Se ele não estiver interessado depois disso, você pode consultar a primeira pergunta que você vinculou.

É realmente o trabalho do seu gerente

1. Perceba que a empresa deve ter um padrão de codificação. Toda empresa um tanto profissional tem isso, não importa o tamanho da empresa.
2. Faça com que todos se sentem juntos e comecem a elaborar um padrão. Dessa forma, todos podem dar a sua opinião e ficarão mais motivados a seguir o padrão.

Se o seu gerente não perceber isso sozinho, ele não estará qualificado para o trabalho. E se sim, você deve dar alguns empurrões acima dos dois acima. As vantagens de ter um padrão de codificação são muitas, não há realmente nenhum argumento contra ter um. (Se alguns programadores sentem que são "artistas" e não devem ser restringidos pelos limites do profissionalismo, eles devem conseguir um emprego fazendo artes plásticas.)

O padrão de codificação em si deve, em primeiro lugar, concentrar-se na proibição de práticas perigosas e funções perigosas da biblioteca. Trabalhe em direção a um subconjunto mais seguro e puro do idioma que você está usando. Mantenha o padrão de codificação livre de "estilo de codificação", porque o estilo de codificação é muito mais difícil de concordar e não é tão importante. É bastante clássico que uma empresa decida estabelecer um padrão de codificação e, em seguida, imediatamente fique presa em uma discussão sem sentido sobre onde colocar os aparelhos.

Para referência, confira como os padrões MISRA-C / C ++ e CERT C / C ++ / Java são gravados.

Antes de tudo, você precisa esclarecer POR QUE deseja mudar o modo de trabalhar dessa pessoa. Se for apenas por razões estéticas, acho que você deveria reconsiderar, porque essa pessoa demonstrou que sua maneira de trabalhar realmente funciona.

Se, no entanto, houver uma razão técnica para isso, considere abordar a pessoa com algo como:

Eu tenho uma sugestão de como você pode economizar tempo tedioso para você e dinheiro para a empresa. Você está interessado?

Esteja ciente de que essas frutas devem ser baixas, porque provavelmente exigirão mudanças nos hábitos existentes, que sempre exigem esforço extra.

Mesmo se você tiver gazilhões de sugestões, basta escolher uma ou duas e demonstrar que será uma mudança para melhor.

Ou isso funcionará e você será perguntado se tem mais sugestões ou não, e o dano será limitado a uma ou duas sugestões.

Observe que é muito importante que ele se torne um sucesso e o faça rapidamente.

Além disso, você precisa ter cuidado. Pode haver muito boas razões para fazer as coisas do jeito que elas são feitas, mas que você é muito novo para ter visto o porquê. Portanto, seja respeitoso com seu ancião e pergunte antes de assumir que sua sugestão é melhor. Você pode aprender uma coisa ou duas.

Gostaria de desencorajá-lo severamente de ficar na cara dele, pois isso faria com que a situação piorasse muito rapidamente. Sei que foi levantado como um tipo de medida de último recurso, mas, na minha experiência, neste momento, o desenvolvedor parou de participar funcionalmente.

Forçar a questão pode transformar o indivíduo em um inimigo, onde eles estão lutando com todas as suas ações. Isso realmente teria um impacto negativo na equipe e não terminará até que alguém saia ou seja demitido.

Se esse indivíduo realmente tiver conhecimento de domínio que você precisa / deseja, peça que ele documente esse conhecimento.

Começando com isso para ele gentilmente: eu não sei o quão experiente e quão bem você é versado em dar feedback. Você já pode saber, empregar ou até mesmo ter rejeitado o seguinte, mas aqui vai mesmo assim. Existem algumas diretrizes para fornecer feedback quando você deseja alterar o comportamento de alguém. A estrutura de conversação em que estive pensando e ainda tento empregar em situações em que quero dar feedback (porque funcionam) são as seguintes:

1. Descreva o comportamento que você vê. Esse deve ser um comportamento concreto. Exemplo: "Vejo que você está usando muitas variáveis ​​estáticas no seu código"
2. Descreva como isso afeta você / sua equipe. Exemplo: "Acho difícil manter esse código"
3. Ofereça uma solução razoável . (as possíveis soluções são mencionadas em outras respostas, e depois eu me refiro a algumas delas).
4. Dê a ele a oportunidade de discutir a solução. Pergunte a ele o que ele pensa sobre a solução. Tome a resposta dele pelo valor nominal. Você deu a ele sua opinião e ele é livre para aceitar ou não. *

Um recurso rápido sobre feedback pode ser encontrado, por exemplo, em http://managementhelp.org/communicationsskills/feedback.htm (embora exista uma pletória desse tipo de coisa na web)

Agora, na parte da solução, pelo que estou lendo em sua resposta, entendo que ele é muito inteligente e tem a mentalidade certa, mas está apenas atrasado nas boas práticas modernas. Isso exige tempo e esforço para dominar, além do aprendizado real sobre eles, para que você tenha a oportunidade de fazê-lo. Isso provavelmente significa reunir recursos de aprendizado (web, revista, livros, o que for) como ponto de partida e fornecer tempo livre para estudá-los. Eu poderia imaginar dar a ele toda sexta-feira à tarde para ampliar seus horizontes no estilo de programação, onde ele pode fazer o que achar que é mais favorável a esses objetivos. As pessoas, inerentemente, querem melhorar a si mesmas. Forneça os materiais e o tempo, e eles farão bom uso dele.

Possivelmente o mais importante, não espere mudanças da noite para o dia. Ele está fazendo as coisas do seu jeito há muito tempo e provavelmente ficou muito bom nisso. Vai levar algum tempo para melhorar a maneira de fazer as coisas, e por um tempo, ele provavelmente não verá muito valor de novas maneiras, porque no começo não há. Seu jeito antigo provavelmente será mais eficaz por um tempo.

* Nota: o engraçado das conversas é que elas são muito difíceis de modelar. Eles têm vida própria, portanto, embora pareça agradável no papel, tende a ficar um pouco confuso.

Explique como você deseja que as coisas sejam feitas e mostre a ele como ele funciona com as escolhas de design e arquitetura que você fez para o projeto no início do projeto em que ele trabalhará. Sente-se um a um (e em particular) e explique os problemas que você viu na codificação anterior e por que eles são um problema para este projeto. Pergunte a ele o que ele precisa para melhorar, mas deixe claro que não melhorar não é uma opção.

Em seguida, use a revisão de código como uma ferramenta para fazer com que ele ajuste seus métodos de trabalho. Planeje um bom tempo para o primeiro e fale realmente sobre por que você prefere isso e deixe que ele explique seu raciocínio. Certifique-se de realmente ouvi-lo, as pessoas são mais ameaçadoras de mudar quando sentem que suas preocupações foram tratadas. Espere em seu planejamento (mas não diga isso a ele) que tenha uma reformulação na primeira tarefa e não a aceite até que atenda aos padrões de sua equipe. Uma vez que ele saiba o que você espera e que você não deixará isso escapar no interesse do tempo, ele provavelmente voltará ao seu modo de trabalhar. Mas você pode usar a revisão de código como uma ferramenta educacional para várias iterações. Você não precisa ser desagradável por não aceitar o trabalho até que ele atenda aos seus padrões, mas precisa ser firme e consistente. Don '

A pergunta de US $ 64.000 é se ele está entregando seus projetos dentro do prazo e atendendo aos requisitos de funcionalidade. Se assim for, ele está fazendo certo. Não existe um objetivo objetivo ou um caminho errado no desenvolvimento de software. Em última análise, trata-se de resolver problemas. E se os problemas forem resolvidos para a satisfação do cliente / cliente, então, por definição , o desenvolvimento de software será feito corretamente.

Torna-se uma questão totalmente diferente, é claro, se seus projetos não estiverem sendo concluídos. Nesse ponto, as mudanças precisam ser feitas por seus supervisores, talvez com a sua contribuição. Mas só porque ele está violando seu senso pessoal de estética do código ou a sabedoria convencional de hoje não significa que o que ele está fazendo está "errado". Você não é o árbitro da definição de 'bom código'. Afinal, ele pode ter uma opinião baixa do seu código.

Então ... a menos que haja realmente um problema com o trabalho dele (que você não indicou que exista), não faça nada. Parte de ser um desenvolvedor de sucesso é aprender a mesclar seu código com os estilos de outros desenvolvedores.

Afinal, ele poderia vir aqui e postar uma pergunta semelhante sobre como lidar com um desenvolvedor menos experiente, que está mais preocupado em acompanhar os modismos do que em concluir projetos. É tudo sobre perspectiva.

Como desenvolvedor júnior, conversando com um desenvolvedor sênior, é muito arriscado para você tentar abordá-lo com idéias melhores que as dele.

A melhor maneira de lidar com isso é tentar convencer seu chefe de uma melhor prática e ver se ele fará um decreto de que todo o código deve seguir padrões específicos e ser aplicado a esses padrões através de análises de código por pares.

Uma parcela considerável das pessoas é (mesmo que em um nível subconsciente) vingativa, egoísta e defensiva, mesmo que desconheça completamente seus motivos subconscientes, elas se ofenderão se você tentar alterá-las ou implicar que elas estão erradas. de qualquer forma.

A Cadeia de Comando é o caminho mais seguro a seguir, porque ele tem que ouvir seu chefe, nem precisa gostar dele. Deixe o chefe ser o cara mau, é para isso que ele está lá.

Se você não pode vender o chefe ou ele é o chefe, lide com os erros dele, mas dê o exemplo no SEU código.

Você não pode.

Você não pode inspirar as pessoas a fazer coisas que elas não conhecem no desenvolvimento de software. Falo por experiência própria, pois tentei fazer isso com frequência em minha carreira, e toda vez que o resultado final é que meu próprio status diminui aos olhos da empresa; Até fui demitido ou parei de frustração depois que nada aconteceu, simplesmente por tentar melhorar a cultura de desenvolvimento ao meu redor para as práticas modernas.

Se o seu colega de trabalho não fosse ignorante, você poderia mostrá-lo. Como eles são, no entanto, não há nada que você possa fazer, pois eles não são capazes nem se preocupam o suficiente com o software como habilidade para se esforçar para adotar melhores práticas de codificação. As chances são de que, se você tentar, elas o ignoram ou se esquivam sem entender realmente, o que, pelo que parece, é o que eles já estão fazendo ("Desenvolvimento de Tentativas e Erros", ou seja, apenas pesquisando o código até que os erros parem) .