Programadores são naturalmente introvertidos e não sabem se comunicar. Deve ser por isso que existem tantos programadores ruins. Programar é um exercício de comunicação.

Anos de experiência desenvolvendo software, conhecer muitas linguagens de programação, escrever códigos de qualidade, nada disso tem valor se você não conseguir se comunicar com outras pessoas. De nada vale ter muito conteúdo e guardar isto só para você.

Aqueles que desejam uma carreira bem sucedida como programadores, além possuir um conhecimento técnico acima da média também precisam estar constantemente melhorando suas habilidades de comunicação.

Inevitavelmente passamos horas em reuniões. Precisamos interagir com clientes e entender as suas necessidades. Escrevemos propostas e relatórios. Estamos em uma luta sem fim tentando convencer nossos companheiros e empregadores a adotarem uma nova tecnologia ou prática que tornará nosso trabalho mais produtivo e divertido. E acima de tudo: escrevemos muito código.

O código é uma combinação de signos utilizados para transmitir uma mensagem. Porém a comunicação só se concretizará se o receptor souber decodificar a mensagem. Computadores costumam fazer isto muito bem, mas não estamos escrevendo código apenas para máquinas. Um código mal escrito e cheio de ruído dificultará o trabalho de outros programadores quando houver a necessidade de estudá-lo.

Nosso trabalho se resume a pura e simplesmente comunicar-se, por isso é tão importante fazer isso bem.

Não importa se você está escrevendo um livro/relatório/e-mail ou se preparando para uma reunião, planejamento é tudo. Um dos segredos dos bons comunicadores é saber o que dizer, antes de sair abrindo a boca e despejando pensamentos. Pergunte-se: “Se eu falar desta maneira, será que todos entenderão com clareza a informação que eu estou tentando passar?”. Repita esta pergunta para si mesmo até que esteja convicto disso. Anote estas ideias e planeje como aborda-las.

Comunicação é repassar informações. Para que isto seja possível é vital que todas as pessoas presentes entendam o que você está dizendo. Antes de começar a argumentar sobre as vantagens de se utilizar um banco de dados não relacional no projeto, certifique-se de que todos sabem do que você está falando. Caso contrário, você não estará impressionando ninguém. Estará apenas sendo chato.

Se você está vendendo uma ideia, certifique-se de conhecer cada uma das pessoas envolvidas na negociação e fale somente o que ela precisa ouvir, nem mais nem menos. Talvez você precise convencer o seu gerente, o pessoal de marketing, o usuário final do aplicativo e até outros desenvolvedores. Trate cada grupo de forma individual.

Tão importante quanto dizer a coisa certa, é dizer na hora certa. Pegar seu gerente no corredor, logo após o seu supervisor lhe chamar a atenção por ele ter entregue um aplicativo cheio de bugs é uma excelente oportunidade para convencê-lo a adotar testes automatizados nos próximos projetos. Mas também será uma péssima hora para pedir um upgrade na sua máquina.

Para ser tornar um bom escritor é necessário ler muito, seguindo o mesmo principio se você deseja falar bem é importante escutar. Programadores tem sérios problemas para escutar. Durante uma reunião, assim que o cliente começa a explicar uma funcionalidade do novo aplicativo, a mente do programador abandona a sala e automaticamente já começa a trabalhar no código que precisará ser desenvolvido. Deste momento em diante tudo o que for dito na sala será ignorado. Concentre-se. Se você não escutar o que os outros estão dizendo, como espera ser ouvido?

Lembre-se disso: Não é somente o que você diz, mas também como você diz. A menos que você esteja trabalhando sozinho dentro de uma bolha, você deve ser capaz de se comunicar. E quanto mais eficaz for a sua habilidade de comunicação, mais influente você se tornará.

Foto de James Yeung

Deus ajuda quem cedo madruga. De acordo com este antigo provérbio se você tem o hábito de acordar cedo e trabalhar por horas a fio com muito afinco e dedicação, então você se dará bem na vida. Mas isto também vale para a carreira de um programador? Muita dedicação e trabalho duro são o suficiente para atingir a imortalidade?

