Quando alguém seria considerado um mau programador? [fechadas]

Como você consideraria que um programador é ruim no que está fazendo?

Se possível ... Como ele / ela deve melhorar?

Quando eles não conseguem aprender com seus erros e com as revisões por pares.

Nós somos todos verdes em algum momento; no entanto, se você não está melhorando ou tentando melhorar, é um programador ruim.

Um programador que não sabe o que não sabe e não está interessado em descobrir.

Um grande sinal de alerta é se eles são um programador de "cult de carga" - o que significa que eles fazem coisas, mas não sabem por que fazem essas coisas (é apenas "mágica"). Ótimo post de Eric Lippert aqui .

Do artigo:

programadores que entendem o que o código faz, mas não como ele faz.

Uma grande dica para mim é quando eles fazem perguntas a você ou a outros programadores que mostram claramente que não fizeram absolutamente nenhum esforço para descobrir por conta própria.

Um corolário é quando eles fazem a mesma pergunta de programação várias vezes, indicando que não estão internalizando as informações.

Quando eles levam muito tempo para resolver o problema do FizzBuzz.

Programadores que se recusam a aprender novas tecnologias / linguagens e insistem em seguir o que já sabem.

Adendo: (adicionando o traço dito abaixo nos comentários)

Uma extensão disso são as pessoas que conhecem um subconjunto da funcionalidade de alguma tecnologia, mas não mostram desejo de aprender mais nada sobre ela. Linguagem de programação, editor, outras ferramentas ...

Quando um membro da equipe é o desenvolvedor produtor negativo .

|# Lines Written| - |# Lines of bugs introduced| - |# Lines of rework required| < 0

Isso significa que o restante da sua equipe precisa trabalhar mais por causa do desenvolvedor ruim. NNPP

Quando eles produzem coisas que pertencem regularmente ao The Daily WTF .

Quando eles sabem que existem maneiras melhores de fazer as coisas, mas ainda se recusam a fazê-las, mesmo quando o tempo permite.

Pessoalmente, acho que qualquer programador que possa ver seu próprio código que escreveu há algum tempo e não encontrar algo errado com ele não é bom. "Um tempo" pode ser dimensionado com a experiência ... eu diria entre algumas semanas até um ano ou mais.

Aqueles que ignoram avisos em seus códigos e se importam apenas com erros.

Quando eu era líder de equipe em uma loja pequena, havia várias pessoas que eu deveria ter transferido (nem eu nem meu supervisor direto tinham capacidade de rescisão sem uma tonelada de burocracia e uma pilha de documentação) ou para não ter renovação de contrato. no final do compromisso atual. Alguns dos tipos enumerados também funcionaram para outros líderes de equipe, e eles adotaram a mesma visão. Coisas que levaram as pessoas para a categoria "Programador ruim" no meu livro:

1. Intreinável ou ossificado no passado
   Quando o 'programador' parece não ser capaz de absorver o novo sistema, nova ferramenta ou o que está sendo implantado, não importa como o treinamento / educação é realizado. Tem que repetir o referido treinamento com frequência.
   Quando o 'programador' conhece apenas a tecnologia ou o paradigma de codificação que eles usaram 10 ou 15 anos atrás. Foi bom o suficiente então, então por que eles deveriam mudar?
2. Codificador de cowboy
   A pessoa que codifica primeiro, sem um plano. O 'programador' que faz alterações não testadas no código de produção e / ou dados "porque precisamos corrigi-lo agora" e fica surpreso quando a "correção" falha.
   O Cowboy também definitivamente não é um jogador da equipe. Não precisa de nenhum time fedorento.
3. O cata-vento
   Este 'programador' é apaixonado pela "tecnologia do dia " e vê toda nova estrutura, linguagem, metodologia ou qualquer coisa nova e quente como a
4. O "grande cérebro"
   Esse 'programador' tem tanta certeza de seu talento e capacidade que são feitas coisas que não fazem muito sentido no projeto. por exemplo, reescrevendo uma biblioteca padrão "porque é ineficiente para o nosso sistema" ou introduzindo ferramentas e técnicas inadequadas para o problema em questão. por exemplo, introdução do Lisp ou Forth em um ambiente de mainframe.
5. LOC ^a. Sandbagger
   Este 'programador' usa ofuscação e direção incorreta para aumentar o ^a. LOC: linhas de código que são pagas. Eu vi código nessa situação que era página após página, tela após tela de estrutura e lógica duplicadas, com apenas os nomes das variáveis ​​de parágrafo ou controle alterados para aumentar a contagem de linhas.
6. Especialista Indispensável
   O 'programador' que possui o conhecimento do domínio para resolver os problemas em questão, mas desde que "sabem" tudo sobre ele. De fato, se eles fossem atropelados por um ônibus, toda a organização desabaria. { Observação: Aqueles que pensam que são indispensáveis ​​geralmente são. (Alguém conseguiu a fonte desse aforismo?)}
7. The Pasta Chef
   Esse 'programador' é especializado em código de espaguete, temperado com identificadores difíceis de seguir sem um IDE implementado sintaticamente. por exemplo , IndexI1O0, Index1I0O, etc.
