No dia 9 de setembro de 1945 a equipe da Dr. Grace Hopper (que mais tarde se tornaria a criadora da linguagem COBOL) e de Howard H. Aiken estava diante de um problema na sala do computador Mark II. Depois de uma análise minuciosa detectaram uma mariposa entre os contatos de um dos relés do computador. Ironicamente Grace documentou o incidente nos registros adicionando o inseto e a frase “First atual case of bug being found”.
Foto do que possÃvelmente seria o primeiro bug encontrado em um computador
Existe um efeito psicologico muito forte quando um erro explode em um software. É dificil para um profissional assumir que cometeu um erro ou deixou de testar adequadamente antes de colocar algo em produção. Quando um bug aparece, a tendencia é sempre procurar pelo culpado ao invés de procurar pelo problema.
Há alguns anos eu trabalhei em uma consultoria que mantinha uma lista na parede com um ranking dos programadores que mais deixavam bugs no código. Toda vez que um usuário ligava reclamando de algo, iniciava-se uma espécie de corrida para ver quem encontrava o culpado primeiro. Assim que o infeliz programador era apontado, ele era obrigado a vestir uma faixa com os dizeres: “Eu quebrei o código” durante todo o dia de trabalho.
Não é possÃvel desenvolver um software isento de falhas. Infelizmente, os computadores ainda estão limitados a fazer aquilo que mandamos ele fazer, e não necessariamente aquilo que queremos que ele faça. E enquanto isso não se tornar uma realidade estaremos sempre em modo de manutenção.
Desenvolver é um ciclo que envolve escrever algo original por alguns minutos e então passar algumas horas solucionando bugs. Escrever um código novo e então reescrever algo que aparentemente ficou ruim. Todos os programadores deveriam ter isso em mente antes de ingressarem nessa profissão.
Um bom programador precisa inicialmente desligar todos esses sistemas instintivos de defesa. Eu sei muito bem o que é estar procurando por um bug no código com o gerente de um lado e o cliente do outro observando cada passo que você dá. Concentre-se, não perca o foco.
Pense em um médico. O paciente chega no consultório com dor de cabeça, nauseas, dor em certas partes do corpo, etc.. Se o médico tentar solucionar cada um dos sintomas de forma isolada ele estará mascarando o real problema do paciente. O objetivo é identificar o que está gerando todos esses sintomas. Ao localizar a raiz do problema e medicar o paciente corretamente, de forma natural todos os sintomas desaparecerão.
Da mesma forma, o maior erro que um programador pode cometer ao tentar resolver uma falha em um sistema é atacar os sintomas. Isso normalmente só confundirá a sua mente.
A maneira mais simples de encontrar um erro no código é explicando o problema para outro programador. A outra pessoa não precisa dizer uma única palavra, o simples fato de explicar passo-a-passo o que o código deveria fazer, normalmente é o suficiente para que você mesmo vislumbre o que pode estar causando a falha.
Pode parecer simples demais, mas ao explicar o problema para outra pessoa você terá de entrar em detalhes que talvez estejam passando despercebidos por você. Isso lhe dará uma nova visão do problema.
Solucionar bugs é parte da rotina de um programador. Algumas técnicas apenas diminuem a quantidade de incidencias no seu código, mas evitá-los totalmente é impossÃvel. O mais importante é ter em mente que um erro no software, mesmo trabalhando em uma grande equipe nunca terá um culpado, ele sempre será um problema seu.
Foto de Marc Castejón
Estou sempre recebendo e-mails de pessoas interessadas em Ruby me questionando se realmente vale a pena gastar o seu tempo estudando essa linguagem de programação ao invés de estudar linguagens mais conhecidas como Java ou C#. Tenho certeza que a mesma dúvida preenche a mente de qualquer um que esteja interessado em apostar em alguma tecnologia emergente.
Por que alguém estaria disposto a gastar o seu precioso tempo estudando algo no qual não tem certeza se terá a oportunidade de ganhar dinheiro com isso depois?
A minha resposta sempre foi: “paixão”. Bons programadores são apaixonados pelo que fazem, isso explica o motivo deles adorarem estar sempre aprendendo coisas novas.
Mas existe um dilema cultural aqui. A maioria de nós vem de famÃlias que emergiram para a classe média apenas uma ou duas gerações atrás. Fomos ensinados por nossos pais e avós a colocar os interesses financeiros da famÃlia em primeiro lugar e deixar a satisfação profissional em segundo plano. Isso explica muito bem porque tantos profissionais continuam em empregos ruins, mesmo insatisfeitos.
Seguindo o pensamento de nossos pais, não é mais inteligente apostar no time que está ganhando? De forma alguma. Correr riscos e estar satisfeito profissionalmente são sem dúvida a receita para o sucesso.
Foto de Marcin Wichary
A muitos anos atrás programar em Visual Basic era uma escolha de baixo risco. Para um jovem em inicio de carreira, como eu, parecia a escolha óbvia a fazer. Era fácil encontrar trabalho, porém havia tantos programadores Visual Basic no mercado que a média salarial não era nada especial. Um baixo risco e uma baixa recompensa.
Com o tempo o Visual Basic cedeu espaço ao C# e mais uma vez essa era a escolha natural para muitos programadores. Mais uma escolha de baixo risco e por consequência uma recompensa compatÃvel.
Depois de mais de dez anos trabalhando com tecnologia Microsoft, conheci o Ruby. Eu realmente gostava de programar com essa linguagem, porém poucas empresas estavam investindo em Ruby e era muito difÃcil conseguir um emprego para trabalhar com ele.
Mas alguma coisa dentro de mim dizia que havia algo especial naquela linguagem somada ao framework Rails. Era um sentimento forte de que aquilo poderia se tornar grande.
Eu investi cedo em Ruby, numa época em que o risco era muito alto. Alto risco, grandes recompensas.
Foto de D'Arcy Norman
Até pouco tempo atrás o Textmate era uma unanimidade para programadores Rails. Recentemente porém tenho visto alguns programadores migrando para outros editores de texto, como o Vim e o Emacs.
Embora eu já tivesse uma certa experiência com esses últimos, eu nunca havia tentando desenvolver código de verdade com eles. Depois de fazer uma experiência trabalhando com cada um deles por uma semana, vejo que ambos são excelentes editores de textos e obviamente boas alternativas para o desenvolvimento de software em diversas linguagens.
Porém, quais critérios devem ser usados ao comparar essas ferramentas e decidir qual delas é a melhor? Quais são as caracterÃsticas mais importantes em um editor de textos que poderiam determinar a minha escolha?
Acredito que o mais importante nesse caso é ser proficiente. Chega a ser irritante ver alguém pressionar dezenas de vezes a seta para a esquerda afim de colocar o cursor no começo de uma linha ou recorrer ao mouse para chegar ao topo do documento no Textmate, sendo que existem atalhos para se fazer isso com apenas uma combinação de teclas.
Escolher um editor de textos para programar não deve ser algo trivial. A curva de aprendizado é bastante Ãngreme até que você não precise mais pensar em quais combinações de teclas devem ser usadas para realizar uma operação. Tudo deve acontecer por reflexo.
É importante que a ferramenta seja flexÃvel, permitindo que o programador possa configura-la de acordo com as suas preferencias. Como o processo de aprendizado é lento, é importante que você possa continuar usando o editor de textos mesmo ao trocar de uma linguagem para outra. Bons editores são capazes de aprender a trabalhar com qualquer nova linguagem de programação que apareça.
Alguns recursos como syntax highlighting e auto-indentation são indispensáveis para o desenvolvimento de software.
A conclusão é que todos esses editores de textos mencionados no inicio do artigo passam com louvor na avaliação dos requisitos mÃnimos. Mas isso ainda não responde a pergunta: Qual é o melhor editor de textos para se trabalhar com Rails?
Eu não sou um usuário comum do Textmate. Além de me sentir totalmente à vontade com essa ferramenta eu estou constantemente implementando meus próprios Bundles e refinando os recursos que mais uso para o meu estilo de trabalho.
Como particularmente sou mais produtivo no Textmate, então especialmente para mim essa é a melhor ferramenta para programar em qualquer linguagem.
A idéia aqui não é defender o meu editor preferido. De fato, não importa se você escolheu o Textmate, o Emacs ou o Vim. Desde que o seu editor seja uma extensão das suas mãos.
MS-DOS
Acredite, nem sempre houve interfaces gráficas. Meu primeiro contato com um computador foi feito através de uma tela preta com letras verdes. Não me lembro exatamente, mas provavelmente era alguma versão do MS-DOS ou do PC-DOS.
Qualquer criança com acesso a um computador nessa época, rapidamente aprendia a manipular arquivos e diretórios através de comandos básicos que o sistema operacional oferecia. Era necessário aprender esses comandos se quisesse se divertir com um novo jogo, por exemplo. Além disso, muitos jogos mais sofisticados exigiam que o usuário entendesse, mesmo que superficialmente, como o sistema operacional manipulava a memória. Termos como memória estendida, superior, convencional e expandida eram comuns na roda de amigos.
Pode parecer nostalgia, mas mesmo depois de mais de uma década, todo esse conhecimento básico continua me sendo prático até os dias de hoje. Afinal, a maior parte do meu trabalho é resolvido através daquela mesma janela do terminal.
É claro que muitos programadores conseguem realizar todo o seu trabalho através de uma um ambiente integrado de desenvolvimento (IDE). Mas será que realmente podemos fazer tudo igualmente bem apontando o ponteiro do mouse e clicando?
Eu sempre acreditei que não. Interfaces gráficas são ótimas e realmente convenientes para muitas situações, mas o seu poder também é a sua limitação. Quando nos tornamos dependentes de uma interface gráfica (GUI) para realizar nosso trabalho, estamos presos à imaginação dos desenvolvedores que a criaram.
No terminal, nossa liberdade é quase infinita. Não vamos encontrar nada muito sofisticado lá, a maioria dos comandos e utilitários realizam apenas uma única tarefa. Mas realizam essa tarefa muito bem. Não existem distinções entre documentos, diretórios, discos rÃgido, drives de CD e DVD, teclados, impressoras e monitores por lá. Todos são simplesmente arquivos e são manipulados como tais, o que facilita muito as coisas.
Mas a maior vantagem do terminal é que podemos facilmente combinar sequencias desses comandos em scripts, o que nos dá a liberdade de automatizar praticamente qualquer tarefa que podermos imaginar, algo essencialmente importante para um programador pragmático que se preze.
Tire o máximo de proveito da sua IDE, mas não ignore o terminal. Aprender a usar bem o shell deve ser uma prioridade para qualquer programador iniciante.
Foto de Balakov
Se você está preocupado com a performance do seu programa, saiba que métodos macarrônicos são mais velozes. Ao escrever todo o código dentro de um único método você estará evitando todos os custos envolvidos na chamada de outros métodos, reduzindo o tempo de execução do seu código.
Embora o argumento acima não seja falso, é triste reconhecer que muitos programadores ainda possuem esse tipo de pensamento. Talvez não de uma forma tão radical, mas são poucos os profissionais que entendem que programar é muito mais do que escrever instruções para um computador, mas que o código que escrevemos também será lido por outras pessoas.
O tamanho do método é proporcional a dificuldade de manutenção e entendimento. Quando damos prioridade a escrever métodos pequenos e com nomes descritivos aumentamos a produtividade do time (incluindo o autor do código).
Métodos pequenos, com poucas linhas de código, facilitam a manutenção e a inserção de novas funcionalidades. Use as caracterÃsticas da linguagem a seu favor. Não é feio criar um método com um nome longo e descritivo em Ruby. Respeite a pontuação. Acrescente o sinal de interrogação no final quando o método retornar um booleano.
Não estamos apenas escrevendo código, estamos nos comunicando.
P.S.: Sim, eu acabei de ver uma coisa que me deixou irritado.
Ilustração de hartboy
Definir quanto tempo será necessário para finalizar uma tarefa ou o desenvolvimento de um software não é (ou pelo menos não deveria ser) algo trivial. Estimar prazos faz parte do nosso dia-a-dia como programadores.
O que muita gente não se dá conta é que a precisão com que um programador prevê a entrega de tarefas e projetos é um poderoso indicador do quão bom ele é.
Para informar de forma precisa o tempo necessário para a realização de algo em desenvolvimento de software é necessário que o programador possua uma certa experiência no assunto, tenha um bom domÃnio do negócio, seja rápido e produtivo.
Embora muitos de nós não apreciem essa difÃcil tarefa, estimar prazos é parte do nosso trabalho. Fazer isso bem pode ser a diferença entre um programador profissional e um amador.
Em um dia normal, estamos estimando prazos o tempo todo. Ao colocar a comida no micro-ondas você deve informar quantos minutos serão necessários para esquenta-la. Se você tem um horário fixo para acordar, deve analisar quantas horas de sono serão suficientes e então decidir quando deve ir para a cama.
O segredo não está no tempo, mas em quão precisa deve ser a sua estimativa. Se seu chefe pergunta que horas você entregará o relatório amanhã, ele quer ter uma ideia se será antes ou depois do almoço. Se ele lhe pergunta quanto tempo será necessário para resolver um bug critico e colocar o sistema de volta em produção ele precisa de uma precisão maior.
A escala de tempo é muito importante ao se estimar prazos. Por exemplo, você pode dizer “O projeto será entregue em 25 dias” ou pode dizer “O projeto será entregue em cerca de 5 semanas”. Embora ambas as frases indiquem o mesmo tempo, o efeito sob cada uma delas pode ser diferente. Ao dar a primeira resposta, seu cliente provavelmente anotará na agenda dele o dia exato em que você entregará o projeto. Por outro lado, a segunda resposta fará com que ele lhe procure a qualquer momento daqui a 4 ou 6 semanas.
O livro The Pragmatic Programmer dá uma importante dica que nos ajuda a escolher a escala de tempo apropriada ao estimar prazos. Veja a tabela:
1-15 dias -> dias
3-8 semanas -> semanas
8-30 semanas -> meses
30 + semanas -> pense bem antes de dar uma estimativa
Qual a vantagem disso? O fato é que quanto maior o tempo, mais difÃcil é a previsão, exigindo que você seja cada vez mais impreciso. Por exemplo, se sua estimativa é que serão necessários 125 dias para terminar um trabalho, é muito mais seguro dizer que precisará de “cerca de 6 meses” para finaliza-lo.
Todas as estimativas que fazemos são baseadas em nossas experiências passadas. Mas, o que fazer quando é necessário estimar algo que você nunca fez ou que não conhece? A resposta é simples: “não estime”. É melhor pedir para que alguém que já tenha feito algo semelhante lhe dê uma ideia do tempo necessário.
Além de considerar o grau de precisão, também é importante entender qual é o problema antes de começar a chutar um tempo. Quase sempre nossas estimativas dependem de outros fatores para darem certo: “Supondo que não haja trânsito dá para chegar aà em 20 minutos”.
Se possÃvel é muito útil testar alguns aspectos do projeto antes de dizer quanto tempo será necessário para cumpri-lo. Se o sistema precisa ser carregado dentro do Facebook, seria muito bom poder gastar um tempo criando alguma coisa bem simples para esta plataforma afim de analisar o grau de complexidade, isto sem dúvida aumentará a precisão da estimativa.
É muito importante levar em consideração que a equipe, sua produtividade e o ambiente afetam diretamente sua estimativa.
Analisando todos estes fatores, a conclusão é que há apenas uma única resposta correta a se dar quando lhe é pedido para estimar um prazo: “Me dê algum tempo para pensar”. Você sempre terá resultados melhores se retardar a resposta e pensar um pouco mais.
Foto de bookdepository
Eu amo programadores incompetentes. Graças a eles os profissionais de TI não podem reclamar de falta de emprego.
Nos últimos anos o mercado nacional de TI registrou um aumento de 40% no número de novas vagas de trabalho. Há estimativas que revelam que a necessidade de programadores no Brasil ultrapassa 40 mil profissionais por ano.
Afim de resolver esse problema, as empresas tem contratado cada vez mais programadores ruins. Porém nós não temos um problema com a quantidade, mais sim com a qualidade. Apenas um único programador incompetente pode facilmente criar duas novas vagas de emprego por ano.
Contratar mais programadores ruins só aumentará a necessidade por mais deles. Se tivéssemos mais programadores bons (que são facilmente identificados), seria necessário contratar menos e não mais.
Assim, quanto mais programadores ruins no mercado, mais empregos. Vida longa aos programadores incompetentes!
Foto de Decepticreep
Eu tenho uma lista de programadores que merecem o meu respeito. Provavelmente você também deve admirar o trabalho de alguns colegas de profissão. Estranhamente, eu sou obrigado a confessar que vi muito pouco do código de cada um deles.
A maior parte desses programadores ganharam o meu respeito através dos softwares ou livros que escreveram. E não através do seu código.
Um exemplo é Yukihiro Matsumoto. Ele foi o criador da linguagem de programação que utilizo diariamente para realizar o meu trabalho e obviamente está na minha lista de heróis, porém pouquÃssimas vezes eu olhei para o código fonte do Ruby, e quando o fiz não teria como identificar se o que estava vendo foi originalmente escrito por Matz ou por algum outro colaborador.
Minha lista está recheada de pessoas que escreveram uma linguagem de programação interessante, um framework útil, uma ferramenta que facilita minha vida ou um bom livro sobre programação. Mas são poucos os que passei a admirar depois de ver algum código que escreveram. Isso me faz pensar…
Na realidade o código que escrevemos tem muito pouco impacto sobre as pessoas. O que realmente interessa é o que fazemos com o código. O que importa é o produto final.
O problema é que a maior parte dos programadores se preocupa demais com o código. Passam horas e mais horas tentando criar o algoritmo perfeito. Porém se esquecem que o melhor código do mundo é inútil se ninguém utilizar o software que o contém.
De forma alguma estou dizendo que devemos jogar tudo para o alto e parar de se importar com a qualidade do código que escrevemos. Porém, tão importante quanto realizar um bom trabalho é fazer com que outras pessoas tomem conhecimento do que você está fazendo. A minha proposta é que aqueles que já são bons programadores hoje, invistam em aperfeiçoar suas habilidades como escritores e palestrantes. Que participem mais ativamente nas comunidades de software e melhorem suas habilidades sociais.
São essas habilidades que vão diferencia-lo dos demais. Não escreva apenas código. Estude, escreva e fale mais sobre código.
Foto de lmw626
É interessante analisar o efeito que uma linguagem de programação tem sobre a mente do programador, principalmente a sua capacidade de influenciar a maneira como enxergamos um problema. A diferença na sintaxe e os recursos disponÃveis afetam a forma como pensamos e nos comunicamos, inclusive no mundo real.
O mesmo problema pode ser solucionado de várias formas diferentes, dependendo da linguagem de programação adotada. Certamente a abordagem escolhida para resolver um problema utilizando Ruby não será a mesma se você usar Java.
Outro fator que exerce uma grande influencia sobre a forma como resolvemos os problemas e pensamos é o domÃnio do aplicativo. Somos tentados a utilizar o mesmo vocabulário do cliente no código. O meu conselho é tirar o máximo de vantagem desse efeito. Pode ser realmente produtivo “falar” a mesma lÃngua que o cliente também dentro do código. Por exemplo, se o cliente explicar uma funcionalidade dessa maneira:
Quando todas as unidade de um produto se esgotarem em uma das lojas, então o sistema deve solicitar mais 10 unidades do mesmo produto para a fábrica.
Seria muito bom se o código produzido fosse algo parecido com isso:
if product.sold_out?
Factory.order 10, product, :to => store
end
É óbvio que não esperamos que o cliente entenda o código e muito menos que ele altere algo por conta própria, mas nós programadores podemos nos beneficiar muito disso.
Não importa se você está escrevendo um código simples como o exemplo acima ou se construiu uma DSL para se aproximar ainda mais da linguagem do cliente. O importante é estreitar a comunicação entre os envolvidos. Assim o seu cérebro estará livre para se concentrar no que realmente interessa: a solução de problemas.
gabriela em 
biker solitario em 