O que fazer com os desenvolvedores estrela que não documentam seu trabalho? [fechadas]

https://stackoverflow.com/questions/532338

collaboration

22-08-2019
|

Pergunta

Há um colega que conhece a sério as coisas dele, ele é um dos mais brilhantes que eu já trabalhei, mas ele:

trabalha em sua própria pequena área de seu diretório home e não no comum CVS repositório
não documento seu código
não comentário seu código, por exemplo, 3.500 SLOC de C sem comentários e sem linhas em branco para quebrar as coisas
muitas vezes overcomplicates coisas, por exemplo, usa três shell scripts que chamam um ao outro para fazer o trabalho que um shell script simples poderia fazer.

Talvez isso possivelmente é uma daquelas pessoas que pensa "se eu sou a única pessoa que sabe disso, eles não podem se livrar de mim"?

Todas as sugestões sobre o que fazer?

BTW Gestão sabe sobre a situação e estão tentando mudar as coisas.

Solução

Na minha opinião alguém fazer essas coisas estúpidas que você tenha descritos acima não podem ser um desenvolvedor estrela! Para mim parece que ele intencionalmente torna as coisas mais complicadas como eles são, de modo que ninguém mais do que ele pode manter o código. Isso torna-se mais importante do que ele realmente é! Fale com ele. Ele tem que mudá-lo! Se ele não faz, substituí-lo com uma verdadeira estrela-desenvolvedor!

Eu te prometo, no mesmo meio ano ele não vai saber como suas próprias obras de código! Demiti-lo e você pode economizar muito tempo e dinheiro.

Outras dicas

A parte CVS é ??fácil - uma falha no disco rígido "acidental" vai ensinar-lhe uma lição para uma vida (verifique se você tem um backup embora assim que você não irá realmente código perder)

Isso soa como uma situação difícil.

Pessoalmente, gostaria de deixá-lo ir. Ele pode ser um desenvolvedor de estrela, mas ele não é um jogador da equipe. E você precisa ter uma equipe coesa que pode trabalhar em conjunto, se você quiser fazer um bom produto.

Na falta de documento é uma maneira (muito ruim) para garantir a segurança no emprego.

Você pode fazer várias coisas para contrariar esta:

documentação add como um requisito para as avaliações de desempenho pessoal.
não aceitam software que não está documentada.
ter uma palavra com o desenvolvedor e descobrir por que ele não tem documento.
Comprar um instrumento de documentação legal.

Jogue o bad cop / bom policial esboçar ter visto a partir dos filmes. Deixe o gerenciamento ser o polícia mau e você ser o bom policial. Deixe o managament pedir mais-kill documentação e por minuto ZIP backups do seu trabalho. Mas você tem a oferecer documentação (por doxygen por exemplo) e de controle de origem check-ins habituais ...

-lo moderada

Fale com ele?

Se ele realmente é um "desenvolvedor estrela" ele vai tomar nota do que você diz.

Pode não mudá-lo durante a noite, mas pode ser que ele é apenas completamente inconsciente de que outras pessoas não entendo completamente como ele faz.

Editar:

É provavelmente um pouco tarde para mudar agora, mas é necessária mais informação na elaboração de uma solução. É impossível para qualquer um aqui para realmente sugiro deixar o cara ir com base apenas nesses pontos. Se você estiver dizendo a cara todos os dias durante o último ano em que ele precisa mudar ou ele está fora daqui, então você pode deixá-lo ir. No entanto, não vejo nenhuma evidência disso.

Um desenvolvedor brilhante pode ser ensinado a usar controle de origem, comentário e documento. Se você gastar o esforço aqui, então você realmente vai ter um desenvolvedor estrela.

Você pode estar se concentrando na área errada aqui, você está sendo fornecido com a oportunidade de ver alguns pontos fracos no seu processo.

trabalha em sua própria pequena área de seu diretório home e não no CVS comum repositório

Um simples bate-papo serão suficientes aqui, os benefícios de falar de controle de versão para si e para qualquer pessoa "brilhante" provavelmente seria entusiasmados com esses benefícios. No entanto, também pode ser uma boa oportunidade de olhar para sistemas de controle de versão alternativas que permitem maior facilidade de uso e flexibilidade (vejam o bzr e git). Melhor ainda, levá-lo envolvido no processo de seleção, se ele realmente é uma "estrela" que ele provavelmente vai ter boa entrada e ser mais investidos na sua utilização.