Embora exista muita gente esforçada que literalmente dá a sua vida pela empresa em que está trabalhando, não é o trabalho braçal que determinará o seu sucesso. O seu conhecimento e experiência é que são o seu maior patrimônio profissional.

Mas infelizmente nessa área de atuação o nosso conhecimento tem um prazo de validade muito curto. Novas tecnologias, linguagens de programação e metodologias aparecem quase que diariamente e é cada vez mais difícil acompanhar este ritmo. Por outro lado, não acompanhar estas mudanças pode torna-lo obsoleto para o mercado.

Profissionais mais antigos já estão acostumados com isto, só que até pouco tempo atrás a necessidade de se reciclar não exigia tanta velocidade. Quando uma nova tecnologia era lançada, normalmente demorava um tempo até que o primeiro livro fosse publicado e para que outros profissionais e empresas começassem a adota-la.

Agora dado a quantidade crescente de novos artigos, livros, screencasts e blogs na internet, isto tem acontecido cada vez mais rápido. Existem estudos que indicam que a soma da informação do mundo dobra a cada 80 dias. Analisando desta forma, se você permanecer três meses sem se atualizar, já pode se considerar obsoleto.

Pegue como exemplo o Ruby Inside Brasil. Lá são publicados artigos quase que diariamente sobre um único tema: Ruby. Temos uma equipe relativamente grande e muito motivada tentando cobrir as principais noticias relacionadas a esta linguagem de programação e mesmo assim isso algumas vezes tem se tornado uma tarefa árdua dado a grande quantidade de informação gerada em cima deste único tópico.

Assim como o seu conhecimento, o seu valor para uma empresa ou cliente também vai diminuindo com o tempo. Precisamos trabalhar para que isto nunca aconteça. Não existe nada pior do que continuar empregado apenas por ter muito tempo de casa.

Qual é a sua estratégia para se manter atualizado?

Foto de Ernest Descals

Não entendo muito de pintura, mas os amigos que apreciam este tipo de trabalho sempre dizem que uma das coisas mais difíceis sobre pintar é saber quando parar. Entender que o trabalho terminou. Uma pincelada a mais pode arruinar um lindo quadro.

Acredito que o mesmo acontece com software. Programadores profissionais sempre defenderam refatoração, testes, integração contínua e outras práticas que visam deixar nosso código mais limpo e livre de falhas. Mas existe um limite para a aplicação dessas práticas? É possível que a preocupação exagerada com a qualidade do software acabe prejudicando o projeto?

Ferramentas como Flog, Flay e Heckle foram criadas para que pudéssemos estressar nosso código ao limite. Ter um código limpo, sem repetições e com testes bem feitos é essencial para o sucesso de um projeto, sem dúvida nenhuma. Mas o fato é que vivemos em um mundo imperfeito e o sonho de um software livre de bugs é um objetivo impossível de ser alcançado. O tempo, as pessoas e até a nossa amada tecnologia, tudo conspira contra nós. Então quando é a hora de parar e declarar o trabalho como finalizado?

A primeira coisa que precisamos ter em mente é que um projeto de software bem-sucedido não é necessariamente livre de bugs, mas sim um software que atende aos requisitos exigidos pelo seu cliente ou usuário. Isto não quer dizer que você deve jogar tudo para o alto e deixar seu código apodrecer. Mas que você deve considerar o quão importante é a ausência de falhas ou a qualidade do código para o seu cliente.

Se você estiver desenvolvendo um software que controlará algum equipamento médico ou uma aeronave ou estiver trabalhando em uma biblioteca open source que será amplamente utilizada, então você não tem escolha e suas opções serão mais limitadas. Porém, este tipo de projeto é uma exceção. Na maior parte do tempo estaremos trabalhando em produtos comerciais mais simples onde seu cliente terá um cronograma de entrega baseado em promessas feitas a seus superiores e sua empresa certamente terá um fluxo de caixa apertado.

