PplWare Mobile

Os erros mais comuns do programador

Marisa Pinto

Editora no Pplware e psicóloga de profissão. Desde cedo que a tecnologia é uma paixão, interessando-se em particular com o impacto que esta tem na nossa vida e nos comportamentos que as pessoas adotam nas redes sociais.

Destaques PPLWARE

Deixe um comentário

60 Comentários em "Os erros mais comuns do programador"

avatar
  Subscreva  
Notify of
José
Visitante
José
Excelente artigo, embora há certas afirmações que não concorde. Por exemplo, o programador deve conhecer todo o código – de momento trabalho numa solução que tem 500 e tal projectos e é impossível haver alguém que o conheça de ponta a ponta. Um grande problema, que pelo menos vi nas empresas portuguesas por onde passei, é que a maioria dos gestores de projecto só chegou a esse lugar por não saber/querer programar, e muitos fazem o papel de comercial. Não estão a par das tecnologias e metodologias. Ouvem falar de uma metodologia que está na moda e querem aplicá-la sem… Read more »
Hugo
Visitante

Excelente artigo.

Muito interessante mesmo e aplicável em qualquer altura.

Redin
Visitante
Redin

A @Codacy dá uma ajuda.

Joao Maria Sesifredo Pimentel
Visitante
Joao Maria Sesifredo Pimentel

Muito interessante, gostei bastante .

Miguel Pinto
Visitante
Miguel Pinto

Excelente artigo! Os vários tópicos descritos são o dia a dia dos programadores :). O importante é ter a humildade de reconhecer os erros e perceber o contexto onde estamos inseridos de forma a contribuirmos de forma positiva para o projecto. Sempre em busca da solução e não de quem originou o problema, visto que muitas vezes vêm de vários factores.

José Simões
Visitante
José Simões
Só uma sugestão Digitalizem e guardem esses desenhos juntamente o código. Mais: espero que os teóricos da gestão de projectos (pessoas em relação às quais eu tenho alguma desconfiança 😉 ) comecem a pensar como gerir essa parte. Isto é, avançar na direcção de metodologias em que os programas de gestão de versões de código também incluam documentos diversos, como os contratos com os clientes, comunicações entre os diversos intervenientes, os tais desenhos, etc. Tenho feito isso colocando sempre a data (e a hora!) em todos os papeis e mantendo isso arquivado em separadores, primeiro em gavetas, depois dentro de… Read more »
Ricardo Moura
Visitante
Ricardo Moura
“Pode ter diferentes responsabilidades: sys. admin., tester, designer de interfaces, etc.” Fez-me lembrar uma empresa que perdeu o foco naquilo que sabia fazer bem, para se meter no mundo do software, lembrou-se que podia “fazer umas coisas” e até tentar vendê-las. Criou um departamento com duas pessoas, uma para gerir todo o projecto (waterfall) e outra para programar. O Jira foi substituído pelo Google Docs (a parte equivalente do Excel), o Eclipse pelo Notepad++, o SVN pelo Google Drive e o TDT por.. nada, não havia testes. Concluindo, Em empresas a sério, trabalha-se a sério (até existem technical writers, para… Read more »
Luís Soares
Visitante
Olá Ricardo, Obrigado pelo comentário. Respeito a sua opinião. Eis o que me leva a crer: 0. Não deve ter lido a palavra “pode” 1. É anti-agile 2. Não deve considerar que há diferentes metodologias para diferentes ambientes. Não há uma super metodologia infalível. 3. Talvez até ache que jira = gestão e gestão só com jira 4. Considera que uma pessoa só pode fazer uma coisa, como numa linha de montagem. Ver filme Modern Times 5. Só vê uma forma de fazer as coisas – by the book. Um consultor tem de se saber adaptar. 6. Encaixa as pessoas… Read more »
Luís Soares
Visitante
bin
Visitante

Ricardo, alguns de nós querem ser engenheiros e não apenas gurus de uma linguagem ou framework. E mais digo que as empresas a sério são os engenheiros que as fazem.

Gonçalo
Visitante
Gonçalo

O pior erro do programador é aceitar, em muitos casos, trabalhar por pouco dinheiro 🙂

Ana Rito
Visitante

O artigo está muito bom! Gostei muito de ler.

Kitamura
Visitante
Kitamura

Excelente artigo, continuem assim. Ultimamente o PPLWare parece mais um site de notícias sobre smartphones que outra coisa, mas é bom saber que ainda fazem artigos assim =).

F. Rios
Visitante
F. Rios

Muito Bom, ri-me bastante, então aquela expressão das marteladas, é “de génio”, pura realidade. =)

