/Desenvolvimento

voltar
/Desenvolvimento

Verdades não tão conhecidas sobre programação

PorThiago Fassina em

Este artigo é a tradução de um excelente texto escrito por David Veksler, no qual ele conta o que sua experiência como programador lhe ensinou. O texto original pode ser encontrado aqui.

E vamos ao que interessa:

  • Um programador gasta cerca de 10% a 20% do seu tempo escrevendo código. Normalmente escreve entre 10 e 12 linhas por dia, que estarão presentes no produto final independentemente do seu nível de perícia ou experiência. Bons programadores gastam cerca de 90% do seu tempo pensando, pesquisando e experimentando maneiras de encontrar a solução ótima. Os programadores ruins gastam quase 90% do tempo debugando e fazendo alterações muitas vezes aleatórias na tentativa de “fazer funcionar”.
  • Um bom programador é dez vezes mais produtivo do que um programador comum. Um excelente programador é entre 20 e 100 vezes mais produtivo do que um convencional. Não é um exagero. Estudos desde os anos 60 têm mostrado isso consistentemente. Um mau programador não é só improdutivo – além de não concluir o trabalho com êxito, gera dores de cabeça e trabalho extra para outras pessoas consertarem.
  • Excelentes programadores gastam pouco do seu tempo escrevendo (código que de fato estará no resultado final). Os programadores que gastam muito do seu tempo escrevendo provavelmente não estão encontrando e utilizando soluções existentes para problemas antigos. Bons programadores são ótimos em reconhecer e em reutilizar padrões comuns e não têm medo de refatorar seu código constantemente, a fim de atingir a solução ótima. Programadores ruins escrevem código que falha em integridade conceitual, não-redundância, hierarquia e padrões, tornando complicada a refatoração, fazendo com que seja mais fácil jogar fora todo o trabalho e recomeçar.
  • Software, como qualquer coisa, obedece às leis da entropia. Contínuas mudanças levam ao desgaste do software e de sua integridade conceitual planejada originalmente. A entropia é inevitável, no entanto, programadores que falham ao estabelecer a integridade conceitual criam sistemas que se desgastam tão rapidamente, que muitas vezes se tornam inúteis e caóticos demais mesmo antes de serem concluídos. Possivelmente, o motivo mais comum para falha em projetos é o rompimento da integridade conceitual devido à entropia descontrolada (o segundo mais comum é a entrega de um produto diferente do que o cliente esperava). A entropia desacelera exponencialmente o desenvolvimento e é o principal motivo para deadlines desesperadoras.
  • Um estudo realizado em 2004 revelou que 51% dos projetos falham ou irão falhar em alguma funcionalidade importante e que 15% simplesmente vão falhar como um todo, o que é um grande avanço desde 1994, quando 31% dos projetos falhavam criticamente.
  • Embora muitos softwares sejam desenvolvidos em equipe, não se trata de uma atividade democrática. Geralmente somente uma pessoa é responsável pelo “design” do sistema e o resto do time o completa com detalhes.
  • Programar é um trabalho pesado. É uma atividade mental intensa. Bons programadores pensam sobre seu trabalho 24/7. Eles escrevem seu código mais importante no chuveiro, sonhando etc., porque o trabalho mais importante é feito longe do teclado. Projetos não são concluídos mais rapidamente gastando mais tempo no escritório ou adicionando pessoas novas ao projeto.

“Um excelente operário pode ser duas ou até três vezes mais produtivo que um operário comum, já um bom programador pode fazer com que seu trabalho seja mais do que 10 mil vezes mais produtivo do que um programador comum” – Bill Gates