Da mesma forma como seria pouco profissional aceitar prazos impossíveis e deixar testes de lado para terminar um projeto dentro do prazo, também não seria nada profissional ignorar as necessidades do seu cliente/usuário simplesmente para adicionar uma nova funcionalidade ou refatorar o código mais uma vez.

Depois de mais de dez anos trabalhando com software, posso dizer empiricamente que muitos usuários preferem usar um software com algumas arestas soltas do que esperar um ano por uma versão livre de falhas. Muitas vezes é melhor um software ótimo agora do que um software perfeito amanhã.

Ainda há uma outra vantagem nessa abordagem. De acordo com o livro Getting Real: “A coisa mais importante em desenvolvimento de software é motivação. Motivação é localizada—se você não está motivado pelo que está trabalhando neste instante, as chances de que isso não saia tão bom são grandes . Na verdade, isso provavelmente vai ficar ruim”. Ciclos de entregas longos e demorados são assassinos de motivação.

Se você dá algo para seus usuários brincarem no início, as suas reações muitas vezes levarão a uma solução melhor.

Programar é como pintar. Tudo começa com um quadro branco, seguido por um esboço, uma pintura maior e então com o preenchimento dos detalhes. Se seu olhar for critico demais, você não saberá quando parar até que tenha estragado a sua pintura.

Estarei novamente palestrando e assim como no ano passado o tema da minha palestra também terá uma forte relação com o trabalho que estou realizando no momento. Embora eu ainda não tenha divulgado isto publicamente, recentemente fui convidado para atuar como diretor de tecnologia em uma startup brasileira chamada SocialSmart.

A SocialSmart é uma empresa especializada no desenvolvimento de aplicativos para publicidade e branding em redes sociais. E quando o assunto é aplicativos sociais no Brasil, não podemos deixar de falar em Orkut e por sua vez em OpenSocial. Daí o tema da palestra introdutória que ministrei durante o Rails for Kids este ano: “Eu odeio OpenSocial”, onde mostrei algumas características desta plataforma que podem ser frustrantes para alguém que costumava ganhar a vida desenvolvendo projetos em Ruby on Rails.

Minhas primeiras semanas neste novo trabalho foram marcadas por prazos apertados, estresse e muitas noites sem dormir. Tudo isso graças a esta “maravilhosa” plataforma. Isto nos levou a conclusão de que a melhor estratégia seria desenvolver um framework que tornasse o nosso trabalho construindo estes aplicativos mais produtivo e divertido.

Atualmente estou trabalhando quase que em tempo integral no desenvolvimento deste framework.

Minha palestra no Rails Summit recebeu o título “Yet Another Ruby Framework – Como o Rails funciona por dentro”. Acredito que ao analisarmos juntos o funcionamento de algumas partes deste novo framework podemos entender com mais facilidade como o próprio Rails realiza algumas tarefas no seu núcleo. Além de uma visão geral sobre o processo de criação de um framework, também veremos através de uma analise do código como ocorre a inicialização de um projeto Web, como construir geradores de código e o que acontece por debaixo dos panos durante o processo de renderização de uma simples página HTML.

Infelizmente o tempo é muito curto para analisarmos cada passo da construção de um framework como o Rails em detalhes. Mas acredito que esta palestra lhe dará uma boa visão geral sobre este assunto, além de expor os motivos que levam uma pessoa como DHH a criar um framework como o Ruby on Rails.

E você, também vai estar lá?

Já ouviu a clássica pergunta “onde você se imagina daqui há 5 anos?” em uma entrevista de emprego?

Você quer detonar, naturalmente! Ou pelo menos se tornar o equivalente a uma estrela do rock em desenvolvimento de software. Este não é o tipo de pergunta onde se espera receber uma resposta séria – outra pergunta desta mesma categoria seria “qual é o seu maior defeito?”