Miguel Marnoto
Visitante
Excelente conteúdo, é sempre benéfico reconhecer ou relembrar alguns dos factores que complicam o que por si só já é complicado. Gostaria de contribuir com dois erros que muitos programadores cometem (eu inclusive) e que não estão directamente ligados ao conteúdo do artigo mas que, na minha opinião, têm bastante importância para o assunto. Que são: o trabalhar pela noite dentro e a falta de exercício. Trabalhar pela noite dentro pode parecer mais produtivo, porque há menos distracções e não há hora definida para acabar o dia de trabalho, mas o cérebro não funciona da mesma maneira, o cansaço aumenta… Read more »
Luís Soares
Visitante

Obrigado Miguel.
Concordo 100%! Poderia ter posto isso na secção “O programador não é um computador” 🙂 São duas coisas essenciais, que as pessoas desvalorizam.

Bond
Visitante

Muito bom. É destes artigos que fazem o verdadeiro Pplware. É pena serem cada vez menos…

Pedro
Visitante
Pedro

Discordo no Pair programming.

Existem tantos estudos a dizer que é eficiente como tantos outros a dizer que é uma perca de tempo.

Sim ganhas mais segurança e certezas no código, mas tirando em questões de aprendizagem não faz muito sentido.
Pagar a 2 pessoas para fazer o trabalho de 1? Não diria que é muito lucrativo.

Num mundo perfeito talvez fosse engraçado.

Mas com boas práticas, testes, testes, mais testes e algum code review consegues atingir os mesmos resultados.

Tiago
Visitante
Tiago

Tenho poucos anos de programação mas pair programming é algo que nunca gostei..
Estamos os dois sentados e só um faz, o outro ou se encosta ou fala demasiado.. Acho que retrai o desenvolvimento da pessoa que não está a programar

Luís Soares
Visitante

Há que usá-lo com moderação; saber quando e como usá-lo.
Não defendo que se deva usar *sempre*, mas há situações em que rende. Exemplos:
– Novo produto
– Nova funcionalidade
– Ramp up de alguém
– Ramp down de alguém

Tiago
Visitante
Tiago

Se calhar é mais por aí

Eskiso
Visitante

“Isso? Isso é num instante…”
5 horas depois: “Pá..isto tá complicado”

Roberto Brandini
Visitante
Roberto Brandini

Muito bom o seu post, concordo com todos os pontos.

MM
Visitante

Um programador não tem de ser designer, nem deve, tal como um designer não tem que ser programador.
Cada um tem de saber o seu lado, um programador fazer mockups não me parece boa prática – fazer um esboço para ajudar o designer tudo bem, mas ser 2 e 1 acho que só é perda de tempo porque está a dispersar-se em duas frentes distintas.

Luís Soares
Visitante
se for um programador de um driver de software ou exclusivamente de backend, concordo. Agora, se estamos a falar de frontend, só pode ser positivo que o programador saiba um pouco de UX. afinal de contas, é para os utilizadores que ele trabalha. Não disse que tenha de ser especialista: daí só ter falado em mockups rápidos em papel e não em ferramentas profissionais de prototipagem. Fazer apenas uma coisa e recusar-se a saber de outras que lhe estão diretamente ligadas dá origem ao pensamento “linha de montagem” que vigora em muitas organizações. Por outro lado, UX não é trabalho… Read more »
MM
Visitante
Sim, concordo. Daí ter dito que fazer um programador saber mockups rápidos ajuda até que a linguagem entre o designer e o programador seja mais facilmente entendida por ambos. Sim, um programador de frontend trabalha para o utilizador directamente, para geralmente quem tem a obrigação de saber como é que os UX se devem construir em termos de passar a mensagem e de serem funcionais (de ser claro, dos botões existirem ou estarem no local certo, etc.,), faz parte do estudo do designer. Mas pronto, também há os erros básicos dos designers quando constroem um mockup, p.ex., meter o design… Read more »
MM
Visitante

De qualquer maneira, este assunto de relações entre designer, programador, ambiente de interacção, funcionalidades, UX e UI correctos e funcionais ou não, já é coisa para um artigo diferente 🙂

João Dias
Visitante
João Dias
E aí entro eu, que sou UX Designer de profissão 🙂 A User Experience não é competência apenas do designer (friso o apenas), é de todos num projecto. A preocupação com a experiência tem que estar em todos os vectores de uma organização. É isso que dá a qualidade final que toda a gente inveja, mas nem toda a gente consegue. Porque é por isso que é tão difícil implementar UX Design nas organizações. Porque nem toda a gente – dos gestores aos programadores e designers inclusos – se quer preocupar com o resultado final. Ou descuram a importância, ou… Read more »
Luís Soares
Visitante

