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

57

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

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

Tom Wijsman
fonte
3
Porque essa pessoa não aceita respostas em uma página da Web relacionada à programação. Brincando :-)
Daniel
11
@EvanKroske: Não, isso não está certo .... O Wiki da Comunidade existe para permitir a edição colaborativa de postagens. Veja também: Our Meta - Tag: community-wiki
Tamara Wijsman
Em muitas perguntas, é impossível aceitar uma única resposta. Veja também: Our Meta - Search: accept
Tamara Wijsman
Nem toda pergunta recebe uma resposta que realmente resolva o problema.
Loren Pechtel 17/10/10

Respostas:

134

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.

PSU_Kardi
fonte
4
Concordo - você precisa ter um ciclo de feedback, sempre aprendendo com seus erros.
Marcel Lamothe
11
@PSU bem dito. Como qualquer ofício, os programadores são comerciantes e não são perfeitos, sempre aprendendo, mas se você não aprender com os erros, não estará melhorando em seu ofício.
Chris
2
Essa é uma definição muito ampla; não é limitado a programadores. Aplica-se a cientistas, cozinheiros, esportistas, tradutores, zeladores, fotógrafos e realmente qualquer profissão.
RegDwight
13
Todo mundo é idiota pelo menos uma vez por semana.
MIA
@ RegDwight: e seu ponto era ...?
SamB 16/09
125

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

Graviton
fonte
16
Se eu pudesse votar em 100x, eu faria. Um pouco de humildade e vontade de aprender compensa muito a longo prazo.
William Pietri
11
+1 para Ngu e William também. Este é o critério mais típico de um "programador" ruim.
fabrik
O que acontece quando você sabe que não conhece MUITO e, por mais que tente, nunca saberá a maior parte disso?
Steven Evers
@snOrfus, você localizar um mentor para ensinar-lhe ...
75

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.
Marcel Lamothe
fonte
3
* e codifica essa tecnologia há algum tempo
Joe Phillips
5
Isso se aplicaria a quase todos os programadores que já fizeram algum desenvolvimento web com estruturas como Java / Spring ou Ruby on Rails. Essas estruturas estão cheias de magia negra que programadores normais geralmente não se incomodam em entender.
missingfaktor
3
@Missing Faktor - e, portanto, não seria tão impreciso dizer que a maioria dos programadores que fazem isso, não são grandes programadores :)
seanmonstar
14
Por outro lado, não é realista supor que os programadores devem entender completamente o funcionamento interno da estrutura, da máquina virtual ou do que quer que estejam construindo o código. (Ou, de fato, detalhes de todas as camadas de abstração abaixo, até que o bare metal seja alcançado.) Você pode ser um programador perfeitamente bom e produtivo, mesmo que saiba apenas as partes mais relevantes.
Jonik
4
@ Missing Faktor: eles podem não entender os elementos internos das bibliotecas e estruturas que usam com precisão, mas devem pelo menos saber para que servem cada coisa em seu código: "snark the frobber" ", porque a documentação diz que isso é necessário para preservar a integridade do continuum espaço-tempo ", etc.
SamB
45

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.

JohnFx
fonte
Ah sim, eu trabalhei com ele. Pretérito, felizmente.
quer
11
Alguns nem sequer são capazes de formar perguntas decentes, pedindo-lhe para "apenas corrigi-lo"
deltreme
21

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

EpsilonVector
fonte
11
Eu acho que pode haver alguns iniciantes com potencial para serem bons programadores - que têm problemas com isso.
JD Isaacks # 15/13
2
Os iniciantes são bons se você estiver procurando por um programador júnior que pretenda moldar e transformar em um bom. Mas esse problema é tão trivial que não deve levar ninguém com experiência a escrever.
Matt DiTrolio
8
Eu diria que não deve demorar muito tempo para alguém que tenha concluído com êxito um curso de programação de nível básico para resolver isso.
EpsilonVector
4
Se um iniciante não pode resolver o FizzBuzz, ele não deve estar se candidatando a trabalhos de programação. Se você afirma poder programar (por exemplo, solicitando um trabalho de programação), deve resolver o FizzBuzz.
Chinmay Kanchi
11
A pergunta sobre o Stackoverflow no FizzBuzz vale a pena dar uma olhada. Confira a solução python que não usa divisão ou módulo. stackoverflow.com/questions/437/…
Gordon
21

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

faltando
fonte
6
... e por boas razões, devo acrescentar.
missingfaktor
18

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

danivovich
fonte
11
Eu concordo - essas pessoas podem ser extremamente prejudiciais para sua equipe.
Marcel Lamothe
44
Huh ... Eu removi 500 linhas de código redundante ontem e não introduzi bugs. Métricas LOC consideradas prejudiciais?
Piskvor
5
A maioria das métricas é péssima e as métricas LOC geralmente são mais inúteis. O ponto aqui é que um programador ruim é alguém que cria mais trabalho para a equipe do que ele / ela completa.
Danivovich
5
As métricas do LOC não são inúteis. Eles são prejudiciais. Além disso, a contagem de LOC é muito difícil na maioria dos idiomas modernos. Mas, a métrica não é o ponto aqui. É só dizer | Trabalhar para criar | - | Trabalho errado | - | trabalhar para consertar | ... ou seja, se você levou 10 horas, das quais você gastou 6 horas trabalhando em algo que finalmente precisava ser consertado e levou mais 6 horas para fazer isso, então você tem -2 horas. O tempo é realmente o que você está tentando obter de qualquer maneira.
MIA
11
Métricas LOC são uma ótima maneira de medir quantos lugares erros tem que esconder.
Samb
18

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