Mas particularmente acho que este pergunta é um pouco diferente e merece ser seriamente considerada. Não para o benefício do entrevistador, mas para seu próprio benefício.

A pergunta “onde você se vê em cinco anos” já é uma espécie de clichê e a maioria das pessoas tem uma resposta na ponta da língua preparada para eventuais entrevistas. Mas esta pergunta levanta algumas preocupações mais profundas: qual é o caminho potencial para uma carreira de desenvolvedor de software? Claro, somos apaixonados pela nossa profissão e estamos muito felizes com isso. Mas você ainda estará sentado em frente a um computador programando quando estiver com 50 anos? Com 60 anos? Qual é o melhor resultado possível na carreira de um programador que aspira ser… bem, um programador?

E se eu lhe dissesse que há oito níveis de programadores?

8. Programador Imortal

Este é o nível mais alto. Seu código sobreviveu e transcendeu a sua morte. Você é uma parte do registro histórico permanente da computação. Outros programadores estudam o seu trabalho e as coisas que você escreveu. Você pode ter ganhado um Prêmio Turing, redigido trabalhos influentes ou inventado uma ou mais coisas fundamentais para a área de tecnologia que afetaram o curso da programação como a conhecemos. Você não apenas tem uma entrada na Wikipédia – mas há sites inteiros dedicados a estudar a sua vida e obra.

Muito programadores, embora tenham tentado, nunca atingiram esse nível.

Exemplos: Dijkstra, Knuth, Kay

7. Programador Bem-sucedido

Neste nível encontrasse programadores que além de serem muito conhecidos também criaram uma empresa – talvez até mesmo algumas empresas – em torno de seu código. Estes programadores conseguiram a verdadeira liberdade: a liberdade de decidir por si próprio em que querem trabalhar. E podem compartilhar esta liberdade com seus colegas programadores.

Este é o nível que a maioria dos programadores aspiram chegar. Chegar a este nível muitas vezes depende mais das habilidades em negócios do que em programação.

Exemplos: Gates, Carmack, DHH

6. Programador Famoso

Este também é um bom lugar para se estar, desde que você tenha um emprego.

Você é famoso nos círculos de programação. Mas ser famoso não significa necessariamente que você pode transformar isto em lucro e sustentar-se. Ser famoso é bom, mas bem-sucedido é melhor. Você provavelmente trabalha para uma grande e conhecida empresa de tecnologia, uma influente empresa de pequeno porte ou é membro de uma equipe em uma startup. De qualquer maneira, outros programadores já ouviram falar de você, e você está tendo um impacto positivo na área.

5. Programador Profissional

Você tem uma carreira bem sucedida como um desenvolvedor de software. Suas habilidades são valorizadas e você não tem muita dificuldade para encontrar um bom emprego. Seus colegas de trabalho o respeitam. Toda empresa na qual você já trabalhou se tornou melhor e foi enriquecida de alguma forma pela sua presença.

Mas onde você vai chegar?

4. Programador Mediano

Neste nível, você já é um programador bom o suficiente para perceber que você não é um grande programador. E você nunca poderia ser.

Talento na maioria das vezes tem pouco a ver com fazer sucesso. Você pode ser muito bem sucedido se tiver habilidades nos negócios e souber lidar com pessoas. Se você é um programador mediano, e ainda assim consegue sobreviver nesta área, então você é talentoso, mesmo que não necessariamente no ato de codificar.

Não se sinta mal com isto. Taleto é mais raro do que você imagina. Não há nada de errado com a falta de talento. Seja ousado. Descubra em que você é bom, e persiga isto. Seja agressivo.

3. Programador Amador

Um programador amador gosta de codificar e normalmente eles são estudantes promissores ou estagiários, talvez estejam contribuindo para projetos de código aberto, criando aplicativos “just for fun” ou desenhando web sites em seu tempo livre. Seu código e ideias demonstram entusiasmo e que eles tem um bom futuro pela frente.