Olá João,

Concordo a 100% com a tua resposta. Sendo programador e “UX designer em part-time” luto diariamente com essas questões, especialmente:
– o cargo de alguém não ser preto no branco
– o UX não ser uma funcinalidade ou algo que se possa adiconar depois; tem de estar omnipresente
– o valor do perfecionismo.

Alexandre
Visitante
Alexandre
O artigo está muito bom, parabéns. No entanto acho que alguns tópicos são um pouco utópicos. A constante refactorização do código é problemática porque o seu valor não é reconhecido pela organização. O projecto está sempre atrasado e é difícil explicar a um gestor a razão de re-inventar a roda. O plano de projecto deve passar pelo programador, mas geralmente o GP é que decide tudo. É errado, mas o programador raramente tem o poder da decisão. Pode aconselhar, mas como é tudo para ontem pouca ou nenhuma diferença faz. A questão da delegação da culpa também é tricky. Se… Read more »
Luís Soares
Visitante
Olá Alexandre, Obrigado 🙂 Quanto ao ponto da refatorização, não se deve fazer por fazer. Eu referia-me mais aos momentos em que algo tem de ser feito. Por exemplo, quando há um funcionalidade nova. Claro que não há regra sem exceção. O que quero dizer é que se deve refatorizar se há valor acrescentado, mas sempre fundamentado. “A questão da delegação da culpa também é tricky.” Talvez eu me tenha explicado mal. Não disse que a pessoa tenha de resolver. É apenas uma questão de atitude: em vez de ter uma atitude “não é comigo”, mais vale ter uma atitude… Read more »
Jorge
Visitante
Jorge

Só e só :))))

Jorge
Visitante
Jorge

Nao vi ai o PEBKAC em lado nenhum….

Luís Soares
Visitante

o que defendo é que não existem PEBKACs (mesmo que existam, é uma questão de me reger por esse princípio).
se o utilizador não consegue fazer, das duas uma:
ou não faz parte do público-alvo, ou a equipa não resolveu bem o problema.

Courela
Visitante
Courela

A minha principal “batalha” tem sido mesmo com os prazos. É sempre tudo para ontem e depois esperam que o software tenha qualidade. Muitas vezes o developer nem tem voto na matéria, os prazos são definidos pelos gestores, ou pior, pelo cliente.

JJ
Visitante

Concordo com alguns pontos/explicações e discordo com outros.

Qualquer das formas, existem coisas que também tenho de melhorar…
Mas como o artigo destaca, todos os programadores uma vez ou outra, falham em algum aspecto mencionado no artigo. E quem diz programador, diz outra área informática, porque alguns dos pontos também se aplicam.

KWu
Visitante

Eu passei com distinção em todas as práticas descritas.

Ou sou muito bom ou muito aldrabão…

Rui C
Visitante
Rui C

Eu tenho um gravíssimo … é não saber programar. :/

Mark
Visitante

Eu sempre tentei utilizar estas e outras metodologias de forma a melhorar o projecto, ou seja fazer mais e melhor com muito menos esforço.

O maior problema é tentar convencer os pseudo-gestores que “perder” 1 ou 2 horas a planear e analisar o projecto vai acelerar todo o processo. Para muitos desenhos é para designers e mesmo assim só pode a versão ficar a cores.

Por muito triste que seja o “Developer” que utilize todas estas más praticas vai ser muito mais respeitado pelo chefe pois consegue mostrar qualquer coisinha em menos de nada.

Luís Soares
Visitante

tenho pena de não ter usado esta frase 🙂
“Para muitos desenhos é para designers”

tomesoares
Visitante
tomesoares

A base de qualquer pessoa ou equipe de trabalho, parte sempre da “humildade intelectual” individual.
O conteúdo deste post não se aplica só a programadores mas de forma longitudinal a todos aqueles que trabalham em equipa.
+1

lmx
Visitante

+10

Steve
Visitante
Steve

muito bom artigo. Parabéns

int3
Visitante

Eu tenho alguns maus hábitos :/
Tenho que melhorar.

lmx
Visitante

não há ninguém perfeito,

Como nos gerimos como um todo e a maior parte deve ser seguida… as coisas que pensamos serem boas podem ser consideradas más.. 😉

lá está temos todos maus habitos, mas aquilo que hoje é um mau habito, amanhã também pode ser uma mais valia. lol 🙂

int3
Visitante

pois pode. 😀
Eu não consigo estimar o tempo que demoro a desenvolver uma certa aplicação porque há sempre algo que mete-me a martelar em algo durante uma noite e acaba por ser algo simples.
E eu culpo sempre o utilizador. x)

