Manuseando meu colega de trabalho antiquado

Sou um programador relativamente jovem e trabalho no departamento de TI de uma empresa de médio porte. Eu tenho um colega de trabalho e ele é realmente um bom programador do Visual Basic 6. E eu quero dizer muito bom. Honestamente. Ele pode fornecer aplicativos de trabalho, contendo muito poucos bugs, no tempo necessário para tomar minha primeira xícara de café e inicializar minha máquina. Ele é tão bom assim.

O fato é que estamos trabalhando com uma equipe e seu estilo de trabalho é completamente antiquado. Ele não acredita no software de controle de versão (se você apenas garantir que seu código está correto, não precisará de toda essa bobagem). Não acredita em implantação (eu posso entregar um executável em funcionamento. Como isso é implantado é para os administradores do sistema descobrirem). Não acredita em abstração. ('se você deseja criar uma sub-rotina, vá em frente, mas não chame nenhuma sub-rotina dessa sub-rotina. Fica bagunçado dessa maneira e o código é difícil de seguir. Dessa forma, todos podem seguir todas as etapas do caminho. 'ou' sim, com certeza você pode usar essa biblioteca para fazer isso por você, mas dessa maneira você realmente não entende o que está acontecendo ') e certamente não acredita em POO. (trabalhamos em VB.net)

Ele é tão bom no que faz, pode entregar aplicativos muito mais rápido do que eu. Mas isso simplesmente não funciona em equipe. Nosso outro membro da equipe está quieto e não gosta de se manifestar, embora ele tenda a concordar. Nosso gerente acha que eu faço pontos válidos, mas não é um programador.

Tenho muita dificuldade em manter os programas que ele escreveu, e isso não cria uma boa atmosfera de equipe. O que você acha que é a melhor coisa para eu fazer?

Parece um daqueles "Ele é um cara legal, mas ...", onde você sabe que a verdade está chegando. E a verdade parece que ele não é realmente tão bom engenheiro. Um bom software não se resume apenas à velocidade de trabalho e desenvolvimento. É também sobre as outras coisas que você mencionou - manutenção, compatibilidade, abstração (para eficiência futura), etc.

Então, dito isso, parece que você tem um desenvolvedor de problemas em suas mãos. O pior para você é que ele está provado e provavelmente está no caminho dele. Então o que você pode fazer?

• Trabalhe em torno dele.
• Esforce-se para produzir seus projetos em um cronograma tão apertado quanto ele.
• E se você não puder, produza um resultado melhor .
• Com o tempo, esses conceitos comprovados que ele dispensa começarão a valer a pena para você.

Por outro lado, se você for forçado a trabalhar do jeito dele, vá embora.

Não tente mudar de colega. Você está descrevendo-o como alguém capaz de fornecer software funcional. Provavelmente também é tarde para integrá-lo à equipe.

Então você tem duas opções:

• Adapte- se. Talvez com o tempo você consiga convencê-lo da utilidade de um sistema de controle de origem? Você terá que aumentar seu círculo de influência . Quanto mais resistente à mudança ele for, mais tempo você precisará.

• Retire-se do team. Você tem muitos pontos para justificar isso. Talvez você deva mantê-lo sozinho e se dedicar a coisas novas.

• Retire-se do company. Às vezes, esta é a única solução.

Se eu fosse você, montaria meu próprio sistema de controle de fontes agora. Comece a usá-lo para tudo o que codificar e administre-o para que seus outros membros da equipe tenham contas e possam acessá-lo. Seus outros colegas de trabalho provavelmente ficarão entusiasmados com o uso.

Seu colega que não acredita em tais práticas pode não ser fácil de convencer. No entanto, qualquer código que você seja forçado a trabalhar e que tenha sido escrito por ele deve entrar no controle de versão para poder trabalhar com ele. Quando ele precisar acessar suas alterações, envie a ele um conjunto simples de instruções passo a passo sobre como obter seu código do repositório.

