ti-enxame.com

Quando alguém seria considerado um mau programador?

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

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

57
Tamara Wijsman

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.

134
ist_lion

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

125
Graviton

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 eles fazem essas coisas (é apenas "Magia"). Ótimo post de Eric Lippert aqui .

Do artigo:

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

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.

45
JohnFx

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

21
EpsilonVector

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 ...

21
missingfaktor

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

18
danivovich

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

18
Billy ONeal

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

15
JeffO

Pessoalmente, acho que qualquer programador que possa ver seu próprio código que escreveu há um tempo atrás 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.

15
Daenyth

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

15
Reigel

Quando eu era líder de equipe em uma loja pequena, havia várias pessoas que eu precisava designar novamente (nem eu nem meu supervisor direto possuímos capacidade de rescisão sem uma tonelada de Fita vermelha e uma pilha de documentação.) ou não ter renovação de contrato no final do contrato atual. Alguns dos tipos enumerados também funcionavam para outros líderes de equipe, e eles adotavam 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, a nova ferramenta ou o que estiver 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 o paradigma de tecnologia ou codificação usado 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 du jour " e vê toda nova estrutura, linguagem, metodologia ou qualquer outra novidade. quente como o
  4. O "grande cérebro"
    Este '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 não adequadas para o problema em questão. Por exemplo, Apresentando LISP ou Forth em um ambiente de mainframe.
  5. LOC uma. Sandbagger
    Este 'programador' usa ofuscação e orientação incorreta para aumentar a uma. 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 domínio de conhecimento para resolver os problemas em questão, mas como "sabe" tudo sobre ele. De fato, se eles fossem atropelados por um ônibus, toda a organização desmoronaria. { 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 serem seguidos sem um IDE implementado sintaticamente. por exemplo IndexI1O0, Index1I0O, etc.
  8. Estagiário de verão - especificamente subtipo Walking Disaster
    Minha antiga loja costumava contratar vários estagiários no final do ensino médio ou superior. 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 colírio para os olhos, mas a aplicação foi incompleto. 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 constatando que o pedido dele era quase nada além de colírio para os olhos quando voltei à minha loja, voltei ao departamento, peguei Norton e cancelei a exclusão dos arquivos que ele havia excluído, tentando encontre alguma lógica adicional, mesmo que incompleta.
    Eu achei, não lógica ruim, mas comportamento ruim. 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. Ele foi não pago pelas últimas duas semanas.

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

/ s/BezantSoft

14
BezantSoft

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.

10
Chinmay Kanchi

Incapaz de se adaptar às próximas tecnologias

10
Gopi

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

10
stevenvh

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.
7
tia

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".

7
talonx

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.

4
Bobby Tables

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.

4
Dean Higginbotham

Ser mostrado de maneira reprecisa a maneira direita de fazê-lo e repetidamente apenas fazê-lo da maneira mais fácil.

3
DaveDev

Silencioso, obviamente, quando um programador escreve MUITO código. Funções muito grandes, talvez copiem/colem 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 é.

3
user2528

Estou movendo minha resposta para aqui a partir 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.

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

Portanto, minha resposta para sua pergunta é sugerir que você a reformule e se pergunte: "Até que ponto sou um péssimo programador?" Ou, melhor ainda, perguntar na 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 encontrar com uma programação muito ocupada 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 um 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!

Então, eu 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!

3
John Tobler

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

2
Giorgi

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 das estruturas 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 leve e abririam um formulário de janela inteira com uma linha de botões na parte inferior quando você navegasse a barra leve até 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 conseguiu 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 três meses em uma lib personalizada de benefícios duvidosos do que aprender Java/Swing/SQL.

2
sal

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 tenho que resolvê-lo usando a linguagem MS-Access ou Assembly, é uma questão de tempo e dinheiro, não de "Não pode ser feito"

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

2
Dan Williams

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

2
Chankey Pathak

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

2
Gratzy

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

2
tcrosley

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

2
Robert Rossney

! (inteligente e faz as coisas)

2
Nick Pierpoint

Hoje, muitos programadores acreditam que essa complexidade é melhor gerenciada usando apenas um pequeno conjunto de técnicas bem conhecidas em seus programas. Eles criaram regras estritas sobre a forma que os programas devem ter, e os mais zelosos denunciam aqueles que quebram essas regras como maus programadores.

1
Pir Abdul

Um programador que apenas copia e cola o código de outros lugares e não entende como o código realmente funciona é conhecido como um programador ruim! Normalmente, vejo isso com javascript.

1
Pir Abdul

Eu acho que a única maneira de um programador ser ruim em programação é se ele parar de ouvir o que as outras pessoas têm a dizer.

Programação é sobre informação. É preciso manter os ouvidos e os olhos bem abertos.

Um programador só pode melhorar batendo nos livros e trabalhando duro. Mas você também deve se concentrar em aprender coisas novas, e não aprender o mesmo repetidamente (procure novas experiências em seu campo/setor).

Boa sorte.

0
Pablo