Carlos
Visitante
Carlos

Eu tenho o mesmo problema, as vezes uma coisa tao simples faz me perder até dias, coisa que eu não tinha previsto e que me faz sair logo fora dos planos. As vezes é tao simples que ate tenho “vergonha” de dizer ao cliente e invento outro problema.

joaquim sousa
Visitante
joaquim sousa
Programação é uma arte que deve ser cultivada logo desde muito cedo, talvez por volta do 2ºano de escolaridade. Porque de certa forma obriga a sistematizar o pensamento, a estruturar as bases para a resolução de problemas complexos que sem essa organização sairiam um fiasco. Por isso é que eu acho que cá em Portugal devia-se incutir nas crianças e nos jovens o gosto pela programação alicerçando sempre como é obvio em aspectos práticos e motivantes adequados à sua idade. Porque de outro modo estaríamos a criar não um gosto mas sim um pesadelo que no final do dia leva… Read more »
joaquim sousa
Visitante
joaquim sousa

Quando eu falo em algoritmia falo dos pseudocódigos…

ze.ccjs
Visitante
ze.ccjs

Concordou em tudo menos numa coisa: criança não! No 8° ano ou por aí, tudo bem. Antes, as criança têm de usufruir disso mesmo: serem criança! Abraço.

Luís Soares
Visitante

Olá Joaquim.
Grandes verdades. Acho que nos EUA já estão a ter essa mentalidade, de considerar a programação uma competência que todos deviam ter desde cedo. E há cada vez mais recursos na web que tentam “democratizar” a programação. Tal como a ciência no geral, a programação não pode nem deve ser de uma elite.

Carlos
Visitante
Carlos

Agora não me lembro o nome do país, mas sei que era um nórdico, que vai começar a dar noções programação nos primeiros anos de escolaridade. E muito útil nem só para quem um dia seguir a área, mas também para desenvolver o pensamento logico desde muito cedo.

lmx
Visitante

Os nórdicos são “uns leões nisso”…

Os míudos na escola ja desenham e mexem em microcontroladores…estão envolvidos num acompanhamento brutal desde cedo na ciencia…é impressionante..

Os putos participam em torneios de ciencia..é impressionante…

Cá em Portugal…o ATL é mesmo, piscina, futebol, basket…e farturas 🙂

Depois admiram-se que os Nórdicos sejam extremamente evoluidos…

Eles também teem um tempo da treta, e isso ajuda por um lado ao desenvolvimento intelectual…mas nós abusamos no desporto, e afins 🙂

Mr.Antunes
Visitante
Mr.Antunes

Eu acho que devia ser mesmo desde de bebés, em vez de música púnhamos-los a ouvirem código máquina, assim quando chegassem aos 10 anos já sabiam programar em binário…

O que foi da raça humana até agora pois pelos vistos nunca tivemos boas metodologias de resolução de problemas.

Se abrissem os olhos…

Luís Soares
Visitante

tem de haver um balanço… há coisas nas escolas que podiam muito bem ser substituídas. desporto não é uma delas pois mantém a mente sã..
os miúdos aprendem apenas a descorar para passar, em vez de se estimular a criatividade e o raciocínio.

Sigsegv
Visitante
Sigsegv

Os franceses já fazem isso desde os anos 80. Programação em logo. Sei do que falo apanhei isso em 85 na primeira classe.

joaquim sousa
Visitante
joaquim sousa

Muito bom tópico, arrisco-me a dizer que este foi sem dúvida o melhor artigo dos últimos tempos aqui no pplware. Muito bem.
Quando a pessoa pensa que faz um código em x tempo isso nunca é realista há sempre muitos factores em jogo. Pseudocódigos acho que é sempre um bom começo para assentar ideias, de um certo modo que é “o pontapé de saída” para o que queremos fazer.

lmx
Visitante

mas isso do desenhar a app, ou que seja, leva tempo…ás vezes mais tempo que fazer o código…e os gestores tendem a se defender a eles…é uma treta…

No entanto se “saltares a gatilhar” sem conseguires ter uma visão do que queres…podes ficar meio enrascado(ou enrascado na totalidade) , se o projecto for grande…

Luís Soares
Visitante

obrigado!
sim.. após os fluxogramas pode-se saltar para o pseudocódigo. Ou então usá-lo como alternativa.

O que não defendo é quando o pessoal se lança logo a bater código que nem leões, sem qualquer desenho prévio do conceito via uma dessas técnicas. É uma ilusão pensar que se está a ganhar tempo ao fazê-lo…