Você não precisa ser combativo ou ir acima dele para envolvê-lo em processos mais modernos. Às vezes, seguir o seu próprio caminho e ser um líder em ação é mais eficaz do que tentar convencer alguém com palavras. Passos de bebê. Se ele começar a responder melhor ao controle de versão, comece a refatorar sub-rotinas e a adicionar testes de unidade para proteger contra as alterações. Automatize os testes e mostre a ele como ele pode acessar os resultados assim que fizer check-ins.

Muitas vezes as pessoas são resistentes porque não gostam de mudanças. Mas se as mudanças lhes forem apresentadas de maneira gradual e de maneira a facilitar o acompanhamento, muitas vezes eles verão os benefícios rapidamente.

Acima de tudo, torne tudo o mais simples possível para ele (mantenha as coisas simples estúpidas). Permita que ele comece a seguir essas práticas em seus próprios termos. Mas não deixe isso te arrastar para baixo.

Serei honesto, você não está pintando uma boa foto dele. Métodos arcaicos, software difícil de manter, teimoso a novas formas de trabalhar, contra abstração etc etc

Pelo que você disse, se ele está produzindo um software amplamente livre de erros, MAIS RÁPIDO do que você, sem o uso de bibliotecas reutilizáveis ​​e padrões de design voltados para o desenvolvimento rápido de aplicativos, isso diz mais sobre você, que ele ...

..obre ele .. sim, encontre uma maneira de NÃO trabalhar com ele e NÃO estar associado ao seu trabalho. Parece que ele tem uma atitude egoísta típica em relação ao seu trabalho. Você não pode trabalhar com alguém assim, só pode observá-lo funcionar e arrumar depois dele (como você atualmente).

Eu já vi isso antes ,

E estou quase disposto a apostar: esse tipo de cara só aparece "rápido" porque ele tem um conjunto de "padrões" experimentados e testados em sua cabeça. 99% dos aplicativos da Linha de negócios são CRUD , coisas básicas.

Ele provavelmente usa uma tonelada de Copiar e colar de seu próprio código existente (nada de errado nisso).

Mas..

No momento em que ele encontra algo remotamente complexo, cai, por quê? porque não se encaixa mais em nenhum dos "padrões" básicos.

Um pequeno desafio ...

Eu criaria um projeto paralelo, um projeto complexo que realmente se beneficia da OOP e da reutilização de código.

Em seguida, mostre esse projeto e peça para implementá-lo recurso por recurso.

Eu apostaria que seu código quase certamente será 10 vezes maior e 10 vezes mais feio se ele o tivesse implementado do seu jeito.

Veja isso do lado comercial.

Você leva mais tempo para produzir código com erros. Você produz menos receita, portanto é péssimo.

Se, com o tempo, você puder reverter isso, poderá reverter isso.

Mas talvez, apenas talvez, esse programador antiquado possa realmente ensinar algumas coisas sobre a produção rápida de código que é tão livre de bugs? Talvez suas técnicas não sejam tão antigas quanto você pensa?

Acho suspeito que alguém possa produzir um código tão bom sem algumas boas práticas. Você pode aprender essas práticas e aplicá-las às "melhores práticas" e às coisas da moda que você entende.

Se o seu gerente não for um programador, tente colocá-lo em termos que ele entenderá.

• Devemos usar o controle de fontes, porque, se não o fizermos, poderemos ter grandes problemas para recuperar

• Demoro x mais tempo porque ele se recusa a seguir alguns processos bastante básicos.

Por outro lado, certifique-se de não ficar muito envolvido com a perfeição, ou seja, esta é uma prática recomendada que devemos segui-la. É provável que seu colega de trabalho tenha muito a acrescentar; talvez você precise cutucá-lo na direção certa lentamente.

Parece que seu colega de trabalho nunca se desenvolveu em uma equipe. Esse tipo de parceiro solo de guru não permite uma boa dinâmica de grupo. Portanto, conte ao seu superior e tente discutir os prós e os contras com o seu parceiro. Se você pudesse fazê-lo da melhor maneira possível, mas se ele recusar, suba no cahin de comando