não documentar seu código

Ele não soa como documentação faz parte do seu processo. As pessoas estão indo para resistir ter que fazer trabalho extra e se não houver um processo definido, então você está falando de um monte de trabalho extra. É a documentação realmente necessário? Se assim for, há um processo definido para criá-la? se você tiver alguém inteiramente dedicado a ele? Se você pelo menos tem uma ferramenta para facilitar isso (talvez algo tão simples como MediaWiki)?

não comenta seu código, por exemplo, 3.500 SLOC de C sem comentários e sem linhas em branco para bico coisas

Três palavras: revisão por pares código. Fora de benefícios atraente erro óbvio, isso também pode fornecer alguma pressão dos pares, que é uma força forte e pode ser uma coisa boa. Querendo ser percebida também por seus pares auto-gera propriedade e qualidade.

muitas vezes overcomplicates coisas, por exemplo, usa três scripts shell que chamada um outro para fazer o trabalho que um shell script simples poderia fazer.

Mais uma vez, peer revisão do código. Você menciona que a administração sabe sobre deficiências este programador. Será que ele? É um pouco difícil para as pessoas a mudar e melhorar, se eles não reconhecem os problemas com a forma como eles estão fazendo as coisas.

E, talvez o melhor de tudo, por surgir com planos para melhorar o seu processo de desenvolvimento (que provavelmente vai melhorar não só a sua "estrela", mas todos os outros na equipe), você provavelmente pode ganhar algumas estrelas de ouro para si mesmo de gestão.

Não soa como muito de um programador de estrelas para mim. Todos os bons programadores sabem que formatação de código e uso de questões de controle de origem. Parece que, embora ele faz um bom progresso por si mesmo, ele está obstruindo o progresso dos outros membros da equipe, o que pode ter um efeito líquido negativo sobre o trabalho sendo feito. Fale com ele, e se ele se recusa a mudar suas práticas, deixá-lo ir.

Se ele realmente é tão brilhante e você não pode mudar os seus caminhos, nem você quer perdê-lo, mas você ainda quer que seu código a ser documentado e comentado, em seguida, a minha sugestão seria a de deixar um desenvolvedor menos experiente fazer a documentação e comentar para ele. Pessoalmente, se eu fosse um desenvolvedor estrela Eu me sentiria prettiy tolice se alguém foi feita a comentar meu código e eu ia começar a fazer isso sozinho eventualmente. Nesse meio tempo, enquanto isso não acontece o desenvolvedor menos experiente pode aprender uma coisa ou dois.

Há mais a ser um desenvolvedor estrela do que apenas ser um excelente programador. Se ele não tem habilidades da equipe e é propositadamente ignorando os padrões da equipe que precisa ser levado até ele. Se ele se recusar a aderir a eles depois de falar com a gerência, talvez ele não é o ajuste certo para sua empresa.

Esta questão me deixa nervoso, porque enquanto a pessoa que você está descrevendo sons notório, eu posso ver um pouco de mim mesmo nele.

Eu acho que eu sou um jogador de equipe muito bom, e eu tenho sorte de estar em uma equipe muito boa. No entanto, eu faço métodos de uso que os meus colegas não entendem, embora eu tentei muito difícil explicá-los. Não apenas é um muito grande lacuna experiência, que não é nenhuma reflexão sobre qualquer um de nós.

A documentação é um assunto amplo e complicado. Tento seguir o DRY (não repetir-se) máxima. Documentação que é separado do código pode ascender a repetir-se, por isso, é susceptível de sair da data a menos que você retardar-se para baixo para mantê-lo atualizado. Minha abordagem usual é tocá-lo até mais tarde.

Muitas vezes, o problema que estou trabalhando é tão complicado que eu possa avançar planejar e documentar tudo que eu quero, mas quando se trata do código muitas vezes eu descobrir que eu estava errado e tem que re acha-lo. Assim, a idéia de que você pode documentar o material com antecedência, e basta seguir que, só funciona para problemas simples bonitas, parece-me.

De qualquer forma, penso que esta é uma excelente pergunta, ea resposta não é de todo simples.