Deixe um comentário! 107

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Comentando como Anônimo

    1. muito bem pensado! nas profissões de TI poucos são os que realmente entendem de código e gerenciar não basta! a partir do momento que você se envolve com tal área deve conhecê-la de ponta a ponta. Não é a toa que as falhas são causadas por falta de comunicação ou entendimento entre a equipe

    2. Tbm concordo. Imagina um chefe de hospital que não entenda nada de medicina, na vida real seria absurdo, mas em TI acontece direto. Pessoas chave tomando decisões sem entender da tecnologia, lamentável.

    1. Mas antes do mau programador está o mau Gerente de Projeto, que nunca escreveu uma linha de código e acha que consegue estimar um prazo baseado em métricas ridículas aprendidas em cursinhos !

    2. Acho que vai além…se o mau programador está lá, é porque alguém o colocou lá( no caso, o gerente ou o coordenador) e o apóia…rs…senão já teria sido convidado a se retirar…mas é incrível como alguns gestores fecham os olhos pra certas coisas…

    3. Tem razao. Essas maneiras de metrificar sistemas aprendidas em cursinhos que os GPs adoram sao extremamente amadoras. Mais amadores ainda sao os gerentes que acreditam nelas. Afinal um GP tem que transformar qualquer coisa a sua frente em um numero p/ obter uma porcentagem de conclusao. Ja vi GP perguntar coisas absurdas do tipo: quantos porcento vc ja pensou na solucao X? Querem metrificar ate pensamentos…

  1. Caro Thiago, é impressionante ler isto de um jovem garoto. Estou ná área há 24 anos. Me deixa muito triste ver que muitas empresas não enxergam isto; em especial as grandes que gastam dinheiro sem dar conta. Em 1999, trabalhei em um projeto de 5 milhoes de reais que nao deveria ter custado 500 mil. Ainda continuo vendo este tipo de coisa. Para piorar, alguns estão usando técnicas como ITIL de forma errada, super valorizando o erro e assim aumentando a tolerância. Fiz esta observação em uma loja virtual de uma grande operadora de telefonia móvel. O loja que é simples e já faz mais de 2 anos de manutenção corretiva. Os profissionais da operadora valorizam mais o processo de manutenção do que o produto. O processo deveria ter reflexo no produto, mas não tem. Um processo altamente custoso para um produto ruim. O que faz cada melhoria virar um pesadelo.
    Há muita politica para sustentar este cenário.
    Hoje estou na área acadêmica e vou indicar este artigo aos meus alunos.
    PARABENS!!!

    1. Paulo, todas as empresas valorizam a manutencao. Manutenção tem orcamento fixo, caixinhas no organograma e risco baixo para seus gestores.
      Transformar qualquer melhoria em pesadelo, faz parte da manutençao do status-quo de baixo risco, limitando a creatividade de usuario.
      Com a desculpa de “cuidar da lojinha”, dezenas ou centenas de programadores ruins ganham para atrapalhar o negocio de suas empresas, e sao por ela valorizados.

    2. Bom, sem querer chover no molhado, o Morsello resumiu tudo…a todo um mecanismo para gerar demanda…o mercado de TI infelizmente vive disso…e os bons programadores são obrigados a levar esse bando nas costas, pois quando a coisa dá errada, alguém tem que resolver, e com certeza não será o zé ruela que fez…aliás, não é só o mercado de TI que vive disso…quando ouço um político qualquer dizendo que vai gerar milhões de emprego, fico de cabelo em pé…porque nesse país não se gera emprego, se gera demanda…demanda pra sustentar profissionais incompetentes que se escoram nos bons profissionais…infelizmente é assim…

  2. Parabéns pela matéria. Retrata a realidade de um programador e seus pecados mais comuns. Ilustra bem o cenário que eu me deparei quando eu, então com 16 ou 17 anos, tive a oportunidade de trabalhar em um estágio na área de programação voltada a aplicações desktop e, confesso, sofri muito para entender o meu próprio descontentamento quanto ao resultado prático do meu trabalho. Mas hoje eu consigo entender quais eram os invisíveis obstáculos que me impediam de produzir soluções ao ponto de me sentir útil. Comecei estudando e notei que eles usavam e desenvolviam várias versões de um mesmo framework, inclusive versões mistas que apenas reuniam as últimas soluções para os velhos problemas de sempre, geralmente vindos de recortes de experimentos bem sucedidos anteriormente. Revirei então o código tentando entender o funcionamento do framework que eles desenvolviam e usavam internamente, já que não havia documentação de suas funcionalidades. Fim da história? A deles eu não sei. Eu pedi demissão com menos de um mês, sem saber exatamente porque eu me sentia tão inútil. Mas graças a minha capacidade lógica de reflexão hoje eu consigo perceber o que um bom planejamento e o uso de boas práticas padronizadas podem influenciar no resultado final de um objetivo, principalmente quando envolve desenvolvimento de projetos em longo prazo. Em tempo para uma última nota: Hoje eu tenho 24 anos e a página inicial da empresa onde eu trabalhei ainda está no ar, mas a página inicial ainda permanece a mesma.

  3. Excelente! Há algum tempo venho pregando isto em conversas que tenho com desenvolvedores e em textos que publico, os programadores precisam saber disto o mais cedo possível para chegarem a um nível de excelência legal.

  4. Ótimo texto, mas ninguém nasce sabendo, você leva os tombos, experimenta outras alternativas, cai de novo, levanta, se apóia e só depois você começa a andar.
    Na programação é a mesma coisa. As vezes o mal programador é o cara que se contenta em engatinhar ao voar.

    1. mas o fato de o texto não ser original do Thiago Fassina, não siginifca que não expresse a opinião dele. Ao contrário, ele teve o trabalho de traduzir e publicar o texto exatamente porque segue a mesma linha de pensamento…

    1. Somente a minoria pensa pq a maioria foi “doutrinada” assim. Lembra como eram ou são dadas as aulas de história, química, física…? Decore fórmulas, decore datas, eventos… Não fomos ensinados a pensar.

      Isso se reflete no futuro profissional. A incapacidade de simplesmente pensar! Lógicamente que isso não se aplica a todos mais infelizmente é um fato.

      Outro câncer nosso é a falta de planejamento. Se as especificações do software não são informadas com clareza, como desenvolver? Difícil, não?

      De qualquer forma, foi bom o artigo. De para dar uma boa reflexão.

      vlws

  5. Muinto Bom o Artigo. Parabéns.
    Estou começando na área de programação mas já deu para perceber que programação é 24 por dia sete dias por semana.

  6. Ótimo artigo Thiago ! Também estou começando na programação, estou como tester e aprendendo sobre desenvolvimento (desde a análise até a programação em si) e achei muito válido o texto. Parabéns.

  7. Com certeza o texto é excelente e reflete uma triste realidade.
    Mas devo citar que ser um bom ou mau programador não depende só da pessoa em si.
    É muito fácil dizer que não foi feito um código decente sem antes avaliar o contexto em que o criador estava inserido.
    Realmente existem bons e maus programadores, mas atualmente tenho visto muitos bons programadores criarem códigos pouco otimizados não por incompetência ou má vontade e sim porque existem demandas cada vez maiores e com prazos cada vez mais curtos.
    O cliente só pensa no produto final e o gerente – que talvez não entenda tanto do processo de programação – só pensa no faturamento, combinação perfeita para que um software seja desenvolvido às pressas sem o esmero e tempo necessários para um produto de qualidade.
    []s.

    1. cara, eu descordo desse ponto que “o programador não pode fazer”, isso é desculpa… eu ja trabalhei em empresas com coisa muito apertada, mas sinceramente, eu prezo pelo que eu faco, e eu sempre faco codigo com o minimo de qualidade e otimizacao que eu considero nescessario, discotir com gerente é facil, basta falar com confianca, ele não tem argumentos pra ir contra. se é pra trabalhar numa empresa que não me deixa fazer meu trabalho, eu mudo de empresa.

    2. Ao colocar a palavra MÍNIMO na sua resposta, você já concordou com o cara acima.
      “pouco otimizados” e “mínimo de qualidade” são bem parecidos.

  8. Muito bom o texto. Faço Sistemas de Informação, estou começando agora na programação, espero um dia estar entre os bons programadores.
    Abrass

  9. Concordo com o texto, que por sinal é muito bom, boa parte dos meus sistemas, eu estruturo fora do teclado, geralmente deitado na cama.

  10. Na minha opinião os “maus programadores” estão aí porque as empresas exigem muito e pagam pouco. Querem profissionais prontos a salário de estagiário. O resultado é que os bons não se sujeitam a essas vagas e os que aceitam são os iniciantes que são obrigados a mentir para arrumar emprego, do contrário não tem chance de começar. Ninguém nasce bom programador. Só se aprende com estudo e muito treino, muita prática. No entanto, o que as empresas entendem como “prática” é experiência profissional, onde elas mesmas, as empresas, não permitem que se treine. Querem resultado. Assim cria-se um ciclo. As empresas fingem que pagam e os “maus programadores” fingem que sabem fazer.

    1. Acredito que ao dizer “pagam pouco” estava se referindo a “não criam ambiente para gerar bons programadores”, pois pagar bem ou mau não torna as pessoas melhores, conheço pessoas que passaram a receber melhor e tudo o que fazem é reclamar e querer mais. Esse certamente é um assunto complexo mas acredito que pessoas se tornam melhores a partir do momento que tem o desejo de melhorar pois assim elas mesmo criam um ambiente propicio a isso… ou são demitidas por acharem que estão enrolando… mas a vida é um risco!… apenas devemos assumir o compromisso de assumir riscos que valem apena…

    2. Mas não é uma questão de tornar alguém melhor. Se você passou anos pagando faculdade, pagando cursos, se esforçando para aprender seja treinando seja em suas experiências profissionais, para chegar a ser um “bom programador”, certamente não vai querer receber, em troca de tudo isso, um salário de estagiário. Mas tem uma boa parte das empresas que insiste em se comportar assim, aviltando o funcionário.
      Quanto a existência de pessoas que passaram a receber melhor e tudo que fazem é reclamar, não duvido que existam, mas certamente não é a regra…até porque, com a realidade das últimas décadas, alguém com essas características, ou tem algum pistolão ou vai pra rua rapidinho. Sem a menor dúvida.

  11. Puxa curti muito o tema e agradeço Thiago Fassina por ter traduzido esse texto abriu muito a mente! Aproveitei para ler os comentários também e o assunto ta pegando fogo :D temos realmente que discutir coisas para tirar o melhor proveito e se tornar melhores! Pude tirar muitas coisas proveitosas e que pretendo aplicá-las na faculdade foi dito que 70% de um software não envolve computadores ou seja é pesquisa e entendimento do que deverá ser feito, desde quando comecei a trabalhar na área tenho percebido que não é assim que funciona, mas se as empresas estão exigindo mais trabalho e menos estudo é porque de alguma forma isso da certo! Ou tem dado lucro a elas, talvez seja porque as perdas com o serviço mau feito não tem sido maior que o lucro e como empresas visão lucro… mas infelizmente isso terá repercussão mais para frente pois assim que cliente tiverem opções irão mudar e vai prevalecer a qualidade! Ais será um pouco tarde para essas empresas que não “criam um ambiente” para desenvolver “bons programadores” realmente como já foi dito… ninguém nasce sabendo por isso é necessário ter um ambiente onde o erro seja permitido! Abraços!

  12. Parabéns, ótimo texto.

    Não gasto 90% do tempo pensando, planejando e estudando. Afinal, isso não é uma receita de bolo. Mas, dependendo do projeto, com certeza varia entre 70 e 80 %.

    Mais uma vez, ótimo texto.
    T+

  13. Bons programadores ouvem seus clientes, comentam os códigos, documentam o que fazem, fazem o básico de forma eficaz. Bons programadores desenvolvem o que é pedido sem firulas ou testes de metodologias que não conhecem. Excelente texto!

  14. Apesar de bem escrito e de conter boas ideias, achei o texto utópico. Não são somente gerentes e o “sistema” que não querem ser eficientes, mas as pessoas em geral , incluindo programadores, também não querem. Se houvessem somente programadores produtivos, segundo o próprio número do texto haveria somente 10 % das vagas existentes no mercado. Já pensou sobre isso?

  15. Quando programador, tive a infelicidade de ouvir meu gerente de projetos dizendo que quando um programador está pensando, é porque alguma coisa aconteceu de errado (Modelagem mal definida, caso de uso confuso, coisa do tipo). Hoje sou coordenador de sistemas e não chego a ser perito em nenhuma linguagem, mas ainda programo e sou considerado um ótimo programador de muitas linguagens por uma única característica: Bom Senso, que ainda é mais raro que um bom progamador.

  16. Meus parabéns pela iniciativa Thiago! Excelente artigo é infelizmente é o que realmente acontece em nossa profissão. Existem muitos programadores que não se preocupam com a qualidade e e seguem a filosofia do “Funcionou? Então beleza!” e acaba acontecendo o que o artigo cita “Os programadores ruins gastam quase 90% do tempo debugando e fazendo alterações muitas vezes aleatórias na tentativa de ‘fazer funcionar'”.

  17. Ótimo texto. Parabéns.
    Estou até repassando o link para amigos terem como inspiração.
    Trabalho a 10 anos com programação e já ví de tudo. Já fui um ruim, moderado e hoje diga não por mim, mas pelos resultados e comentários de amigos que veem meu trabalho que sou um bom programador.
    Espero um dia chegar ao nível de excelente.

  18. O grande problema é que mais facil e rapido para um gerente ou empresa fazer um contorno (“Gambiarra”) no codigo antigo, do que parar e planejar uma nova solução mais produtiva.
    Todos os dias vou para minha casa pensando na solução mais agil para o problema que tenho a resolver, sempre buscando alguma inovação, mais isso exige que eu conheça e estude a nova condição, leva tempo e quase sempre não posso ultiliza-la pois vai mais tempo do que tenho para executar, pois o prazo ja foi estipulado pelo meu gerente.

  19. Este artigo é um dos melhores já lidos aqui no Imasters. É extremamente verídico todas as informações e fáceis de deparar-mos no dia-a-dia com tais situações. Por isto acredito que um programador para ser competente, não basta apenas saber programar.

    Obter conhecimento em Análise de Sistemas, banco de dados, UML é sempre muito importante, para não cometer os erros mais comuns nesta área.

    Parabéns pelo Artigo!

  20. Parabéns pelo texto de fácil leitura. O pior é que quase nenhum dos gestores de empresas sabem disso. E por isso pedem prazos impossíveis.

  21. Algumas verdades, mas também algumas bobagens:
    “Embora muitos softwares sejam desenvolvidos em equipe, não se trata de uma atividade democrática. ” Em primeiro lugar, software não tem plural (como a palavra gado). A figura de um ‘arquiteto’ que tudo sabe e tudo vê (e que geralmente pouco escreve código) ficou no passado. Isso não é a realidade dos projetos mais modernos.

    “Contínuas mudanças levam ao desgaste do software e de sua integridade conceitual planejada originalmente.” BDUF é outro conceito que já ficou no passado. O uso de TDD e BDD mantem o software funcionando e íntegro, apesar do refactoring. O próprio texto se contradiz ” Bons programadores (…) não têm medo de refatorar seu código constantemente”.

  22. Um pouco óbvio esse texto nao? Um bom programador é mais produtivo que um mau programador? Serio? Não sabia…

    Cade as fontes primárias? Cade as pesquisas nas quais foram baseadas esses números aí? “Estudos realizados desde os anos 60”. Que estudos?
    Eu sei que programador não é jornalista. Mas também não é exigir demais que ele pelo menos saiba reconhecer um texto bem escrito de um mediocre. Afinal, creio eu pelo menos, todos aqui terminaram o ensino médio.
    Esse texto e essa maré de aplausos que ele provocou só mostra uma faceta triste dos profissionais da computação no brasil: São semi-analfabetos.

  23. Utopia demais!
    Levanta a mão ai o programador que fica 24/7 “programando”.
    Levanta a mão ai o programador que faz uma tela de cadastro com 50 campos para cada um de três tipos de registro com 10 ou 12 linhas por dia. Pode até ser, mas vai demorar um bocado nesta tela.
    Sei que nossa área está repleta de maus profissionais mas, pra mim, este texto é uma tentativa frustada de um talvez bom profissional se auto-vangloriar.

  24. Ficou muito bom. Dá para ter uma boa idéia. Um dia espero chegar no nível de excelência, vou esforçar para isso. Estudar, aprender e treinar.

  25. Pessoal, creio que o maior problema está no meio termo. Excelente programadores que dificultam para médios e bons programadores. Se utilizam de uma lógica muitas vezes que só para entender demoraria mais do que para codificar. Creio que no mundo da implementação, quanto mais simples melhor. São os programadores que querem exclusividade nos seus códigos.

  26. Não sou programador, sou apenas um entusiasta web, por tanto um observador. Vou aproveitar uns trechos de um comentário que fiz no “itweb”:

    Vocês são um bando de doidos sadomasoquistas, agora acreditem nisto, precisamos desses doidos (rs). Viva os programadores, huhaa!

    Posso afirmar isso: Programadores são os profetas de uma nova geração tecnológica!
    Essa frase pode ser usada infinitamente pra todas as gerações que virão e sempre vai ser atual.

    Ótimo artigo Thiago

  27. A maioria dos programadores começa errando e sem padrões, esta é a verdade! Por mais que muitos clamem pela realeza de ótimos programadores a grande verdade é que quase todos começam com os famosos Ctrl+C e Ctrl+V e muitas pesquisas a códigos prontos, e não venha dizer que com você não foi assim, pois caso contrário, você é um dos grandes fenômenos criadores de nossa era da programação. Não é sarcasmo, é fato, por isso acredito que ao invés de perdermos tempo falando sobre maus ou bons profissionais, que existem em todas as áreas, deveríamos nos focar na regulamentação de nossa profissão, que é ridículo ainda não ter sido aprovada, pois sejam bons ou maus profissionais, todos nós estamos sujeitos ao mesmo problema, o não reconhecimento como reais profissionais, seja você um expert com ótimo salário ou um iniciante ganhando uns trocados, todos nós no final das contas somos tidos como profissionais sem estudo que fazem o que querem, porque dominam algo que a empresa ou órgão precisa, e que não merecem o que ganham, pois no final das contas seja muito ou pouco os patrões sempre acham que pagam mais do que merecemos.
    Pensem nisso, programar por que gosta ou por amor é ótimo, mas não devemos nos esquecer que é o meio de sustentabilidade e carreira escolhido por muitos ou a fonte extra de renda para alguns, sendo um caso ou outro, no final das contas o que interessa é que sem o devido reconhecimento para a a classe sempre seremos os quase profissionais “muito bem pagos” que não merecem o que ganham nem o real reconhecimento como profissionais.

  28. Lendo o texto me lembrei agora de um documentário que assisti sobre sobre o Bushido que seria o código de conduta Samurai, dizia como um Samurai deveria ser, agir e pensar…
    Sério, me esforço, mas não consigo imaginar os grandes inventores seguindo manuais de conduta, ta certo que ajuda mas não deve ser o único caminho e nem incentivado a tal.
    Só espero que nenhum programador esteja pensando em executar o Seppuku ao final do texto hehehe.

  29. Acho que ainda não conheci então esses ótimos programadores. Só conheço os que pensam, pensam, pensam. Dizem que estão pensando na melhor solução, e pensam e pensam e acham a solução melhor que anterior, e pensam e pensam e dá merda no fim igual :D.

  30. Parabéns pelo artigo, também acho que o mercado trata os profissionais de informática com muito descaso, visto que os salários sempre estão muito aquém do que nós investimos, e muitas vezes com um retorno duvidoso.
    Basta compararmos os profissionais que trabalham com JAVA, .NET e tantos outros.
    Analisem o quanto que temos que estudar e continuar estudando para termos condições de atender o mercado e muitas vezes somos tratados como “MERETRIZES” (desculpe o termo), ou seja tentam pagar o menos possivel e exigem que saibamos quase tudo.
    Espero que um dia esse quadro mude, pois conheço vários profissionais de alta qualidade, que acabaram saindo da area.
    Um grande abraço a todos

  31. Cara!
    O mau programador não existe numa emprêsa que se preze; é
    demitido.
    10 a 12 linhas de códigos, quando as empresas querem para ontem;
    Isso não existe.
    Bons programadores dependem de uma ótima análise.

  32. Vale lembrar que quando falamos de um produto bem construido, este é fruto de uma equipe de excelencia, composta de analistas, programadores e gerentes competentes. E não adianta nada ter todas as pessoas competentes de a equipe não for unida e com o foco no mesmo objetivo.

  33. “Normalmente escreve entre 10 e 12 linhas por dia, que estarão presentes no produto final independentemente do seu nível de perícia ou experiência”

    se isso acontecer, filho, vc é mandado embora.
    10 a 12 linhas por dia…
    é claro, temos que pensar, mas, isso, ja é a mais.

    e faço minhas as palavras do Tulio.

    imastes ta virando um google translate.

    e não é apenas um ou outro que faz tradução aqui, tem aos montes.

  34. Ótimo post….Realmente condiz com a esses 5 anos de experiência com desenvolvimento. Muito das coisas relatados aqui eu re-vi nas minhas experiências.

  35. Um verdadeiro bombardeio de opiniões, e cada uma coberta de razão e vivências, a tercerização, o neo-liberalismo, as comissões (digo propinas), as métricas, a falta de escrúpulos de administradores, a péssima qualidade de programadores/analistas, as FÁBRICAS DE SOFTWARE, tudo isso aliado a empresas corruptas, viabiliza um mercado caótico para tecnicos e um verdadeiro oasis para a incompetencia, trazendo incertezas e desanimo para quem realmente gosta e conhece do código.
    Um LIXO e Isso já está previsto nos orçamentos daas empresas, infelismente.
    Deveríamos repassar o link desse forum a nossos gerentes e patrões, para que eles vejam que os erros em TI, é em grande parte culpa deles.

  36. o cara só traduziu o texto e tem gente parabenizando ele, haha… e bons programadores escrevem 10 a 12 linhas de código por dia?? hahahha… bastante imbecil isso…

  37. O bom programador é aquele que sempre se questiona sobre o seu proprio codigo(como posso melhora-lo?),… é bem verdade que uma boa documentação e um levantamento de requisitos claros são fundamentais para reverter possiveis erros de processo/redundancia no futuro.
    Quem vos fala é um ex fatecando. 2 anos de experiencia em pegar muitos erros de codigo.

  38. Eu já fui um mal programador e sofria muito com isso, ainda tenho muita coisa para aprender, mas estou mais prudente hoje e procuro filosofar mais com meu código. E realmente um bom programador escreve menos linhas de código do que um mal programador, e também conhece sobre ferramentas e frameworks que o livra de trabalho extra.

  39. programador é profissão de homem, pq nós pensamos racionalmente melhor que as mulheres, já elas, pensam melhor emocionalmente(publicidade,rh,psicologia…)
    PROGRAMADOR É COISA DE MACHO!

  40. Conrcordo com tudo o que disseram aí e com muito dos comentários. Aproveito e já lanço a teoria de que o programador tem data de validade; a partir do 6º ano trabalhando como programador, o cérebro do cara começa a cansar, principalmente no que compete a aprender coisas novas.

    Estou entrando no meu sexto ano trabalhando como programador, e acredito que estou começando a ficar cansado..quero trabalhar programando só mais um ano..hehehe..

    1. Estou há 13 anos, e ainda não cansei… Na verdade, cada dia fico mais triste em saber que tem tanta coisa nova, e posso fazer pouco com elas, devido aos projetos já estarem rodando em tecnologias ultrapassadas.
      Mesmo assim tentando sempre deixar atualizadas.
      Mas concordo que muitos vão cansando mesmo, e acostumando a rotina..
      A validade pode ser maior ou menor, depende o nívels dos desafios que se apresentam.

      Manda bala, pois você ainda é novo!

  41. Mais vale um mau programador na mão do que um bom programador voando, em alusão ao conhecido jargão do “passarinho”.

    Normalmente, quando o cliente me pede um programa com urgência, eu apelo para tudo quanto é tipo de gambiarra. Copiar, colar, testar, emendar parte de um código com outro, isso me fascina. Uso códigos dos outros como uma espécie de laboratório, até criar o meu própio código. Ou se quiserem, uma espécie de padaria, faço tudo quanto tipo de mistura e olha… sai cada docinho gostoso!!!

    Então, rapaziada, nesse mundo tresloucado, onde o sujeito têm que sair correndo atrás da grana, vale tudo. Porque se eu ficar perdendo tempo em programar linha por linha, levar um ano queimando pestana em cima de um projeto que pode acabar dando em nada, não perco somente meu precioso tempo, mas corro o risco de perder meu cliente e, por conseguinte, minha graninha. Concordo com todos os termos do artigo acima postado, desde que o sujeito tenha muita grana para bancar a si mesmo. Porque senão, sejam como eu, um programador ruim, mas feliz!!!!

  42. Equilíbrio, meio termo e, principalmente, BOM SENSO com tendências à qualidade acho que é o ideal.

    Nem todos os prazos, momentos e códigos são convidativos a se fazer artesanalmente cada linhazinha do que você escreve.

    São inúmeras variáveis que são colocadas em jogo. Concordo, porém, que a gerentada aí estipula parâmetros que são incompatíveis com a natureza do trabalho de programação. É lamentável que uma coisa dessas aconteça.

    No mais minha gente, não tem quem está certo ou errado aqui nesse mar de opiniões: o BOM SENSO prevalece. E isso não se ensina em lugar nenhum.

  43. Falou tudo, na minha turma no curso de Informatica, digo q tinha 4 ou 5 no maximo entre uns 25 q realmente ‘Programavao’, e bem por sinal…

    Da para vc realmente perceber quando um cara leva jeito para ‘a coisa’ rsrs

    Quando se reunia com um ou mais q nao manjavam muito de programação, era um nivel de conversa totalmente diferente sobre o assunto, e quando eu se reunia com outros q manjavam ai as conversas ja avançavam mais e era mais prozeroso :)

  44. Infelizmente hoje em dia os programadores comuns estão tomando os lugares dos programadores bons, todo mundo quer fazer ciência da computação sem realmente amar o que faz.

  45. Quanto exagero e imbecilidade neste texto! Qual programador consegue sobreviver escrevendo tão poucas linhas de código quanto está escrito no começo do texto? Depois que inventarem a inteligência artificial é que isto será possível. Hoje em dia, um programador tem que identificar bons padrões e automatizar a geração de código, não importa quantas linhas devam ser escritas pela ferramenta de automatização. Ainda assim, o resto ele terá que ralar para completar. No ritmo que fala o texto, o programador que não tiver uma ferramenta que faça o trabalho duro por ele, vai consumir o tempo inteiro do projeto para escrever um programa do tamanho de um “Olá, Mundo!”.

  46. É, foi com programadores que escrevem 12 linhas por dia que os milhões de linhas de programação que fazem a plataforma Java e .NET foram escritas. Quem lê uma idiotice destas e ainda aprova tá delirando.

  47. Pessoal, preciso de uma ajuda:

    Atualmente, trabalho em uma função a qual não gosto (Não é na área de T.I). Fiz tecnólogo em análise e desenvolvimento de sistemas, mas infelizmente aprendi mais o básico, o que não é suficiente para o mercado de trabalho. Terminei os estudos e estudei java intensamente por uns 5 meses, mas tbm não era o suficiente e acabei desanimando um pouco. Sempre gostei da linguagem C, mas na facul era tratada apenas como “linguagem de introdução”. Atualmente estou cursando eletroeletrônica, e irei aprender a programar microcontroladores em linguagem C e Ladder, no qual é o que pretendo seguir. Gostaria de algumas dicas para conseguir me posicionar no mercado de trabalho, participar de projetos open source… Obrigado

leia mais