Ser um amador é uma coisa boa; partindo deste nível pode-se subir rapidamente para se tornar um programador profissional.

2. Programador Desconhecido

É o típico programador comum. Apenas um recurso. Competente (na maioria das vezes), mas normal. Provavelmente trabalha para uma grande e anônima megacorporação. É apenas um funcionário, programar não faz parte da sua vida. Também não há nada de errado com isso.

1. Programador Ruim

Pessoas que de alguma maneira entraram na área de desenvolvimento de software sem um pingo de habilidade ou capacidade. Tudo o que tocam se transforma em dor e sofrimento para os seus colegas programadores – com a possível exceção de outros maus programadores, onde falta ainda a habilidade rudimentar obrigatória para perceberem que eles estão trabalhando com um outro programador ruim.

Esta é talvez, a marca registrada de todos os maus programadores. Essas pessoas simplesmente não possuem nenhuma habilidade para escreverem código, mas de alguma maneira é isto o que fazem.

Estes níveis não são totalmente sérios. Nem todos os programadores aspiram continuar fazendo isto por toda a sua carreira. Mas é esclarecedor considerar o que um programador poderia realizar em dez, vinte ou trinta anos – talvez mesmo uma vida inteira. Quais são os programadores notáveis que você mais admira? O que eles fizeram para merecer a sua admiração?

Em suma, o que você quer fazer com sua vida?

Depois de pesquisar um pouco encontrei a resposta, um método muito simples no Kernel do Ruby chamado caller que devolve um array com o call stack. O primeiro item do array é quem disparou o método atual. E cada elemento consecutivamente é aquele que disparou o método anterior na fila, e assim se segue até o final da pilha.

Este método pode ser muito útil quando se deseja descobrir a causa de uma exceção em um aplicativo. Veja um exemplo:

    1 def metodo_a
    2   puts caller
    3 end
    4
    5 def metodo_b
    6   metodo_a
    7 end
    8
    9 metodo_b
   10
   11 # => ["untitled:6:in `metodo_b'", "untitled:9"]

Conforme você pôde ver no exemplo acima, o primeiro item no array informa que o metodo_a foi disparado pelo metodo_b na linha 6 e que o metodo_b foi disparado na linha 9.

O string de retorno sempre seguirá o formato [arquivo]:[linha] ou [arquivo]:[linha]: in [método].

Foto de kstoon

Metodologias ágeis, desenvolvimento orientado a testes, integração contínua, programação em par ou qualquer outra prática que você utilize não irão evitar que vez ou outra você seja obrigado a parar tudo o que estiver fazendo e correr desesperadamente para “apagar um incêndio”.

Imprevistos, urgências e prazos apertados surgem o tempo todo e requerem nossa atenção imediata. Com o tempo acabamos nos tornando peritos em resolver este tipo de problema. Certa vez eu trabalhei com um DBA que era chamado de herói por todos os nossos colegas de trabalho, dado a sua grande capacidade em resolver problemas desta ordem tão rapidamente.

Durante muito tempo eu acreditei que todo programador deveria receber pelo correio um diploma de bombeiro honorário. E já que somos obrigados a conviver com esta realidade, por que não aprender com os bombeiros profissionais qual é o melhor procedimento a ser adotado durante um incêndio de verdade?

Hoje, graças a um constante trabalho de prevenção, equipamentos de última geração e homens bem treinados, os bombeiros profissionais conseguem vencer as chamas com cada vez mais velocidade e com o mínimo de danos. Muito diferente da nossa forma de atuação, ao se deparar com um incêndio esses homens conseguem manter a calma e seguir a risca cada um dos procedimentos necessários. No caso de uma emergência, ao chegarem no local, a primeira missão de um bombeiro é resgatar as pessoas que estão em perigo. A segunda coisa a se fazer é evitar a propagação das chamas para prédios ou casas vizinhas e então lutar para extinguir o fogo.