É o cara realmente uma estrela do rock? Seriamente? Pense nisso por um segundo. Ele é inteligente, mas não fazer as coisas, ou ele é inteligente e capaz de fazer as coisas?

Pense nisso realmente difícil.

Se ele realmente é uma estrela do rock, então talvez você não deve mexer com ele. Ele está produzindo coisas incrivelmente impressionante Usando seu próprio processo. Só porque há uma maneira diferente de fazer as coisas que funciona melhor para você, não significa que vai capacitá-lo para produzir o seu melhor trabalho. Em vez de tentar levá-lo a dobrar para o seu processo, que poderia muito bem matar toda a sua grandiosidade, você deve tentar e encontrar uma forma para acomodar a forma como ele funciona.

Se ele realmente é tão bom como você diz, você não deve se importaria de fazer isso. Se não vale a pena o esforço para fazer isso, então ele realmente não é tão bom. Nesse caso, você não tem uma estrela do rock, você só tem um programador medíocre que não gosta de jogar ser as regras. Esses caras, você deve apenas se livrar. A estrela do rock temperamental é geralmente vale a dor, no entanto, por causa da qualidade do que ele ou ela pode produzir. Essas pessoas, você deve ir para grandes comprimentos para manter.

soa como um programador estrela que está cansado de seu trabalho e acabou complicando as coisas para torná-lo mais de um desafio. Ele vai encontrar algo melhor em breve.

Tentando mudar as coisas? O que você prefere, um pedaço mal documentados de trabalho de software ou um lixo bem documentado? Algumas pessoas é capaz de escrever software que requer pouca ou comentários, que não é um indicador confiável de qualidade.

Eu tenho medo que você vai perder um bom desenvolvedor.

"Hi Estrela Developer,

apenas um pouco de heads-up informais para dizer-lhe que a partir da próxima semana, vamos estar exigindo documentação de código, e útil comentando no código - que vai ser a política da empresa, e não haverá exceções "

A partir de então, você só lidar com essa falha o mesmo que você iria lidar com uma falha de transformar-se no tempo, uma falha de parar jogando conversa fora durante o trabalho, etc. A linha inferior é se o patrão diz documento, documento ou você não está fazendo seu trabalho corretamente.

Se ele está trabalhando assim, ele não é um desenvolvedor star - grandes desenvolvedores de software entender que manutenção é extremamente importante. Você provavelmente vai pagar caro por isso, a longo prazo, eu seria muito direto com ele sobre como isso é sério e deixá-lo ir, se ele não pode começar a ajustar. Eu já vi isso muitas vezes antes e é uma bomba-relógio.

Para ser perfeitamente honesto, eu vi muita desenvolvedores como este e, a menos que sejam apenas fora da escola, eles não vão mudar. Eu digo cortar seu lossless agora, a sua só vai ficar mais difícil para demiti-lo como ele continua a vomitar código mais insustentável:)

É muito improvável que a gestão vai se livrar dele se ele é realmente brilhante.

O projeto inteiro pode ser fechado, é claro, mas não haverá uso em CVS e documentação, em seguida, de qualquer maneira.

Sem gestão irá disparar um bom programador apenas para contratar um mau.

Diga-lhe que ele vai ajudar ele para se livrar de administração sempre que ele quer.

O que é que ele quer mudar de emprego? Ele pode dizer gestão: "OK, as pessoas, tudo é exatamente como você me perguntou:. Check-in, documentado e sob a controlar Eu estou feito com a minha parte, eu embalar e licença".

Pode a equipe ser bem sucedida sem ele? Se assim empurrar o problema e se recusam a aceitar qualquer código que não está devidamente documentados ou não cumprir outras normas. Esperemos que isto irá obter o ponto de mas ele só poderia fazê-lo com raiva e levá-lo a desistir. Se a equipe não pode ter sucesso sem ele, então você está fora de sorte até que você pode treinar um substituto até o seu nível de habilidade que pode não valer a pena o tempo e esforço.

+1 para ocdecio -. Se ele é um desenvolvedor de estrela, em seguida, seu código deve ser baseada em um design tão alta qualidade que documenta-se

