Programadores de verdade (pra descontrair o feriado)
A definição prática do que era um programador de verdade em 1983 (ano da publicação do artigo original da Datamation com o texto que o Irado referencia abaixo) mudou bastante desde então, mas o texto ainda pode provocar reflexão (e algum riso, especialmente para quem chegou a programar alguma coisa ainda na década de 1980).
Para outra referência sobre os míticos “programadores de verdade”, leia também The Story of Mel, a Real Programmer – embora seja difícil compreender a complexidade do hardware descrito, para quem não viveu a época pré-integração.
Segue o texto do Irado:
“Não é bem uma noticia mas servirá para descontrair a historia que encontrei perambulando pela ‘net (pra variar). É um texto que (segundo o autor do link) já é antigo, mas sempre atual. Vale a pena ler com atenção, é verdadeiramente engraçado, hilário algumas vezes.
Dica: o titulo já indica do que se trata: o comportamento dos REAIS E VERDADEIROS PROGRAMADORES; mais ou menos como um antigo ‘mote’ de que “.. boy que é boy não usa o freio, capota!””
Enviado por irado furioso com tudo (iradoΘsafe-mail·net) – referência (codeproject.com).
@brlinuxblog
Feed RSS
Programadores de verdade?
http://xkcd.com/378/
A verdade atemporal:
“Real Programmers don’t need comments — the code is obvious.”
O melhor:
geek hero comic
http://www.geekherocomic.com
Quem tem o KDE4 pode pegar usando o plasmóide de tirinhas, muito bom :-)
Aos saudosistas:
ÁGUAS DE MARÇO
É pau, é bug
É o fim do programa
É um erro fatal
O começo do drama
É o turbo Pascal
Diz que falta um begin
Não me mostra onde é
E capota no fim
É dois, é três
É o quatro oito meia
Instrução ilegal
Quem bloqueia
É o erro no boot
É um disco mordido
Hard disk estragado
Ai meu deus tô f*****
São as barras de espaço
Exibindo um borrão
É a promessa de vídeo
Se espalhando no chão
É o computador
Me fazendo de otário
Não compila o programa
Salva só o comentário
É ping, é pong
O meu micro reboota
O Scan não retira
Vírus filho da p***
O Windows não entra
E nem volta pro DOS
Não funciona o reset
Me detona o CMOS
É abort, é retry
Disco mal formatado
PCTools não resolve
Norton trava o teclado
É impressora sem fita
Engolindo o papel
Meu trabalho de dias
Foi cuspido pro céu…
Marcelo (usuário não registrado) em 21/04/2009 às 4:25 pm
A verdade atemporal:
“Real Programmers don’t need comments — the code is obvious.”
FATO!
“the determined Real Programmer can write FORTRAN programs in any language”
Excelente, rs!
Um programador de verdade, um programador profissional, SEMPRE CRIA código estruturado e MUITO BEM documentado (dependendo do tamanho do programa, até manuais de desenvolvimento precisam ser gerados).
Sem isso, o susposto “programador” NUNCA SERÁ mais do que uma criança criando simples scripts, ou pior, um lambão que só sabe criar código macarrônico irreconhecível e cheio de gambiarras, além do tempo de “desenvolvimento” sempre crescer exponencialmente a medida que a ganbiarra aumenta :-)
E não se ofendam, desenvolvedores de shell script, quando eu falo sobre “simples scripts” no texto acima. Pois eu acho que um bom profissional em shell script não cria scripts, mas sim, programas em shell. ;-)
Rodrigo Amorim, sugiro que leia sobre “XP”
Você está falando sobre eXtreme Programming? Se for, eu já até revisei livro sobre o assunto, só que nunca quis implementar. E saber sobre XP (além de não ter razão para ser citado em função do meu comentário sobre “boa programação”) não muda meu ponto de vista no que eu escrevi acima. XP é apenas uma parte na gerência de um projeto de software. Isso se o projeto optar pelo uso da XP. XP não é a salvação da lavoura. Tem equipes que preferem, outras não. É quase como a briga religiosa entre VI e Emacs :-D
Voltando ao assunto da documentação de código, acho fundamental. Principalmente para códigos grandes, de projetos grandes, onde você trabalha com uma equipe inteira. Você trabalha de maneira padronizada no código também. Inclusive isso é importante para quem vai começar a trabalhar no projeto (ou até mesmo para você quando for retornar ao trabalho depois de algum tempo sem mexer no seu código). Ajuda ao usuário a saber por onde começar, como entender mais rápido o código, além de começar a trabalhar a sério no mesmo, de forma mais rápida :-)
Principalmente em uma empresa séria, onde ninguém é maluco de não gerir bem o desenvolvimento de seu software (e a documentação é uma parte muito importante do processo de gerência de software).
Correção da última frase do penúltimo perágrafo:
“Isso a saber por onde começar, como entender mais rápido o código, além de começar a trabalhar a sério no mesmo, de forma mais rápida :-)”