8. Estagiário de verão - subtipo específico do Walking Disaster
   Minha antiga loja costumava contratar vários estagiários no final do ensino médio ou em idade universitária. Uma vez, um departamento precisou de um pequeno banco de dados para rastrear o uso de alguns equipamentos (agora isso estava atrasado e estava usando o dBase III). O cara codificou durante todo o verão, mas não foi concluído quando a faculdade começou no outono. Ele recebeu uma extensão de uma semana e depois uma segunda semana. No final da segunda semana, fui enviado para assumir o projeto dele e trazê-lo de volta ao Desenvolvimento de Sistemas para ser concluído. Ele me mostrou o que tinha feito e depois a parte inacabada. O que funcionou teve um bom colírio para os olhos, mas o aplicativo foiincompleto. Quando abri a nova caixa de disquetes formatados para obter cópias, ele disse: "só um segundo, deixe-me excluir meus arquivos de teste ..." e antes que eu pudesse dizer qualquer coisa, ele havia excluído vários arquivos.
   Sendo do tipo suspeito, e descobrindo que o aplicativo dele era quase nada além de colírio para os olhos quando voltei para a minha loja, voltei ao departamento, peguei o Norton e cancelei a exclusão dos arquivos que ele havia excluído, tentando encontrar alguma lógica adicional, mesmo que incompleto.
   Eu achei, não lógica ruim, mas mau comportamento. A impressora conectada ao PC que ele estava usando era uma impressora de margarida. O conjunto de caracteres normalmente montado era uma variante suíça. A saída dos programas excluídos coloca um nome, endereço, DOB, alguns códigos de letras e algum tipo de número de identificação. O formato e o layout me incomodaram. Todas as datas de nascimento de várias pessoas eram apenas a idade legal para beber. A maioria dos endereços não estava lá quando os procurei em nosso diretório cruzado. Quando mostrei as impressões para o supervisor dele, ele olhou para mim e disse: "Carteira de motorista, você não acha?" Eu disse que fiz. Ele disse que foi por isso que encontrou o material de transparência todo cortado no lixo ao lado da Xerox. Nosso garoto mau tinha sobreposições para ajustar a idade dele e de seus amigos em suas carteiras de motorista. Nós o denunciamos às autoridades.não pago por suas últimas duas semanas.

Estes são apenas alguns dos personagens ruins com os quais tive que trabalhar ...

/ s / BezantSoft

Incapaz de se adaptar às próximas tecnologias

Além da óbvia falta de conhecimento / habilidade, um programador é ruim, se o código for mais difícil de ler e / ou manter do que deveria.

Quando ninguém mais pode ler seu código. Não importa o quão brilhante você é; nenhum programador é uma ilha.

Alguém que não presta atenção aos detalhes e está sempre no modo "funciona, então estou deixando isso em paz. Todas essas exceções nos logs não importam".

Existem duas categorias para programadores para mim - solo e equipe.

Os programadores solo ruins são

• Aqueles que demoraram muito para realizar a tarefa simples.
• Aqueles que não podem pesquisar sozinhos o que estão fazendo.
• Aqueles que esquecerão o que foi codificado hoje em poucos dias e não poderão manter muito bem sua própria base de códigos.
• Aqueles que não conseguem se adaptar aos requisitos mudam.

Os programadores de equipes ruins são aqueles que se enquadram na categoria de programadores solo ruins, incluindo

• Aqueles que não conseguem coordenar com outros membros da equipe.
• Aqueles que não aceitam críticas.
• Aqueles que não sabem como ser útil para os outros e como se beneficiar de outros membros da equipe.
• Aqueles que não sabem escrever código legível.
• Aqueles que não comentam por questões de legibilidade para os outros.

Não está disposto a admitir que não sabe a resposta e / ou não quer procurar as coisas.

Se você não souber, não desista - descubra e faça.

Um grande sinal de alerta na minha experiência é quando eles não comentam seus hacks ....

Você sabe o que quero dizer: quando você é forçado a fazer algo muito hacky, porque simplesmente não há maneira melhor de fazê-lo.

Bons programadores odeiam ter que fazer isso e colocam comentários embutidos dizendo o quanto odeiam colocar esse tipo de invasão, mas não há escolha. Programadores ruins apenas colocam o hack e não comentam.

Silêncio, obviamente, quando um programador escreve MUITO código. Funções muito grandes, talvez copiar / colar linhas ou blocos de código, usando muito mais ifs do que o necessário etc. Isso pode ocorrer porque o programador não conhece uma função padrão para fazer o que deseja, mas na maioria das vezes não é.

Ser repetidamente mostrado o caminho certo para fazê-lo e repetidamente apenas fazê-lo da maneira mais fácil.

Estou movendo minha resposta para aqui de um tópico duplicado fechado que perguntou: Você consegue reconhecer se é um programador ruim? O outro tópico estava sendo fechado enquanto eu escrevia minha resposta. Minha resposta aborda mais diretamente a pergunta, como foi formulada pelo outro solicitante e, se você entender isso, lerá melhor.