Converse com seu gerente, pura e simplesmente, como você fez aqui. Aqui há potencial de crescimento - se seu colega de trabalho é bom como você diz, não deve ser muito convincente para fazê-lo começar a se converter em usar o controle de origem e o .Net com os conceitos adequados de OO.

Eu conversava com outras pessoas para obter uma imagem mais ampla de como as coisas parecem onde você está. Talvez haja algumas separações para que o código dele não precise se misturar muito com os outros, pois existe o potencial de segregá-lo em sua própria área, de uma maneira que isso poderia ser tratado, embora isso seja mais para uma pessoa mais alta como uma diretor ou CIO para criar, em vez de desenvolvedor.

Você pode conversar com ele para ver que tipo de sistemas maiores ele construiu, pois existem alguns sistemas corporativos grandes que tendem a ser muitos blocos de construção em que o código espaguete pode ser executado na região de "Oh, é por isso que OOP pode ser bom! " embora isso às vezes leve o caso em que é bastante útil ver como isso pode ser útil na caixa de ferramentas.

A apatia pode ser outro suspeito para ver se é por isso que ele rejeitaria algumas coisas que eu consideraria fundamentais em termos de como eu desenvolvo o código, mas talvez eu tenha recebido muito do Kool-aid.

Desafie-o (de uma maneira boa) a provar o contrário, mostre-lhe o lado legal das ferramentas e práticas. Não apadrinhe.

Por exemplo, talvez ele não acredite no controle de versão como uma ajuda, mas mostre a ele como ramificar / mesclar e como ele pode trabalhar em vários recursos experimentais sem precisar ter um monte de arquivos.

Em relação ao POO, mostre a ele alguns padrões de design interessantes / complexos, como o padrão de comando, o padrão de tarefa e como ele pode economizar um tempo valioso e toda a sua equipe.

Se você não o interessa nem um pouco ... ele pode ser um caso perdido, mas, novamente, você tem as ferramentas para o seu time e o supera. Tente usar um software de repositório que mostre / envie mensagens de e-mail que seu gerente pode ver, que trarão transparência ao seu gerente e deixarão seu colega de lado (o bitbucket.org possui repositórios particulares gratuitos com espaço ilimitado, se você usar mercurial).

No final, não tente convencer com palavras, mas com ações irrefutáveis, essa é a melhor maneira de lidar com pessoas teimosas IMHO (a psicologia reversa às vezes também funciona, lol).

bem, as técnicas mencionadas são obviamente boas, mas você também precisa se perguntar se as está empurrando como ideologia. Acho que os programadores mais jovens tendem a ser um pouco evangélicos sobre o que aprenderam na faculdade. lembre-se de que essas técnicas são boas por causa de resultados: o controle de versão permite o desenvolvimento simultâneo, um rastreamento mais claro dos estágios de design, desenvolvimento, teste e correção de bugs. se seus projetos são realmente de curto prazo, muito disso é simplesmente inapropriado e acabará tornando-o menos ágil. simplesmente não é o caso que a melhor prática signifique usar todas as melhores práticas possíveis. a abstração, por exemplo, definitivamente pode ser mais uma obrigação do que uma ajuda, pelo menos algumas vezes. o controle de versão faz mais sentido quando você estende cronogramas de desenvolvimento, código complexo, vários programadores - existe uma espécie de sinergia, que é difícil de obter tração aos poucos.

Acho que o ponto de partida é ficar atento a possíveis reutilizações - à medida que os projetos passam, pensamos em pontos em comum ou em estruturas mais gerais. tentar sair na frente dos projetos seria uma jogada poderosa e pode permitir que você trabalhe com mais técnica ...

Você deve pedir ao seu supervisor que faça uma apresentação para TODOS sobre por que o software de "versionamento" é bom. Não escolha seu colega de trabalho.

Sou um cético em relação ao software de controle de origem, porque vejo as pessoas fazendo mau uso o tempo todo - como uma maneira de evitar o trabalho.

Meus colegas de trabalho estão constantemente se fundindo, pisando constantemente nos dedos uns dos outros. Mas uma boa palestra amigável sobre seus benefícios seria uma coisa agradável e estimularia discussões.