Após o incêndio ser controlado, ainda é necessário fazer uma busca por focos de fogo que podem estar escondidos em escombros e possíveis vitimas que ainda possam estar vivas. O trabalho não termina até que uma equipe especializada identifique as causas do incêndio.

Analisando estes procedimentos adotados pelos verdadeiros bombeiros, fica muito claro o motivo de não recebermos a nossa carteirinha de bombeiro honorário. Nós não somos profissionais. Quando surge uma emergência no trabalho costumamos ignorar todas as regras e procedimentos afim de resolver o problema o mais rápido possível. Não nos importando com vítimas ou com a estrutura do prédio (software).

Não importa a gravidade do problema ou o quão apertado é o prazo. Uma janela quebrada, um pedaço de código mal concebido ou uma decisão estratégica errada pode ser o começo do declínio para o seu software. Quando se está trabalhando em um software cheio de janelas quebradas é fácil desenvolver pensamentos como “este código é uma porcaria mesmo”. Simplesmente não importa se tudo estava indo bem até aquele momento.

Por outro lado, quando uma equipe zela pelo seu código e o mantém limpo, bem escrito e elegante, mesmo durante um incêndio (prazo apertado, um bug sério descoberto em produção ou uma data fixa de lançamento) nenhum desenvolvedor desejará ser o primeiro a estragar tudo. Manter a cabeça fria e seguir o procedimento é a diferença entre amadores e profissionais.

Uncle Bob na RailsConf 09 – Profissionalismo from Fabio Akita on Vimeo.

Foto de kathleen.bradley

A segunda lei da termodinâmica, em principio, afirma que em um sistema fechado a desordem não pode ser reduzida, no máximo pode se manter inalterada ou pode ser aumentada. Esta lei também parece vigorar quando o assunto é desenvolvimento de software.

Quando alteramos o código já existente de um sistema, a desordem sempre aumenta. O nome dado a este efeito é “entropia de software”. Entropia é um termo da física que se refere à quantidade de “desordem” em um sistema e embora desenvolvimento de software seja imune a quase todas as leis da física, a entropia nos pega de jeito.

Se um sistema é muito utilizado então eventualmente ele será alterado. E ao adicionar novas funcionalidades a um software, também estamos aumentando a sua complexidade e desordem. Softwares muito complexos e desorganizados são identificados por programadores por seu código em processo de deterioração, basicamente um código podre.

Um dos motivos que parece contribuir muito com esta deterioração no software é o fator psicológico. Há quase dois anos atrás escrevi sobre a “teoria da janela quebrada”. Não pretendo me repetir aqui, então se você não sabe do que estou falando, sugiro dar uma pausa e reler este artigo primeiro.

Uma única janela quebrada pode ser o suficiente para criar uma sensação de abandono que normalmente leva a uma segunda janela quebrada. Assim, em um espaço de tempo relativamente curto, temos um prédio deteriorado e com danos estruturais graves. E aquela sensação de abandono se torna então uma realidade.

A “teoria da janela quebrada” inspirou a polícia de Nova York e de outras grandes cidades a reprimir pequenos delitos, a fim de manter as coisas em ordem. E funcionou! Consertar rapidamente os vidros quebrados, limpar as pichações e atacar outras pequenas infrações reduziu consideravelmente o nível de criminalidade.

Esta teoria ajuda a explicar por que alguns projetos muito bem planejados e com uma excelente equipe ainda podem experimentar o fracasso. Enquanto projetos, que enfrentam enormes dificuldades e retrocessos, conseguem combater com sucesso a tendência natural para a desordem e sair-se bem.

Não deixe “janelas quebradas” em seu código. Conserte cada uma delas assim que forem descobertas. Se não houver tempo suficiente para corrigir um problema da forma correta, então use um remendo. Talvez comentando um código ruim ou exibindo uma mensagem “não implementado”. O mais importante é tomar medidas para evitar mais danos e mostrar que você está em cima da situação.

O segredo para manter um código saudável é agir rápido. A negligencia acelera o apodrecimento do software. Programar é uma corrida contra a entropia!