Suspiro! Parte de mim não queria adicionar esse tópico já ocupado, mas a outra parte venceu! Por que ganhou? por que estou me preocupando em adicionar mais palavras a esse multilogo específico? Bem, porque, até certo ponto, eu posso ter uma visão um pouco diferente disso que os muitos comentaristas anteriores.

O binário funciona muito bem em computadores: é '1' ou '0', "ativado" ou "desativado". Podemos abstrair e codificar muitas informações usando esses dois estados famosos. Mas isso não costuma funcionar tão bem em assuntos humanos: "bom" ou "ruim", "sã" ou "insana", "boa" ou "má", "inteligente" ou "estúpida", "gorda" ou "magro", "vivo" ou "morto?" Esse tipo de avaliação polarizada sempre deixou o ser humano atencioso parte de mim terrivelmente insatisfeito. Quaisquer que sejam os esquemas de medição que eu opte por aplicar, geralmente descubro que as respostas para esses contrastes realmente estão em algum lugar ao longo de um continuum entre um desses polos e o outro, e não em ambos os lados.

Já luto com essa tendência à polarização há algum tempo, e minha solução pessoal é que acho muito mais útil aplicar três palavras a essa avaliação: " em que grau!"

Portanto, minha resposta para sua pergunta é sugerir que você a reformule e se pergunte: "Até que ponto sou um mau programador?" Ou, melhor ainda, perguntar em outra direção: "Até que ponto sou um bom programador?" Se você busca a verdade, provavelmente se localizará em algum lugar ao longo de um continuum entre ser um programador "ruim" e um "bom". Então, quando você conseguir localizar aproximadamente onde está nesse caminho, provavelmente poderá identificar um ponto um pouco mais próximo do final "bom" - um ponto em que você gostaria de se encontrar no futuro próximo.

Se você não definir esse ponto muito longe, provavelmente poderá engatar a traseira e começar a movê-lo nessa direção. Se você conseguir repetir esse algoritmo heurístico bastante simples várias vezes, em breve poderá se programar muito ocupado para precisar fazer essa pergunta novamente! Ah, e você provavelmente fará um progresso mais rápido se começar a digitar o código em um teclado o mais rápido e frequentemente possível; e, se você fizer uma pequena pausa de vez em quando, leia algum código de alta qualidade escrito por seus colegas! Nestes dias de desenvolvimento dinâmico de código aberto, você não tem falta de código gratuito e requintado para aprender!

Portanto, recomendo fortemente que você tente minhas três pequenas palavras "até que ponto" e veja até que ponto, em uma boa direção, elas podem levá-lo!

Alguém que diz "Não pode ser feito".

Na minha opinião, é tudo sobre solução de problemas, a ferramenta deve ser muito menos relevante do que realmente fazer o trabalho. Se eu tiver que resolvê-lo usando o MS-Access ou a linguagem assembly, é uma questão de tempo e dinheiro, não de "Não pode ser feito"

Um sinal de alerta é um foco excessivo na maneira acadêmica e "adequada" de fazer as coisas, e não um foco suficiente na realização do trabalho.

Se ele conhece apenas a sintaxe de uma linguagem, mas não conhece os conceitos básicos de algoritmos.

Quando eles fazem muita pontificação, mas produzem muito pouco.

! (inteligente e faz as coisas)

Aqueles que não conhecem princípios como SOLID, DRY, OOP e assim por diante. É importante ter um bom entendimento dos princípios e fundamentos de programação, em vez de conhecer tecnologias específicas. Aqueles com base sólida poderão aprender facilmente novos tópicos e produzirão um código melhor.

Um programador incorporado que não entende as interrupções muito bem ou multitarefa. Também programadores que precisam trabalhar com campos de bits, mas não compreendem operações lógicas e mudança.

Um sinal de reconhecimento imediato é alguém dizendo: "Não entendo por que não funciona. Fiz tudo certo".

Uma coisa que distingue um programador ruim de um programador iniciante é a insistência teimosa em implementar seu sistema favorito em qualquer idioma e API em que estejam trabalhando.

Certa vez, herdei um sistema em que o desenvolvedor anterior reimplementou (em Java) um grande conjunto da API Ashton Tate DBase III + em camadas na parte superior da biblioteca de acesso dbf personalizada. Nenhuma estrutura de coleções Java foi usada.

Isso foi para que ele pudesse escrever um aplicativo Java / swing que parecesse e agisse como um aplicativo DBase III + (ou possivelmente clipper).

Os aplicativos que ele escreveu neste sistema tinham menus de barra de opções e abririam um formulário de janela completa com uma linha de botões na parte inferior quando você navegasse a barra de opções para a opção. Era como uma pequena máquina do tempo nos anos 80.

O homem era claramente um desenvolvedor habilidoso. Ele sabia o suficiente que era capaz de escrever todo esse sistema no prazo desse projeto. Ele também foi capaz de reutilizá-lo em alguns outros sistemas internos.

Mas ele era um péssimo programador, pois seu código usava mal os recursos dos sistemas nos quais trabalhava. Ele estava mais disposto a gastar 3 meses em uma lib personalizada de benefícios duvidosos do que aprender Java / Swing / SQL.