Dito isto, a frustração pode ser que embora seja excelente em áreas tecnicamente exigentes que são interessantes para ele, ele não faz muck-in com a entrega de recursos - você só vai saber se isso é um problema para o seu organização.

Ter um "guru" disponíveis pode ser um salva-vidas absoluta - ou, pelo menos, que costumava ser, ou tenha StackOverflow fez essa redundante papel

Não deixe que o código ser lançado revisão de código até que ele passou e só permitir que passe se houver comentários e / ou documentação suficiente para o código que ele escreveu para o atual recurso / projeto.

Editar levá-la em sua avaliação. Documentação / code comentando pode ser dado a ele por suas "áreas de melhoria".

: -)

Você também pode adicionar controles de qualidade automatizados que impediriam o check-in seu código até que foi suficientemente documentada.

Isto é, se você pode convencê-lo a fazer o check-in em primeiro lugar! (O que é essencial, imo)

Há um monte de gente aqui nos "comentários, e daí?" movimento aqui. código de alfabetizados sem comentários é perfeitamente possível, mas só porque alguém é inteligente e não comenta, não significa necessariamente que eles estão escrevendo código alfabetizados.

Então, vamos esclarecer. Você já disse que não documentar seu código em tudo, seja em comentários ou documentos separados e ele não usa nenhum controle de origem. Que tal:

É seu código compreensível apesar da falta de comentários?
A sua utilização equipa qualquer tipo de acompanhamento de problemas (por exemplo FogBugz, Bugzilla, etc), que participa?
É o seu código sob teste?
Existe mais alguém na equipe que realmente é, pelo menos um pouco familiarizado com a forma como suas obras de código?
Ele está disposto a pelo menos reconhecer que ele poderia estar a fazer algumas mudanças na forma como ele trabalha com o resto da equipe?

Se a resposta a todas estas perguntas é "não", você tem um grande problema. Basta ser inteligente não necessariamente fazer alguém um ativo. Você tem qualquer garantia de que ele não vai deixar o seu amanhã empresa, ou ser atropelado por um ônibus? Como parafusado você seria se isso acontecesse? Vale a pena o risco?

Eu acho que isso é muito típico em qualquer ambiente. Como você arranjar alguém para fazer o que quiser? Este é exatamente o "Como Fazer Amigos e Influenciar Pessoas" tem tudo a ver. Dale Carnegie não era sobre a manipulação, mas gestão de pessoas.

Parece-me que ele é apenas inexperiente e precisa de alguma experiência e orientação.

Você acha que você pode sentar e conversar com ele sobre estas questões? alguém dizendo que eles estão fazendo algo errado, muitas vezes parece que a coisa errada a fazer (especialmente na sociedade ocidental de hoje, onde nós não queremos ferir os sentimentos de outras pessoas), mas eu acho que você pode ir muito longe por calma e honestamente explicando os problemas e falando-los passar. Ela ajuda se a pessoa aspectos você e sua opinião, o que é uma questão totalmente diferente e é falado no livro mencionado acima. Certifique-se de que ele entende que estas são questões sérias. Além disso, que em futuras tarefas de desenvolvimento que ele vai ter que fazer essas coisas também, então é uma boa idéia para praticá-los agora.

Eu não acho que esperar até a próxima avaliação de desempenho é uma boa idéia. Acumulando um monte de feedback negativo e entregar tudo de uma vez é apenas uma má idéia e eu realmente não gostava quando isso foi feito para mim.

documentação

Code está classificado. formação CVS é ??fácil.

Uma classe bem deve revelar o seu objectivo através das suas propriedades e métodos.

Documentar o exterior modelo da aplicação também é mais fácil de fluxo e compreender.

Gostaria de trazê-lo para a sua atenção, se você não pode resolvê-lo parece que você estará perdendo um desenvolvedor estrela.

Edit: Oops -. CSV usado em vez do CVS, para muitas importações e eu uso svn heh

Levá-lo a usar as ferramentas de execução de verificação de automatizadas. (Veja a minha resposta em " Como fazer perguntas a um obsructionist? ")
Se ele overcomplicates e não usa SCC, ele é não um excelente desenvolvedor -. Estas coisas são partes importantes de engenharia de software
No caso muito improvável que ele tem algum brilho insubstituível em áreas como algoritmos, atribuir-lhe ao trabalho nessa área, por exemplo, a definição de algoritmos, e obter um verdadeiro programador para fazer a codificação.
Use o código de análise estática de entender e limpar seu código.