Billy ONeal
fonte
15

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

JeffO
fonte
Mas pode haver discordâncias de especialistas sobre o que é "melhor".
darenw
@ DarenW - Eu não diria que alguém é um péssimo programador, porque tomou partido de um tópico controverso, mas quando tem uma escolha definitiva em sua própria mente.
JeffO 9/10/10
15

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.

Daenyth
fonte
5
E se eles não encontrarem algo errado, e isso os preocupa?
SamB 16/09
11
Ou pior, eles não conseguem encontrar nada errado e tentam consertar.
Toon Krijthe
15

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

Reigel
fonte
14

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

BezantSoft
fonte
RE "Aqueles que pensam que são indispensáveis ​​geralmente são" lembram-me en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
DaveDev
10

Incapaz de se adaptar às próximas tecnologias

Gopi
fonte
10

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.

Chinmay Kanchi
fonte
11
E o programador é realmente ruim quando ele não consegue ler um código :-) bem escrito
Maniero
4
Isso não seria quase todo mundo? Quero dizer, o código nem sempre é mais difícil de ler e / ou manter do que deveria ser?
SamB 16/09
Não. É sempre mais fácil escrever código do que ler. Mas tive que manter um código muito bem escrito que reduzisse essa dor o máximo possível.
precisa saber é o seguinte
10

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

stevenvh
fonte
Bem, se ele está escrevendo em Unlambda, ninguém deve ser capaz de lê-lo.
SamB 21/09
Além disso, quando um programador leva muito pouco tempo para fazer algo inicialmente e, em seguida, muito tempo para fazer alguma personalização nisso. Eu sempre vi isso acontecer porque o programador geralmente copia o código das pastas (é por isso que é rápido no começo), mas leva muito tempo porque é difícil (mesmo para bons programadores) alterá-lo a partir daí por causa da ausência da intenção para escrever código personalizável no início.
Sandeepan Nath 01/01
7

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

talonx
fonte
7

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.
tia
fonte
8
Não me lembro exatamente como implementei as coisas que programei na semana passada. Isso é incomum? Fiquei com a impressão de que trabalhar com memória humana finita era apenas um dos desafios da programação. Daí a importância de estruturar e documentar o código para que eu não precise me lembrar de detalhes.
James
@ James Por favor, desculpe meu inglês;). Quero dizer que se um programador voltar a olhar seu código alguns dias depois e não tiver nenhuma pista, isso é um mau sinal. Também não me lembro como e o que exatamente fiz alguns dias atrás, mas tenho certeza de que não preciso coçar a cabeça ao olhar para o meu próprio código e dizer 'o que eu estava pensando?'
tia
@ James: Exatamente, ele deve documentar seu código para que não importe que ele se esqueça de como a metade funciona
#
4

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.

Dean Higginbotham
fonte
4

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.

Bobby Tables
fonte
3

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

user2528
fonte
3

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

DaveDev
fonte
3

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!

John Tobler
fonte
2

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.

Dan Williams
fonte
2
E quando ele diz por que isso pode ser feito?
Maniero
11
Então, que tal resolver um problema de parada? Isso pode ser feito?
usar o seguinte comando
2
É ruim descartar algo como impossível se não for e vice-versa.
Randall Schulz
2
@ Randall Schulz: Até onde eu sei pelo craigslist, um programador de rock é alguém que lida com todos os níveis de desenvolvimento (banco de dados, experiência do usuário, implantação, sysadmin e suporte ao usuário) em uma agência de publicidade por significativamente menos do que o salário normal para uma dessas coisas. Eles os chamam de estrelas do rock, porque após 60 horas por semana disso, sua dieta é semelhante a alguém que viaja em uma van econômica e tem que penhorar seus violões por comida.
Dan Monego
11
Sim, fiz uma generalização abrangente :), mas ... era para fazer um ponto. "Minha opinião profissional é que isso não deve ser feito" é melhor. Ainda melhor "Que tal resolver o mesmo problema de uma maneira diferente". Meu argumento é que um bom programador deve ter foco na solução. "Não pode ser feito", sem oferecer opções, é muito frustrante para o cliente.
Dan Williams
2

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

Chankey Pathak
fonte
2

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

Gratzy
fonte
2

! (inteligente e faz as coisas)

Nick Pierpoint
fonte
== estúpido ou incapaz de fazer qualquer coisa ;-).
Toon Krijthe
2

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.

Giorgi
fonte
2

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.

tcrosley
fonte
2

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

Robert Rossney
fonte
Seguido de perto por "Não entendo por que isso funciona, não está certo".
Randall Schulz
Sim, é o computador que é :) estúpido
Dan Williams
2

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.

sal
fonte