Par de programação. Localizar Hima par que vai "completa"-lo para os requisitos que você apenas listados. Você vai resolver um controle de fonte problema vontade, documentação, pergunta todas suas ações, etc. Você também treinar outro cara usando primeira força cara

Do que você descreve, esse sujeito é distintamente não um desenvolvedor estrela. A programação é um esporte de equipe, e aqueles que não joga bem com os outros não acrescentam muito valor a um projeto.

Pessoalmente, eu não poderia lembrar código que eu escrevi 6 meses ou mais atrás, e muito valor histórico das mudanças em algum tipo de controle de origem.

Se você tivesse regulares revisões de código com esse cara eu acho que você iria ver que ele não é tão estelar de um desenvolvedor como você acha que ele é.

Eu concordo com a maioria das pessoas sobre esta discussão. Uma maneira de colocá-lo no ponto quente é ter Código de equipe Comentários.

Para a primeira reunião de revisão de código escolher código de um membro da equipe que está aberto e vai aceitar as recomendações. O desenvolvedor "estrela" terá a oportunidade de ver como a revisão de código funciona e, em seguida, você pode programar o seu código a ser revisto no próximo. Dê-lhe algum tempo para se preparar para a próxima reunião e então ele deve ser, pelo menos, comentando seu código.

A intenção de revisões de código não é para colocar uma vergonha para as pessoas, mas sim de forma colaborativa identificar problemas e lugares para a melhoria, mas vai ser uma boa maneira de colocar o desenvolvedor estrela na berlinda.

Na minha opinião, você precisa soltar esse cara. Parece que seu código é ilegível e ele definitivamente não é uma equipe, nem um cofre, leitor.

Também é uma prática muito ruim para permitir que alguém se vêem como indispensável. Se você deixar ele continuar assim, suas práticas vai piorar, não melhor. Quando ele sai, para todo mundo faz, você vai ficar com uma enorme dor de cabeça de código emaranhado. Você precisa cortar suas perdas agora, se ele não vai moldar-se.

Finalmente, mantendo este desenvolvedor sem reinando ele em conjuntos um mau exemplo de desenvolvedores junior. Se você forçá-los a funcionar corretamente, você corre o risco ressentimento do "por que ele e não eu" multidão. Se você não fizer isso, você recebe um monte de hacks que trabalho como o seu "estrela".

Em suma, a menos que ele molda-se muito, muito rapidamente, é hora de deixá-lo, para a saúde e sanidade de toda a sua equipe de desenvolvimento.

Nós tivemos um problema semelhante quando eu comecei meu trabalho atual um pouco mais de 3 anos atrás, a nossa principal desenvolvedor era um cowboy. Ele era muito inteligente, mas muito irregular, algumas de suas coisas foi muito bem documentado, mas tão excessivamente complicado era imposable de manter, ou código primeiro e descobrir o que ele estava construindo mais tarde, ele iria jogar fora o código para ver o que iria ficar.

Ele deixou cerca de 2 1/2 anos atrás, e ele ainda está nos assombrando quando encontramos algum do seu código antigo, e em sua defesa que é como a loja de desenvolvimento aqui foi executado naquela época, nos últimos 3 anos tenho sido em uma cruzada para mudar essa mentalidade.

Quando você se tornar um desenvolvedor estrela deixa de ser tanto sobre quão bem você conhece o sistema, código, estrutura, arquitetura, etc, e mais sobre

Escrever código elegante, sustentável, flexível, legível
Trabalho com o resto da equipe:. Utilizando o controle de origem, levando por exemplo, etc
documentar o que cada método, classe, objeto, etc está fazendo
Pesquisando novas e melhores maneiras de fazer as coisas por si mesmo, e sua equipe

Se o seu não seguir todos os quatro deles em algum nível você não é um desenvolvedor de estrela, ainda mais se você se recusar a tentar / aprender a usá-los, em seguida, é hora de que deve encontrar outras oportunidades de emprego de uma forma ou outra, eu ouço fome artista é popular com este tempo de pessoa (o todo misunderstand gênio coisa)

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow