Mais que bom código

Programe menos

2011-10-04T07:42:00.000-03:00

Muito se fala sobre a necessidade de treino, muito treino, para alguém se tornar um bom programador. Apóio totalmente essa ideia. Mas, nesse artigo, gostaria de chamar a atenção para uma habilidade que poucos bons programadores chegam a adquirir: a habilidade de não precisar programar. Não, não estou me referindo a "habilidade" que alguns tem de se esquivar do seu trabalho. Estou falando sobre realizar um trabalho de qualidade, mas usando pouco ou nada do seu próprio código.

Quando aprendemos a escrever código

No começo, tudo é uma beleza. Com algum material de estudo e pouco tempo de prática, podemos ver nosso primeiro Hello World! funcionando, seja qual for a linguagem. Nesse ponto, não há a pressão das boas práticas ou da economia de recursos; precisamos apenas descobrir como fazer as coisas funcionar. Qualquer um que passa algum tempo nessa fase aprende a programar, ainda que não possa ser considerado um bom programador.

Quando aprendemos a deletar código

Passada a fase inicial de aprendizado, descobrimos que há algumas boas práticas que nos ajudam a criar programas mais estáveis e fáceis de manter. É a fase em que aprendemos a deletar código. Pegar um código grande e complexo e torná-lo mais simples e eficiente é fonte de grande orgulho e prazer para muitos programadores. Com algum tempo praticando essa "arte", aprendemos quais códigos valem o esforço de refatoração e como executá-la de maneira responsável, sem quebrar a estabilidade do software. Muitas dessas refatorações dão origem a bibliotecas que podem ser reaproveitadas em outros projetos, gerando uma grande substituição de código ruim e duplicado por código mais eficiente e estável. Que maravilha, hein? Só não é melhor porque a maioria dos bons programadores estaciona aqui.

Quando aprendemos a não escrever código

Muitos programadores se tornam tão bons na codificação que acreditam que seu código é a melhor forma de resolver todo tipo de problema. Isso não seria ruim se não fossem pequenos detalhes:

Tempo é um recurso caro;
Todo código novo é propenso a bugs e leva tempo para que se torne estável e confiável;
Existem inúmeras bibliotecas, componentes e frameworks de qualidade que resolvem uma infindável quantidade de problemas;
Nem todo problema se resolve com código.

Esses pontos óbvios são frequentemente ignorados por causa de uma cultura existente em muitas empresas e indivíduos: a cultura do Not Invented Here (Não Inventado Aqui).

"Not Invented Here (HIH) é um termo usado para descrever uma cultura social, corporativa ou institucional em que se evita o uso ou compra de produtos, pesquisas, padrões ou conhecimento existentes por causa da sua origem externa." (Wikipedia)

As razões para se preferir escrever seu próprio código podem incluir o medo de não entender as soluções de terceiros ou a indisposição de valorizar o trabalho de outros. Seja qual for o motivo, reinventar a roda raramente é a melhor alternativa.

Há uma história interessante que posso contar sobre isso. Muitos anos atrás, uma empresa onde trabalhei precisava tornar seus aplicativos desktop capazes de serem atualizados automaticamente. Desenvolveu-se então um aplicativo que, integrado aos aplicativos que seriam atualizados, cuidaria da verificação da existência de uma nova versão, do download e da instalação dela. O aplicativo era bem sofisticado para a época, podendo até continuar um download interrompido, se necessário. Seu desenvolvimento ocupou alguns meses de trabalho contínuo de um desenvolvedor e levou mais de um ano até que a primeira versão fosse testada em um cliente real. No primeiro teste real, bam! O cliente usava um proxy de internet com um protocolo de autenticação que não havia sido previsto. O desenvolvedor dessa solução não estava mais na empresa e o problema caiu no meu colo.

Ao pesquisar uma solução pronta que resolvesse essa questão da autenticação, descobri uma biblioteca que não apenas poderia cuidar desse problema específico, mas também poderia substituir praticamente todo o trabalho do aplicativo de atualização! Então, propus "jogar fora" o trabalho realizado até aquele momento e substituí-lo por um novo projeto baseado numa biblioteca de terceiros. Para encurtar a história, em dois dias eu tinha um protótipo funcional da nova solução e, em duas semanas, sua versão funcional. Até onde sei, essa solução, que ocupou uma pequena fração do tempo de desenvolvimento da primeira, usando uma biblioteca de terceiros, atualiza milhares de aplicativos até hoje.

Quanto dessa solução foi resolvida com meu código? Talvez cinco ou dez por cento. O código principal não era meu e não tenho receio algum de admitir isso. Tive sucesso graças ao trabalho de outros desenvolvedores que tornaram sua solução disponível a terceiros. Se essa abordagem tivesse sido utilizada originalmente, teria-se poupado muito tempo e dinheiro.

Qual a lição aprendida aqui? Não defendo que você utilize uma biblioteca, componente ou framework de terceiros para resolver todo tipo de problema. Da mesma forma, não defendo que faça o contrário, usando seu próprio código para resolver todo tipo de problema. A grande lição é:

Aprenda a escrever bom código e faça isso quando necessário; mas aprenda também a escrever pouco ou nenhum código, quando está a sua disposição uma solução adequada, confiável e pronta para o uso.

Pra fechar, segue a tradução do tweet que me serviu de inspiração para escrever esse artigo:

"O código que você escreve te torna um programador. O código que você deleta te torna um bom programador. O código que você não tem que escrever te torna um grande programador". (Mario Fusco)

Que achou desse artigo? Já teve alguma experiência relacionada? Deixe seu comentário.

—

Créditos pela foto do bicho-preguiça a Guilherme Jófili.

[off-topic] Mudanças profissionais e novo blog

2011-08-30T07:30:00.007-03:00

No final de 2009 comecei a prestar muita atenção na área de desenvolvimento de software para dispositivos móveis. Me pareceu um mercado muito promissor, então comecei a estudar um pouco de desenvolvimento para iPhone (não havia iPad ainda). Em pouco tempo, comecei a dar uma olhada também no Android. Minha experiência com C me ajudou a tolerar um pouco da esquisitice do Objective-C. E minha experiência com Java, tornou as coisas bem fáceis ao estudar o SDK do Android.

Logo, comecei a olhar também algumas alternativas que me permitissem desenvolver ao mesmo tempo para iOS (como veio a se chamar o antigo iPhone OS) e para Android. O Android estava crescendo muito e me parecia razoável investir nas duas plataformas. Então, fui apresentado ao Appcelerator Titanium Mobile, ainda nos seus estágios iniciais. O Titanium permite criar apps nativas para iOS e Android usando uma única base de código, em JavaScript. Codificar em JavaScript me pareceu muito melhor do que usar ObjC ou Java. E a ideia de não precisar escrever dois aplicativos para ter um pé em cada plataforma, foi um ótimo argumento para estudar esse tal de Titanium.

No final do ano passado, abri mão de um emprego de muitos anos para aproveitar uma oportunidade na área de desenvolvimento para dispositivos móveis. E o Titanium é atualmente a ferramenta que mais uso dentre as que estão as minha "maleta".

Por ser uma ferramenta ainda pouco conhecida no Brasil, tive o prazer de criar o primeiro grupo de discussão brasileiro focado em Titanium Mobile. Agora, já com alguma bagagem de Titanium, tenho o prazer de lhes apresentar o Mais que Titanium, o primeiro blog nacional focado no desenvolvimento de aplicativos móveis usando a plataforma Titanium Mobile. Dê uma olhada nele e, se você gostar, aguarde os próximos artigos que publicarei por lá.

Se você gosta do "Mais que bom código", não se preocupe, ele continuará vivo e com o mesmo perfil. Artigos que não tratarem de tecnologias ou nichos específicos continuarão sendo publicados aqui. Já os artigos que tratarem da área mobile, serão publicados no Mais que Titanium.

Um abraço a todos os leitores e até o próximo artigo (aqui ou lá)!

—

Créditos pela foto a Zig Koch do Natureza Brasileira.

Foque nos usuários, não nas funcionalidades

2011-06-27T16:45:00.049-03:00

Num passado não muito distante, um certo nicho de mercado precisou atender a uma exigência do seu órgão regulador: determinadas guias que eram preenchidas à mão precisariam passar a ser preenchidas no computador, para que fossem enviadas eletronicamente a seus destinatários. Os gestores da empresa de TI onde eu trabalhava viram nessa exigência uma oportunidade. Então, junto com uma equipe, fui encarregado de desenvolver um software que permitisse àquelas empresas atenderem a sua nova necessidade. Havia alguns concorrentes e o nosso software precisava, de alguma forma, se destacar entre eles. O resultado foi atingido e o software foi um sucesso! O que fizemos? *

Avaliação dos concorrentes

Não tenho receio algum de admitir que avaliamos as soluções de vários concorrentes. Tivemos que comprar algumas delas, inclusive. Nessa avaliação, percebemos que as soluções existentes focalizavam sempre a mesma coisa: as funcionalidades. Elas atendiam ao que era imprescindível, mas não faziam isso de forma eficaz. Os softwares concorrentes eram complicados e, em muitos casos, preencher as guias nesses softwares chegava a ser mais demorado do que fazer isso em papel.

Foco nos usuários

Não havia espaço para inventarmos funcionalidades como diferencial. O que tinha que ser feito estava claro: receber do usuário os dados das guias, permitir sua impressão e exportá-las para um formato específico. Qualquer funcionalidade adicional seria, perdão pelo termo, encheção de linguiça. O que tínhamos que fazer para que nosso software se destacasse era simples: proporcionar ao usuário a melhor experiência de uso possível.

Como 99% do tempo de uso do software era o preenchimento de guias (que chegavam a ter mais de 100 campos e, em alguns casos, somavam milhares de unidades ao mês), nosso maior esforço tinha que ser concentrado nelas. Os recursos que implementamos provavelmente não vão te surpreender, mas surpreenderam os usuários. Os principais foram:

Os formulários de preenchimento das guias tinham leiaute tão próximo quanto possível das guias em papel (o que facilitou muito a transição papel->computador);
O preenchimento de diversos campos era deduzido pelo programa sempre que possível;
As validações necessárias eram feitas campo-a-campo e não eram obstrusivas (nada de "preencha esse campo antes de passar para o próximo");
Era permitido salvar uma guia incompleta ou inválida e terminar ou corrigi-la mais tarde;
Era sugerido salvar uma guia como "modelo" e preencher novas guias a partir desse modelo;

Nada de mais, certo? Pois é. Mas com esses recursos "nada de mais", preencher guias no nosso software chegava a ser até 20 vezes mais rápido do que fazer isso no papel! Isso era muito, muito mais do que qualquer concorrente havia conseguido. Será que éramos gênios? Não, apenas focamos nos usuários.

Os interesses de quem paga

Focar nos usuários nos ajudou a compreender o que tornaria seu trabalho mais fácil e produtivo. Mas isso seria insignificante se os interesses de quem de fato pagaria pelo software não fossem atingidos. Como a facilidade de uso aumentava a produtividade, tivemos um excelente argumento de venda. Afinal, produtividade é economia de tempo e tempo, é dinheiro.

No mundo corporativo, os softwares adotados nem sempre são escolhidos com base no que os seus futuros usuários pensam sobre ele. Por isso, é preciso estar ciente de que o foco nos usuários é importante, mas deve ser feito de forma a atender aos interesses de quem paga.

Apaixonando os usuários

Outra coisa muito positiva que conseguimos por focar nos usuários, foi a propaganda gerada por eles, o popular boca-a-boca. Como seu trabalho se tornou muito mais fácil, por conta própria, eles recomendavam nosso software para seus conhecidos em outras empresas. Esses, por sua vez, recomendavam nosso software para seus gestores.

Você quer que seus usuários façam propaganda gratuita do seu software? Apaixone-os pelo seu software.

Mas as funcionalidades também são importantes!

Sim, claro, as funcionalidades são importantes. Mas existem as funcionalidades imprescindíveis e as dispensáveis. Partindo do princípio que você sempre vai atender as necessidades imprescindíveis dos seus usuários, valorize menos as funcionalidades que só servem para encher linguiça e foque em proporcionar aos seus usuários uma melhor experiência ao usar seu software.

O que achou desse artigo? Deixe seu comentário.

—

* ^ Destaquei nesse artigo apenas questões diretamente relacionadas a software, mas tenha em mente que aspectos comerciais e de marketing também estiveram envolvidos.

Para saber mais sobre User experience (Experiência do usuário) aplicada a Web, veja o livro The Elements of User Experience de Jesse James Garret ou veja o diagrama que deu origem ao livro.

Invista em conhecimento

2011-05-23T12:41:00.005-03:00

Todo mundo sabe que mil reais hoje compram menos do que seria possível um ano atrás. Isso acontece por causa da inflação. Para fazer o dinheiro não perder seu valor é preciso investi-lo.

Conhecimento é como dinheiro. Seu valor também diminui com o passar do tempo. E quando se trata de tecnologia, a “inflação” é ainda maior, fazendo com que qualquer conhecimento tecnológico que se possua hoje perca drasticamente o seu valor em alguns anos. Se você não quer se tornar intelectualmente pobre, precisa colocar seu cérebro para trabalhar. Em outras palavras, precisa investir em conhecimento.

Adquira o hábito de investir

Muitas pessoas só investem quando aparece um dinheiro extra. Similarmente, muitos programadores só aprendem algo novo quando o que já sabem está obsoleto. Em ambos os casos, o investimento, de qualquer forma, é válido. Mas, melhor que investimentos grandes e esporádicos são os investimentos pequenos e regulares. Faça do investimento em conhecimento um hábito.

Não ponha todos os ovos no mesmo cesto

Salvo raras exceções^[1], os investidores concordam com a bem conhecida frase acima. O motivo é simples: se todos os ovos estiverem no mesmo cesto e algo muito ruim acontecer ao cesto, todos os ovos serão perdidos. Essa é uma forma simples de ensinar a importância da diversificação.

Com o conhecimento tecnológico não é diferente. Seus maravilhosos conhecimentos na tecnologia que paga seu salário hoje – lamento dizer – um dia serão desprezados pela maior parte do mercado. Investir todas as suas energias nessa única tecnologia é como colocar todos os ovos num mesmo cesto.

Para diminuir seus riscos, diversifique. Aprenda os pontos positivos e negativos da tecnologia que você usa atualmente, mas não pare por aí. Aprenda novas tecnologias. Quanto maior o número de tecnologias com as quais você for capaz de trabalhar, melhores serão as suas chances de se adaptar às rápidas mudanças que acontecem na nossa área.

Não evite o risco, administre-o

Se você investir apenas em poupança, seus riscos de perder dinheiro serão pequenos. Porém, basicamente, você apenas manterá o poder aquisitivo do capital aplicado. Por outro lado, se você investir apenas em ações de small caps (empresas de menor porte), as possibilidades de alto lucro serão grandes, mas as de perda total também.

Com um pouco de bom senso, percebe-se que nenhum dos dois extremos é só bom ou só ruim. É aí que entra a administração do risco. Muitos investidores dividem seus investimentos entre os de risco pequeno, moderado e alto. Se os investimentos de alto risco perderem completamente seu valor, o investidor não estará falido. Se, por outro lado, eles dobrarem ou triplicarem de valor, o investidor terá um bom lucro, ainda que não fique rico por isso. Riscos não são ruins, desde que sejam controlados.

De forma similar, podemos dizer que as tecnologias atualmente populares e com significativa demanda de oportunidades de trabalho são os investimentos conservadores enquanto as tecnologias emergentes, mas com bom potencial de crescimento são os investimento arriscados. Não é preciso escolher apenas uma das alternativas para investir; é possível investir em ambas, correndo riscos controlados, sem colocar todos os ovos no mesmo cesto.

Compre na baixa, venda na alta

Pouco depois de a crise financeira estourar nos EUA em 2008, cogitei a possibilidade de comprar ações de uma small cap que havia ficado em sérias dificuldades financeiras. O valor de cada ação estava menos de R$0,10. Era um investimento de alto risco, visto que a empresa poderia falir em pouco tempo. Mas o potencial de ganho era grande, desde que os rumores de que um grande grupo compraria essa empresa e a resgataria da ruína financeira se concretizassem. Bem, eu não quis correr o risco de perder dinheiro algum com essa ação. E fiz mal. No início de 2010 cada ação dessa mesma empresa valia mais de R$25! Se eu tivesse usado mil reais para comprar ações dessa empresa quando elas valiam R$0,10 e tivesse vendido essas mesmas ações quando elas valiam R$25, os mil reais teriam se transformado em nada menos que duzentos e cinquenta mil reais! Essa história me ensinou a importância de comprar na baixa e vender na alta.

Quando se trata de tecnologia, acontece algo muito parecido. Aprender uma tecnologia antes que ela se torne popular é arriscado. Pode ser que nunca surja demanda para “vender” o conhecimento obtido. Por outro lado, se essa nova tecnologia se tornar muito popular e houver poucos profissionais aptos para utilizá-la, esses poucos profissionais serão muito bem pagos para “vender” seu conhecimento.

Ajuste seus investimentos

O mercado financeiro é muito dinâmico. Atentados terroristas, guerras ou mudanças de governo - para citar apenas alguns fatores - geram movimentos bruscos de alta e baixa. Por isso, os investidores precisam estar sempre atentos. Eles podem até se apegar ao seu capital, mas nunca à forma como ele é investido. Nesse mercado, é preciso ser capaz de abrir mão de um investimento que deixou de ser promissor para aplicar em outro com melhores perspectivas.

Não é diferente na área de tecnologia. Tecnologias nascem e morrem o tempo todo. Outras ficam eternamente moribundas. Não se pode contar com a sorte de ter escolhido uma ou outra tecnologia com um futuro promissor. É preciso estar sempre atento às mudanças no mercado e às consequentes oportunidades que surgem. Se a tecnologia com a qual você trabalha hoje está a cada ano menos solicitada pelo mercado, não reze para o barco não afundar, pule. E se um novo mercado ou uma nova tecnologia tem se mostrado cada vez mais promissor, o que você está esperando para colocar pelo menos um pé nele?

Agora, gostaria de saber de você: em que você está investindo?

—

Referências:

[1] ^ Max Gunther. "Os axiomas de Zurique". Resenha disponível aqui.
Andrew Hunt and David Thomas. "The Pragmatic Programmer: From Journeyman to Master". Versão em português aqui.

Como identificar bons programadores

2011-04-30T02:29:00.006-03:00

Gerente de circo: Você faz malabarismo há quanto tempo?

Candidato: Humm, há cerca de seis anos.

Gerente de circo: Você faz malabarismo com três, quatro e cinco bolas?

Candidato: Sim, sim e sim.

Gerente de circo: Sabe lidar com objetos chamejantes?

Candidato: Claro.

Gerente de circo: ...facas, machados, caixas de charuto abertas e chapéus?

Candidato: Faço malabarismo com qualquer coisa.

Gerente de circo: Você faz o público rir durante o malabarismo?

Candidato: Sim, sou hilário.

Gerente de circo: Gostei de você. Está contratado!

Candidato: Mas... você não quer me ver fazendo malabarismo?

Gerente de circo: Caramba, nunca pensei nisso.

(Peopleware. “Hiring a Juggler”)

Qualquer um consideraria insano contratar um malabarista sem antes vê-lo demonstrando suas habilidades. É uma questão de bom senso. Mas é impressionante como esse bom senso é simplesmente ignorado por muitas empresas ao contratar programadores. Elas se limitam a ler currículos e fazer entrevistas que talvez avaliem um monte de coisas, menos se os candidatos têm talento pra fazer software.

Se você quer contratar bons programadores, precisa saber como identificá-los. Não tenho um passo-a-passo para lhe oferecer, mas algumas lições que aprendi durante alguns anos de observação e execução dessa tarefa podem lhe ser de ajuda.

Quem pode identificá-los?

Identificar um bom programador é similar a identificar um bom malabarista: é preciso vê-lo demonstrar suas habilidades. Mas há uma diferença sutil: alguém que nunca fez malabarismo, pode identificar um bom malabarista; mas alguém que nunca fez software, dificilmente poderá identificar um bom desenvolvedor de software. Existe um abismo que separa software de bom software e só quem compreende a profundidade desse abismo pode identificar aqueles capazes de criar bom software.

Portanto, se você não sabe programar, encare a realidade: sozinho, você não pode recrutar programadores. É claro que pessoas não técnicas podem (e devem) contribuir para o processo seletivo. Psicólogos, por exemplo, tem muito mais chances de identificar um candidato insubordinado, com dificuldades de relacionamento ou até um psicopata do que nós, técnicos. Minha intenção não é desmerecer o trabalho de ninguém, mas deixar claro o que cabe a cada um. E identificar bons programadores, do ponto de vista técnico, cabe a bons programadores.

Qual o contexto?

Se alguém me disser: “Preciso de um bom programador, você tem alguém pra indicar?”. Minha resposta será: “Depende, o que ele fará?”. O fato de alguém ser um bom programador não quer dizer que ele é adequado para todos os tipos de trabalho que envolvem criação de software. Num extremo há os trabalhos que exigem um perfil mais generalista, no outro os que exigem um perfil altamente especialista. No meio está a maioria, onde se exige um misto desses dois perfis. Essa e outras peculiaridades do trabalho formam o que chamo de contexto.

Se você já programou por algum tempo e conheceu vários outros programadores, sabe que não se pode dizer que fulano é melhor que beltrano e ponto final. Lembre-se: programadores são pessoas, não mercadorias. As habilidades de duas pessoas não podem ser comparadas como se mede altura delas (ambos têm a mesma altura ou um é maior e outro menor). A comparação deve ser feita mais ou menos como se comparam dois gráficos de barras. Em algumas barras (habilidades), um candidato pode parecer melhor que outro, em outras, equivalente ou pior. O contexto ajuda o recrutador a descobrir que “barras” do gráfico são mais relevantes para o processo seletivo em questão.

As ferramentas

A seguir, algumas das ferramentas que já utilizei para identificar bons programadores.

O bom e velho currículo

O currículo ainda faz parte da primeira etapa de avaliação de candidatos na maioria das empresas. Não tenho nada contra eles, desde que não sejam supervalorizados. Eles são ótimos para demonstrar habilidades de redação e marketing, mas ineficientes para demonstrar se alguém tem talento para fazer software. Seja como for, há algumas informações pelas quais tenho interesse especial ao ler currículos:

Primeiras experiências: Se as primeiras experiências do candidato aconteceram quando ele ainda era bem jovem, possivelmente se trata de alguém autodidata. Pontos adicionais são somados se essas experiências estiverem relacionadas a trabalhos autônomos, feitos para si mesmo ou para outros.
Raridade de conhecimento: Apesar de o conhecimento diretamente ligado ao trabalho que será executado ter sua importância, gosto de ver que o candidato tem conhecimentos técnicos não muito solicitados pelo mercado. Não tanto pela utilidade direta desse conhecimento, mas pelo que ele representa. Investir tempo em aprender algo que não trará um retorno imediato geralmente revela um candidato apaixonado pelo que faz, além de interessado em se aperfeiçoar e não apenas em ter um bom emprego. Ademais, certos conhecimentos abrem a mente para novas formas de resolver problemas.
Trabalhos notáveis: A realização de trabalhos com grau de dificuldade elevado, não convencionais, inovadores ou de grande responsabilidade são algumas das coisas que tornam a experiência de um candidato algo notável. Programadores talentosos, muitas vezes atraem para si esse tipo de trabalho.

Apesar de muitas vezes ficar bem impressionado e curioso para conhecer alguns candidatos por causa dos seus currículos, é preciso reconhecer que com uma leitura de currículo, podemos apenas descobrir que um candidato não serve para a vaga. Será preciso muito mais que isso para descobrir se ele serve.

Mapeamento de conhecimento

Essa é uma ferramenta que utilizo após avaliar um currículo favoravelmente. Se trata de um formulário onde o candidato autoavalia e comenta seus conhecimentos e/ou experiência em uma série de itens relacionados ao desenvolvimento de software, mas não exclusivamente nos quesitos mais relevantes para a vaga em questão.

Um exemplo que criei apenas para usar neste artigo pode ser visto aqui.

O resultado desse formulário é, geralmente, muito mais revelador que o currículo. Por ser menos formal e ao mesmo tempo mais técnico, os bons candidatos tentem a se sentir mais à vontade para escrever sobre suas habilidades. Ao mesmo tempo, candidatos que “enrolaram” no currículo vão se “enrolar” na hora de dar detalhes sobre seus conhecimentos.

De posse do currículo e do mapeamento de conhecimento preenchido, tenho uma impressão melhor do perfil do candidato. Mentalmente, é como se eu formasse um gráfico com os pontos fortes e fracos do candidato. Se o gráfico parecer adequado ao contexto, levo o candidato para a próxima etapa: a entrevista por telefone.

Entrevista por telefone

A entrevista por telefone não substitui a entrevista presencial, apenas provê um meio mais rápido de conhecer e avaliar os candidatos. Joel Spolsky cita uma das vantagens da entrevista por telefone ao dizer:

"Visto que na entrevista por telefone você não vê o candidato, é fácil se concentrar na qualidade do que ele diz ao invés de em fatores externos e irrelevantes para o trabalho." ^[1]

Após uma curta introdução onde faço breves e sinceros elogios com base no que li no currículo e no mapeamento de conhecimento, procuro conhecer melhor o candidato a partir de três pontos principais:

Como ele começou a programar: Peço que o candidato me conte um pouco sobre como se interessou pelo desenvolvimento de software e quais foram as suas primeiras experiências com programação. A resposta de um candidato apaixonado normalmente é carregada de entusiasmo. Eles têm orgulho de falar das suas “façanhas” como aspirantes programadores. Ao mesmo tempo que a resposta do candidato alivia a sua tensão inicial, características importantes como paixão e autodidatismo ficam mais evidentes pelo que ele diz.
Trabalhos que mais gostou: Uma pergunta chave que faço é: de todos os projetos em que você esteve envolvido, em quais mais gostou de trabalhar? Um candidato apaixonado, citará sem muita demora os projetos mais desafiadores. Peço detalhes sobre cada um desses os projetos. Quero saber quais foram as responsabilidades dele, que desafios enfrentou, como os resolveu, por que resolveu daquela maneira, se propôs mudanças, se enfrentou resistência e que tecnologias estavam envolvidas. Vou fundo nessas questões para descobrir se ele realmente sabe do que está falando.
Como ele resolve problemas que nunca viu antes: Se você precisa selecionar programadores que não resolverão sempre os mesmos problemas, é bom avaliar a capacidade de lidarem com problemas nunca antes vistos. Para isso, descrevo brevemente alguns problemas e peço que o candidato me diga como os resolveria. Propositalmente não forneço muitas informações para descobrir se o candidato sabe fazer as perguntas certas para obter mais informações. A solução para esses problemas deve revelar conhecimentos que vão além de escrever código. O nível de dificuldade dos problemas e o que será considerado como uma solução viável varia de acordo com o nível do programador que se deseja contratar. A seguir, alguns exemplos que já usei:

Como você implementaria um programa para ordenar um arquivo texto de 10GB?
Como você implementaria um programa para controlar os elevadores de um prédio?
Como você implementaria uma engine de renderização para um browser?
Como você implementaria uma timeline como a do Twitter?

Se o candidato não consegue nem mesmo formular perguntas para entender melhor o problema ou diz que não faz ideia de como resolvê-lo, muito provavelmente ele terá dificuldade para resolver problemas diferentes dos que está acostumado a resolver.

Nesse ponto, já tenho dados suficientes para decidir se gostaria ou não de conversar pessoalmente com o candidato.

O que a internet diz sobre ele?

Se o candidato tem um blog sobre algum assunto ligado ao desenvolvimento de software, leia o que ele escreve e descubra suas opiniões. Se ele participa de grupos de discussão ou comenta em blogs, veja como ele interage com outros. Ele é ferrenho defensor de uma tecnologia específica? Mal sinal. Ele tem uma postura agnóstica sobre tecnologias? Ótimo, isso revela maturidade técnica. Nenhum programador é obrigado a ter uma conta no Twitter, mas se ele tem uma e a utiliza para compartilhar links interessantes, isso é uma boa forma de descobrir o que ele lê. Se o candidato compartilha projetos no Github, ótimo. É uma forma de avaliar a qualidade do seu código. Se ele possui forks de outros projetos, isso mostra que projetos o interessam.

Miniprojeto

Ao avaliar novatos em programação, gosto de pedir que executem em casa miniprojetos de software. Algo que dê pra fazer em um fim de semana. Não devem ser projetos muito simples e nem excessivamente complexos. O objetivo final deve ser claro, mas a forma como ele será atingido deve ficar em aberto. Eventuais dúvidas devem poder ser esclarecidas por e-mail ou telefone. Quando o candidato considerar a solução terminada, deve enviá-la por e-mail. Isso dá ao avaliador a oportunidade de verificar a qualidade do código do candidato. A forma como o problema foi resolvido deve ser discutida e eventuais ajustes podem ser solicitados. O objetivo não deve ser que o candidato entregue uma solução perfeita, mas uma que funcione bem ao fim de algumas iterações. Os resultados que tive com esse tipo de ferramenta ao avaliar candidatos a estágio ou profissionais juniores foram excelentes.

Entrevista presencial

Essa é a etapa que considero mais importante no processo seletivo. Os que chegam até ela, até certo ponto, já conquistaram minha admiração e normalmente estou ansioso para conhecê-los.

Uma boa entrevista deve se parecer com uma conversa. A meta do entrevistador deve ser criar situações onde o candidato possa mostrar o seu potencial. Procuro fazer isso de duas maneiras.

Detalhes sobre projetos realizados: Solicito mais detalhes sobre projetos citados na entrevista por telefone. Algo como: estive pensando naquele projeto que você executou na empresa X. Como funcionava a parte de...? Ou, por que você implementou usando...? Você teve problemas com...? Que achou de usar...? Preferia ter usado outra linguagem/tecnologia? Chegou a sugerir isso? Deixe-o à vontade para responder observe se ele demonstra que tinha genuíno interesse pelo que estava fazendo. Programadores apaixonados não fazem um bom trabalho porque são pagos para isso, o fazem porque têm prazer nisso. São essas pessoas que você deve procurar. Procure pelo brilho nos seus olhos.

Ao mesmo tempo, essa conversa mais detalhada permitirá que ele demonstre a variedade e nível do seu conhecimento técnico, que deverá estar alinhado com o que foi informado no mapeamento de conhecimento.
Me mostre o código: Como diria Linus Torvalds: “Show me the code”^[2]. Nessa parte final, me certifico de que o candidato sabe não apenas falar sobre programação, mas também sabe praticá-la. Para isso, uso um quadro, papel e lápis ou um computador com um editor de texto simples (não é necessário compilador) e peço que o candidato resolva alguns problemas simples de programação na sua linguagem predileta. Os problemas podem ser algo como:
- Crie uma função que receba uma string e retorne uma cópia dela com o primeiro caracter em maiúsculo;
- Crie uma função que receba um array e inverta a ordem dos seus elementos;
- Crie uma função que retorne a quantidade de arquivos existentes num diretório (incluindo seus subdiretórios).
O primeiro problema é realmente muito fácil e espera-se que todos sejam capazes de resolvê-lo em poucos segundos. O segundo, dependendo da linguagem, envolve algum conhecimento sobre ponteiros e o terceiro sobre recursão. O código de cada solução dará margem para alguma pergunta ou sugestão e isso deve ser explorado pelo avaliador para que o candidato se mostre capaz de explicar o que fez. Considerações de performance e consumo de memória podem ser levantadas. O candidato deve ter a chance de melhorar seu algoritmo, se assim desejar. Essa troca de ideias ajuda o avaliador e perceber como o candidato raciocina e como reage ao receber uma crítica construtiva sobre seu código. Apenas lembre de esperar até que o candidato diga que terminou uma solução, antes de falar qualquer coisa. O tempo que ele levar para resolver cada problema e a quantidade (ou ausência) de bugs também são fatores de avaliação.

Considerações finais

Se você está em busca de bons profissionais, lembre-se de duas coisas: (1) eles são a exceção e (2) sua empresa não é a única opção deles. Lembrar disso o ajudará a tratar seus candidatos com respeito, desde o primeiro contato. Isso vai desde a forma como você responde aos e-mails, passando pela flexibilidade de horários das entrevistas e indo até a sua pontualidade ao recebê-lo para uma entrevista presencial. Trate os candidatos como você gostaria de ser tratado, sempre.

O que você acha da forma como as empresas tentam identificar bons programadores? Tem alguma experiência para contar? Algo a dizer sobre esse artigo? Deixe seu comentário!

—

Foto: Vladik Myagkostupov no show 'Dralion' do Cirque Du Soleil. Créditos a Sandra Mu/Getty Images AsiaPac.

Referências:

[1] ^ Joel Spolsky. "Smart and Get Things Done"
[2] ^ Linus Torvalds. "Talk is cheap. Show me the code"

Como atrair bons programadores

2011-01-18T15:25:00.005-02:00

Na década de 80, milhares de bravos garimpeiros foram atraídos ao lugar que se tornou o maior garimpo a céu aberto do mundo - a Serra Pelada. O motivo? A descoberta que o solo desse local possuía uma enorme quantidade de ouro.

Garimpeiros sabem que não adianta procurar ouro a esmo. É preciso saber onde há uma grande concentração do metal para então empreender o garimpo. E o garimpo envolve vasculhar grandes quantidades de terra, areia e pedras sem valor, para encontrar uma quantidade proporcionalmente ínfima do metal precioso.

Procurar bons programadores, de certa forma, é como procurar ouro. É preciso saber onde procurar por eles e muita disposição para garimpá-los. A diferença é que, quando se trata de pessoas, elas sempre terão a escolha de não querer ser garimpadas por você. Por isso, não basta saber procurar. É preciso saber como atraí-las.

PS: Apesar desse artigo ser sobre atrair bons programadores, grande parte das sugestões se aplicarão perfeitamente a outras profissões na área de TI.

Onde fica a "Serra Pelada" dos bons programadores?

Se você acha que os melhores locais para garimpar bons programadores são os classificados tradicionais de emprego, você errou feio. Pra começar, os melhores programadores, normalmente, não estão no mercado dando sopa. Boa parte deles, sequer freqüenta classificados de emprego. Quando querem mudar de emprego, é na sua rede de contatos profissionais – o famoso network – que eles procuram por uma nova oportunidade. E, mesmo quando não estão procurando um novo emprego, novas oportunidades chegam ao seu conhecimento através desses seus contatos. Se você não tem um bom network, suas chances de encontrar bons programadores são reduzidas, assim como suas chances de conseguir uma melhor oportunidade profissional. Portanto, a primeira dica é ter um bom network, tanto para encontrar profissionais como para ser encontrado.

Se você não puder preencher suas vagas através da sua rede de contatos, será preciso anunciá-las. Mas, como fazer com que seu anúncio seja lido pelos melhores programadores se eles, geralmente, não estão procurando emprego? Seu anúncio precisa aparecer no caminho deles. E por onde eles andam?

Grupos de discussão

Pessoalmente, encontro muitos bons programadores em grupos de discussão relacionados a programação. Se, através das suas participações, percebo que um membro do grupo tem perfil adequado a uma vaga, faço um convite direto. (Eles se sentem honrados com isso!) Mas, mesmo que não possa fazer um convite direto, gosto de anunciar em grupos por causa da grande concentração de programadores realmente interessados, muitos deles apaixonados pelo que fazem. Um detalhe importante é que oportunidades compartilhadas por membros ativos têm mais crédito no grupo.

Eventos de TI

Panfletar anúncios de emprego em eventos de TI pode parecer apelativo, mas é uma ótima alternativa, pois nesses eventos há uma grande concentração de excelentes profissionais. Se houver verba, você pode contratar moças bonitas para fazer a panfletagem. Senão, é melhor deixar um panfleto em cada lugar do auditório. Se você conseguir que as oportunidades da sua empresa sejam também anunciadas do palco, melhor ainda. Esteja disposto também a fornecer mais informações pessoalmente aos interessados. Os melhores profissionais desejarão "entrevistar" você para confirmar se sua empresa é interessante para eles.

Blogs

Se sua empresa ou algum funcionário tem um blog relacionado a desenvolvimento de software com um bom número de leitores, anunciar nesse meio é uma boa alternativa, pois a maioria dos que acompanham blogs são realmente interessados na sua área e você, certamente, quer contratar esse tipo de profissional.

Twitter

Anúncios compartilhados no Twitter são uma boa alternativa, contanto que quem os anuncia tenha um bom número de seguidores na área de TI. Se seu anúncio for muito interessante, é provável que os seguidores de quem tuitou a vaga se interessem ou pelo menos a retuitem, aumentando bastante as chances do seu tweet chegar até bons profissionais. Por causa da limitação de 140 caracteres nos tweets, você precisará publicar o anúncio numa página da sua empresa ou blog e compartilhar no Twitter apenas uma chamada e um link encurtado para o anúncio.

O legal desses meios de divulgação "alternativos" é que você pode chegar até os bons programadores sem que eles estejam procurando um emprego.

Os classificados de emprego tradicionais não precisam ser descartados, mas devem ser usados em último caso. Se tiver que utilizá-los, dê preferência a procurar pelos currículos interessantes e não a anunciar a oportunidade e esperar que pessoas brilhantes peçam para você lhes dar uma oportunidade.

Crie um anúncio sedutor

Fazer seu anúncio "aparecer no caminho" de bons programadores é apenas o começo. O próximo passo é seduzi-los. Por quê? Porque se o cara é bom, sua empresa não é a única alternativa dele. Independente de ele estar procurando um emprego ou não, seu anúncio precisa fazê-lo querer muito a vaga e não apenas se interessar por ela. Se você tem a mínima experiência em motivar pessoas, já deve ter percebido que nós, mesmo sendo técnicos, reagimos muito mais prontamente a estímulos emocionais do que racionais.

Portanto, se você quer motivar bons programadores a lerem seu anúncio e quererem trabalhar na sua empresa, você terá mais sucesso se conseguir mexer com suas emoções. Em outras palavras, você precisa seduzi-los.

É verdade que quanto mais interessante for o seu anúncio, mais candidatos você terá, sendo que a maioria continuará sendo de maus candidatos. Não adianta tentar resolver isso com uma longa lista de requisitos e uma observação (às vezes em caixa alta) tal como "Só envie seu currículo se você atende a todos os requisitos". É melhor se concentrar em criar um anúncio sedutor e depois se dedicar ao "garimpo", pois assim você aumenta suas chances de encontrar alguns bons candidatos.

Não existe uma fórmula para criar um anúncio sedutor, mas tenho visto a aplicação das seguintes sugestões render bons resultados:

Trate os candidatos como humanos (hã?)

Já reparou que a maioria dos anúncios de emprego é escrita como se fosse uma licitação para compra de uma mercadoria? Os requisitos que vemos são semelhantes a:

X anos de experiência em XPTO
Experiência comprovada em XYZ
Curso superior completo nas áreas A, B ou C

Qual o problema? Bem, se um candidato passou X anos mexendo superficialmente com XPTO ele atende aos requisitos? E se ele tem registrado na carteira profissional "Analista XYZ Sênior", mesmo tendo lidado com XYZ apenas ocasionalmente, serve? E se ele tem curso superior completo numa das áreas exigidas, mas foi um péssimo aluno, tudo bem?

Requisitos objetivos demais não ajudam, atrapalham. Eles reduzem a quantidade de candidatos, sem aumentar a qualidade deles. Se você os utilizar, haverá o risco de eliminar candidatos brilhantes por causa de um mero detalhe, que nada tem a ver com talento para fazer bom software. Além disso, requisitos objetivos demais são frios e não mexem com as emoções de quem os lê.

Outra questão é sobre a quantidade de exigências para a vaga. Não caia na tentação de fazer uma longa lista de exigências coma intenção de reduzir a quantidade de candidatos. Se você fizer isso, terá apenas mais candidatos mentirosos e não melhores.

Ao invés de fazer uma lista altamente objetiva do que é imprescindível e do que é desejável, diga em linguagem informal o que se espera do candidato, sem mencionar detalhes que podem ser aprendidos facilmente. Use o bom senso. Se você puder adicionar uma pitada de bom humor, melhor ainda. Lembre-se: você quer descrever o que se espera de uma pessoa e não de uma mercadoria.

Dê um motivo para orgulho

Freud dizia que entre os anseios mais fortes do ser humano está o "desejo de ser grande". As pessoas gostam de pensar que seus trabalhos as tornam importantes, ou "grandes". Um software que terá milhares de usuários ou um trabalho que ajudará numa causa nobre certamente são motivos de orgulho para quem os desenvolve. Se você não pode oferecer esse tipo de orgulho, será bom oferecê-lo de outra forma. Por exemplo, se na sua empresa há uma espécie de culto a qualidade ou você tem na equipe alguns dos melhores profissionais da região, também haverá motivo para orgulho.

Mostre que o trabalho é interessante

Para bons programadores, trabalhos interessantes são aqueles que fazem bom uso do seu talento e que os ajudam a desenvolver novos conhecimentos e habilidades. É por isso que muitos justificam uma mudança de emprego com a "busca por novos desafios". Se você não puder demonstrar pelo seu anúncio que o trabalho em questão envolve um ou mais desafios interessantes, suas chances de ter bons programadores como candidatos serão pequenas.

Mostre que o ambiente é interessante

Programadores são trabalhadores do conhecimento, não operários. Como tal, o sucesso do seu trabalho sofre uma tremenda influência do ambiente no qual é realizado. Ambientes restritivos ou burocráticos, inibem a criatividade, o que afasta aqueles que não estão interessados apenas em receber o salário no final do mês. A maioria dos bons programadores que conheço está nessa categoria.

Se sua empresa não é restritiva nem burocrática em aspectos simples como horário de trabalho ou acesso a internet e você deixar isso claro no seu anúncio, suas chances de atrair excelentes programadores já serão consideravelmente aumentadas. Se for possível trabalhar de casa - mesmo que ocasionalmente – tenha a certeza de que você impressionará os melhores programadores.

Não coloque o ego em jogo

Os melhores programadores não são aqueles que se dizem especialistas em o que quer que seja. Os sensatos, quanto mais sabem sobre um assunto, mais reconhecem que ainda há muito o que aprender. Só os ignorantes vão logo se autoproclamando especialistas. É como disse o matemático e filósofo Bertrand Russell: 'Os tolos e os fanáticos têm sempre certeza, enquanto os sábios estão sempre cheios de dúvidas'.

Se você incluir no seu anúncio exigências do tipo "especialista", "profundo conhecimento", "ninja" ou similares, haverá o risco de descartar aqueles que conhecem muito sobre o assunto, mas que não possuem um ego tão inflado para se considerarem aptos à vaga. Se você não quer correr esse risco, seu anúncio deve ser convidativo, não intimidador.

Se você precisar de inspiração...

Se você precisar de inspiração para escrever anúncios de emprego sedutores, veja a seguir dois dos anúncios que mais gostei de ler. Note que eles se concentram mais no que o candidato pode esperar da empresa do que no que a empresa espera do candidato.

E o garimpo, como faço?

Se você está oferecendo um trabalho interessante, conseguiu criar um anúncio sedutor e o fez aparecer no caminho de bons programadores, sua caixa de e-mails deve estar lotada de candidatos. Anime-se, isso é ótimo! Quando mais candidatos, maiores as suas chances de garimpar um bom programador. Mas se você quiser algumas sugestões sobre como garimpar os bons programadores entre os seus muitos candidatos, leia o artigo Como identificar bons programadores.

Você gostou desse artigo ou tem alguma outra idéia para atrair bons programadores? Deixe seu comentário!

—

Foto: Recrutador (garimpeiro) trabalhando, feliz com a possibilidade de encontrar um bom programador (ouro). Créditos ao fotógrafo Sebastião Salgado.

Referências:

Dale Carnegie. "Como fazer amigos e influenciar pessoas"
Travis Bradberry e Jean Greaves. "Desenvolva sua inteligência emocional"
Domenico de Masi. "Organizações Criativas"

Um assunto leva a outro

2011-01-15T00:00:00.008-02:00

É impressionante como um assunto leva a outro. Quatro artigos atrás, escrevi sobre a limitação das metodologias e concluí dizendo que para fazer bom software é preciso uma equipe talentosa.

No artigo seguinte, eu pretendia escrever sobre como identificar programadores talentosos, mas percebi que, antes disso, era preciso explicar porque é importante contratar programadores talentosos.

Ao começar a escrever sobre isso, me dei conta de que a minha ideia original de talento era muito abrangente e, na verdade, incluía duas outras características - a paixão e o autodidatismo. Então, escrevi uma série de três artigos, um sobre cada uma dessas características.

O próximo artigo, ou série, enfim, seria sobre como identificar programadores talentosos, além de apaixonados e autodidatas.

Juro que era sobre isso que eu pretendia escrever, mas ao começar, percebi que, para poder identificar essas características naqueles que se candidatam a vagas na sua empresa, é preciso primeiro atraí-los.

Então, fique ligado. Em breve publicarei o artigo "Como atrair bons programadores". Acho que está ficando legal, aguarde.

Em seguida (eu espero), publicarei o artigo “Como identificar bons programadores”. Depois de tanto tempo de gestação, espero que nasça algo legal.

—

Foto: Judge Harry Pregerson Interchange em Los Angeles, California.

Características de um bom programador – Parte 3/3 – Autodidatismo

2010-11-06T02:03:00.007-02:00

Encerrando a série de três artigos em que falo sobre as características mais importantes a serem procuradas num programador, hoje explico porque considero o autodidatismo a terceira mais importante característica.

(Para quem não conhece a palavra, autodidatismo é a 'qualidade do autodidata'*. Autodidata, você já sabe, é quem aprende por conta própria, mesmo sem a ajuda de professores.)

Conhecimento tem prazo de validade

Um dos maiores motivos para você desejar ter apenas programadores autodidatas na sua equipe, é que boa parte de todo conhecimento técnico que qualquer programador possua hoje se tornará obsoleto em alguns anos. A experiência adquirida até o presente ajuda a resolver os problemas do passado. Os problemas do futuro exigirão um conhecimento que ainda não existe. Logo, é muito perigoso contratar programadores com base apenas no que eles já sabem. É preciso contratar aqueles que serão capazes de aprender por conta própria o que for necessário para resolver problemas que ainda estão por surgir.

Treinamentos formais não são o suficiente

Aprender por conta própria? Sim, pois não se pode contar apenas com o treinamento formal. A quantidade de tecnologias novas e relevantes é tão grande que é impossível treinar equipes em todas as que parecem promissoras. E mesmo um bom treinamento não é suficiente para capacitar alguém como um bom solucionador de problemas. No máximo, os alunos aprendem a usar ferramentas e técnicas específicas para resolver problemas específicos. Se os alunos não forem autodidatas, suas habilidades ficarão limitadas aos problemas abordados no treinamento, que são infinitamente menores em quantidade que os problemas do mundo real.

“Quando tudo o que você tem é um martelo, todos os problemas parecem pregos” (sabedoria popular)

Além disso, se sua equipe só se atualiza numa nova tecnologia quando há treinamento formal para ela, você estará sempre atrasado. Um monte de equipes de autodidatas já estarão produzindo soluções mais modernas nas outras empresas quando a sua equipe estiver apenas começado a aprender a nova tecnologia.

Aprender sozinho é fácil e divertido

Outro motivo é que para um programador talentoso, apaixonado e autodidata, aprender uma nova linguagem, framework ou técnica é fácil e até divertido. Dê a ele tempo e os recursos necessários para estudar e em questão de semanas ele estará suficientemente produtivo no novo conhecimento. A fluência virá com o tempo.

Na maioria das vezes, é melhor contratar um bom programador e dar a ele tempo para aprender Python, Ruby, Objective-C, Erlang ou o que quer que seja, do que contratar um programador mediano que já conheça o básico da linguagem em que ele vai trabalhar. (Uma exceção é se você está procurando um programador apenas para “apagar incêndios”.)

Acredite, eles existem

Programadores talentosos, apaixonados e autodidatas são a minoria, mas acredite, eles existem. Gostaria de poder dizer que todos eles estão muito bem empregados ou tem um negócio próprio bem sucedido, mas a realidade é que boa parte deles trabalha para empresas que acham que "programador é tudo igual". Se sua empresa não é desse tipo e você quer aprender a identificar as características que tornam alguém um bom programador para levar pessoas assim para a sua equipe, veja os artigos Como atrair bons programadores e Como identificar bons programadores.

O que você achou dessa série de artigos sobre as características mais importantes a serem procuradas num programador? Gostaria de citar alguma outra característica? Comente.

—

* ^ Michaelis - Moderno Dicionário da Língua Portuguesa. "Autodidatismo"

Referências:

Joel Spolsky. "Smart and Get Things Done"

Características de um bom programador – Parte 2/3 – Paixão

2010-10-30T00:00:00.006-02:00

Em 2005, os formandos da Stanford University - uma das melhores universidades do mundo - foram brindados com um discurso memorável de nada menos que Steve Jobs. Seu discurso inteiro merece ser assistido^[1], mas quero citar apenas uma pequena frase dele:

"A única maneira de fazer um trabalho brilhante é amar o que você faz" ^[1]

Jobs contou que os eventos que culminaram na sua demissão da Apple não afetaram seu sentimento para com o seu trabalho. Ele continuou apaixonado pelo que fazia. Essa paixão o motivou a seguir em frente. Ele então criou a NeXT, que produziu a tecnologia que viria a se tomar o coração do Mac OS, e iniciou a Pixar, que produziu o primeiro longa-metragem totalmente feito por computação gráfica - o filme Toy Story. Em uma incrível virada de eventos, Jobs reassumiu a liderança da Apple.

É uma história impressionante, e meu objetivo ao utilizá-la é embasar a afirmação de que talento não é nada sem paixão.

Apaixonados vão mais longe

Pessoas talentosas, mas sem paixão, não vão muito longe. Nenhuma motivação externa (salário, estabilidade, status etc) é capaz de produzir efeitos equivalentes a maior de todas as motivações internas - a paixão. Isso é verdade tanto para um pedreiro como para um programador.

Programadores talentosos e apaixonados não precisam de estímulo para fazer um trabalho de qualidade; eles o fazem porque sentem prazer nisso. Também não precisam de estímulo para serem criativos; eles simplesmente o são. Problemas desafiadores fazem seus olhos brilharem. Por outro lado, os que tem talento, mas não paixão, fazem apenas o suficiente.

Ninguém veste a camisa do outro

Alguns gostam de contratar aqueles que se comprometem a "vestir a camisa da empresa". Mas a realidade é que nós vestimos apenas a nossa própria camisa. Em outras palavras, trabalhamos pelas nossas próprias realizações.

Quando se trata de programadores, não adianta procurar aqueles que serão comprometidos com a empresa. Esse tipo de comprometimento significa apenas que serão funcionários obedientes e honestos, o que não tem nada a ver com fazer bom software. Um bom software é feito por pessoas talentosas e comprometidas com o seu próprio trabalho. Esse comprometimento é o que os leva a procurar pelas melhores soluções para os problemas que a sua empresa enfrenta. E de onde vem esse comprometimento? Não é da paixão pelo empregador, mas da paixão pelo seu ofício. Portanto, esqueça aqueles que dizem que vão "vestir a camisa da empresa" e procure pelos que, de verdade, são apaixonados pelo próprio trabalho.

Nem tudo são flores

O corolário dos programadores talentosos e apaixonados é a sua tendência de produzir soluções mais sofisticadas do que o prazo e o orçamento permitem. Isso, de fato, é um problema para os gestores. Mas é um problema menor e mais fácil de ser contornado do que a improdutividade e baixa qualidade do trabalho de programadores sem talento e paixão.

Outra peculiaridade é que eles facilmente chegam ao estágio House se não tiverem uma boa dose de trabalhos que façam bom uso do seu talento e alimentem a sua paixão. Isso é comum acontecer em empresas que pararam no tempo e não evoluíram tecnologicamente. Se esse é o caso da sua empresa, é melhor conseguir alguns trabalhos interessantes antes que sobrem apenas cowboys na sua equipe.

Pra fechar...

Se você quer fazer bom software, tenha uma equipe talentosa e apaixonada. Sem essas características, não há metodologia, salário, nem gerência que faça uma equipe produzir bom software.

Esse era o recado sobre Paixão. Volte no próximo sábado e leia o último artigo desta série falando sobre a terceira característica que considero mais importante. Se preferir, assine meu RSS, siga-me no Twitter ou torne-se seguidor deste blog para ser informado quando for publicado o próximo artigo.

Você concorda que a paixão é uma das características mais importantes num bom programador? Deixe seu comentário.

—

Foto: Equilibristas talentosas e apaixonadas do Cirque du Soleil.

Referências:

[1] ^a ^b Steve Jobs. "You've got to find what you love" (transcrição)

Características de um bom programador – Parte 1/3 – Talento

2010-10-23T00:00:00.014-02:00

Se você trabalha com desenvolvimento de software há alguns anos, já deve ter percebido que bons profissionais são a minoria no mercado. É impressionante a quantidade de gente que se torna “experiente” e até ganha dinheiro, sem saber fazer software direito.

No artigo anterior, defendi que não é possível fazer bom software sem uma equipe talentosa, por mais que se use uma “boa metodologia”. Dando continuidade ao assunto, neste artigo explico porque considero o talento* a característica mais importante a se procurar num programador.

Em busca das notas altas

Joel Spolsky, no seu livro Smart and Get Things Done, compara a capacidade de programadores fazerem excelente software com a capacidade de cantores atingirem as notas altas. Ele diz:

"Pessoas sem talento nunca atingem as notas altas que as pessoas talentosas atingem todo o tempo" ^[1]

Você certamente conhece “cantores” e “cantoras” que fazem sucesso, mas não por causa da qualidade do seu canto. Porém, quando se trata cantores de ópera, apenas aqueles que atingem as notas altas conseguem se destacar.

Comparando com software, é verdade quem nem todo software precisa atingir as notas altas, por assim dizer. Em empresas que não são de tecnologia, por exemplo, equipes de TI medianas, muitas vezes são o suficiente para atender as expectativas dos gestores. Mas se você está no mercado de desenvolvimento de software criando produtos que precisam se destacar pela sua qualidade, não há saída: você precisa ter programadores talentosos, aqueles capazes de atingir as notas altas.

"Programadores medianos nunca atingem as notas altas que fazem um grande sotware" ^[1]

'Programadores brilhantes são muito, muito mais valiosos que programadores medianos. Eles são de três a dez vezes mais produtivos, custando apenas 20% ou 30% mais. E atingem as notas altas que ninguém mais pode atingir.' ^[1]

Segundo Spolsky, a questão não é apenas a produtividade. É a capacidade de atingir “notas altas”, ou seja, fazer excelente software. Se uma equipe talentosa faz um excelente software em um mês, não adianta dar dez meses para uma equipe mediana fazer o mesmo software, o resultado nunca será equivalente.

Talento se ensina?

É preciso ficar claro que o talento de um programador não está relacionado com sua formação acadêmica ou com seu tempo de experiência, apesar de esses fatores poderem aperfeiçoar talentos. Você já deve ter conhecido aprendizes de programação com grande talento, ainda que tivessem pouca experiência e nenhuma formação acadêmica na área. Por outro lado, você talvez também conheça inúmeros programadores muito experientes e até com boa formação, mas que codificam como um amador.

Atualmente, é praticamente inaceitável dizer que alguém é intrinsecamente incompetente em determinada área. Supõe-se que bons líderes podem fazer emergir qualidades inexploradas nos seus subordinados. Essa visão é bastante confortável para nós quando nosso talento está sendo avaliado. Mas quando se está do outro lado - o lado de quem contrata talentos - a realidade é bem diferente. Tom DeMarco e Timothy Lister, no aclamado livro sobre gerência de projetos Peopleware, são muito francos ao dizer:

“As pessoas que trabalham para você durante qualquer período serão, no fim, mais ou menos a mesma coisa que eram no começo. Se elas não forem as pessoas certas para o trabalho no início, elas nunca serão.” ^[2]

DeMarco e Lister defendem que, mesmo bons gerentes, são incapazes de mudar seus subordinados de forma significativa. A influência que eles podem exercer na natureza dos membros da sua equipe é limitada, dada toda a carga genética e a formação adquirida desde a infância.

É verdade que os indivíduos podem fazer grandes mudanças em si mesmos, mas nós não podemos fazer essas mudanças neles. Portanto, é fundamental que no momento da contratação seus programadores já tenham o talento necessário para fazer bom software.

Esse era o recado sobre Talento. Volte no próximo sábado e leia o segundo artigo desta série onde falarei sobre a segunda característica que considero mais importante. Se preferir, assine meu RSS, siga-me no Twitter ou torne-se seguidor deste blog para ser informado quando for publicado o próximo artigo.

Você concorda que o talento é a característica mais importante que um programador deve ter? Deixe seu comentário.

—

* ^ Por “talento”, me refiro a “aptidão natural ou adquirida”. (Dicionário Priberam da Língua Portuguesa)

Foto: Ópera de Mozart, La finta giardiniera (A falsa jardineira) apresentada no Eastman Opera Theatre por Angelique Jacob (esquerda) e Erica Schuller (direita, no fundo).

Referências:

[1] ^a ^b ^c Joel Spolsky. "Smart and Get Things Done"
[2] ^ Tom DeMarco & Timothy Lister. "Peopleware"

A limitação das metodologias

2010-09-11T00:00:00.018-03:00

Para quem gosta de etimologia, a palavra “metodologia” vem da junção de duas palavras gregas: methodos, que significa "modo para se chegar a um determinado fim ou objetivo" e logia, que significa estudo. Logo, no sentido mais lato, metodologia pode ser definida como o estudo dos métodos para se atingir um objetivo.

Especificamente no desenvolvimento de software, a seguinte citação ajuda a explicar:

“Metodologias impõem um processo disciplinado no desenvolvimento de software, com o objetivo de torná-lo mais previsível e eficiente. Elas fazem isso desenvolvendo um processo detalhado com uma forte ênfase em planejamento” (Martin Fowler)

Sem dúvida, a proposta das metodologias é muito boa. E, de fato, as metodologias que se tornaram populares são realmente boas, tendo sido concebidas por respeitáveis profissionais de desenvolvimento de software. A questão não é se as metodologias são boas, mas se a ênfase dada a elas é adequada.

Para entender melhor, pense em alguma atividade manual que você realize com alguma frequência. Pode ser montar um computador, lavar o carro, aparar a grama etc. Se você listar os procedimentos envolvidos nessa atividade, identificar padrões de ação que se repetem e encontrar os meios mais eficientes e seguros para realizar essas ações, você terá o suficiente para criar uma metodologia que otimize essa atividade. Parece fácil criar uma metodologia para esse tipo de atividade, certo?

Agora, suponha que você queira criar uma metodologia para uma atividade intelectual tal como criar músicas, pinturas ou esculturas*. Concorda que nenhuma metodologia garantiria a produção de belas músicas, pinturas ou esculturas? Você provavelmente concorda porque sabe que quando se trata de um trabalho intelectual, o resultado final não depende da forma como o trabalho foi estruturado, planejado ou conduzido, mas do talento de quem o executa.

Ora, o que é o desenvolvimento de software – um atividade manual ou intelectual? Sendo uma atividade intelectual, há uma barreira que as metodologias não conseguem transpor: a necessidade de pessoas talentosas para executar o trabalho.

“O problema, na maioria das vezes, é que metodologia se opôs à noção que as pessoas são fatores de primeira ordem no sucesso de um projeto.” (Martin Fowler)

Não compreender que desenvolver software é um trabalho predominantemente intelectual é a causa de sérios equívocos na indústria de software, entre eles, tratar software como algo determinístico, que pode ser produzido em série, como numa fábrica. Sob esse olhar equivocado, basta uma boa metodologia e uma equipe ~~obediente~~ disciplinada que o resultado final será maravilhoso. "As pessoas não são importantes, mas sim as suas funções. Mais importante ainda é o processo. Se alguém deixa a equipe, basta substituí-lo por outra pessoa que exerça a mesma função e a engrenagem da fábrica continuará funcionando, afinal, ninguém é insubstituível."

Isso pode soar correto na teoria, mas na prática, resulta em softwares que até atendem aos requisitos funcionais, mas falham em atender aos requisitos não funcionais como facilidade de uso, rapidez e manutenibilidade.

“Não há pesquisas e estudos suficientes sobre como se organiza o trabalho intelectual ou criativo. Na falta desse conhecimento, a empresa aplica para intelectuais as mesmas regras criadas para os trabalhadores manuais [...] A conseqüência é que a criatividade fica reprimida e diminuída.” (Domenico de Masi)

Se você quer fazer bom software, tenha uma equipe talentosa e dê a ela boas condições de trabalho. Metodologias serão de ajuda, desde que sirvam como um plano geral, constantemente adaptado ao tipo e às circunstâncias de cada projeto.

Gostou desse artigo? Ficarei feliz ao ler seu comentário.

—

* ^ Para efeito de desambiguação, estou usando a seguinte definição para atividade/trabalho intelectual: "Trabalho intelectual é o que envolve a manifestação do intelecto, em todos ou qualquer dos seus sentidos: intuitivo, operativo ou compreendente, ou seja, a ação criativa ou recriativa, de ordem física e/ou mental, concebida a partir da compreensão abstrata do objeto." (LIMA, Francisco Meton Marques de - Âmbito Jurídico)

Crédito da foto: National Geographic (elefante pintor do Thailand Elephant Conservation Center)

Referências:

Martin Fowler. “The new methodology”.
Tom DeMarco & Timothy Lister. "Peopleware"
Alexandre Gomes. "Manifesto 2.0"
Domenico de Masi. "Organizações Criativas"

Não faça o usuário pensar

2010-08-14T12:21:00.007-03:00

Aos dezessete anos de idade consegui meu primeiro emprego como programador. Foi numa pequena empresa que desenvolvia software para outras pequenas empresas. Os usuários desses softwares eram, na sua esmagadora maioria, quase totalmente leigos em informática. Esse cenário fez com que o seguinte conselho do meu então chefe fosse pertinente:

“Nunca duvide da capacidade de um usuário ser uma “ameba”.”

Em outras palavras, meu chefe não queria que eu deixasse brechas nos softwares para que os usuários cometessem um erro. Se houvesse uma única chance de um usuário fazer uma besteira, isso seria suficiente para algo dar errado. Era a Lei de Murphy.

Um motivo mais nobre

Anos mais tarde, depois de desenvolver diversos projetos de software para os mais variados perfis de usuários, e depois de me tornar um forte crítico de todos os softwares que uso e desenvolvo, me dei conta de que há um motivo, digamos, mais nobre, para não exigir muito raciocínio dos usuários dos softwares que faço:

“Meu software é apenas o meio pelo qual os usuários resolvem seus problemas.”

Ou seja, os usuários querem pensar apenas sobre os seus próprios problemas, sejam eles as suas compras, vendas, cobranças, pagamentos, reposições de estoque etc. Eles não querem ter que pensar sobre o meu software. Se meu software exigir que eles pensem em coisas que não são os seus problemas, isso significa que não fui eficiente em projetar um software que facilite sua vida.

Facilitando a vida dos usuários

Um software que facilite a vida dos usuários vai além de resolver os seus problemas (ou “atender aos requisitos funcionais”). Ele os conduz pelo caminho necessário de forma que se sintam confiantes de que estão fazendo a coisa certa. Suas escolhas são praticamente impensadas de tão óbvias. Isso traz à tona a importância de algo que não é levado em consideração por muitos desenvolvedores de software: a Usabilidade.

Como diz meu amigo Valmir Santana, uma boa imagem vale mais que 1024 palavras. Então vamos analisar algumas imagens em dois exemplos de usabilidade.

O exemplo ruim

O exemplo ruim tirei do internet banking do banco onde concentro minhas transações financeiras. Eventualmente me sobra algum dinheiro na conta corrente e eu o transfiro para a poupança, que tem o mesmo número da conta corrente. A interface onde realizo essa operação não é intuitiva como poderia ser. Vejamos:

Suponha que eu queira transferir R$1000 da conta corrente para a conta poupança. Consigo fazer isso através dessa interface? Bem, a primeira informação apresentada (dentre muitas) diz que se eu precisar de um limite maior para transferências, preciso utilizar a opção “Transferência entre Contas Cadastradas”. Mas qual é o limite??? Preciso ler o restante do texto para descobrir que o limite diário é de R$500 (note que a ordem das informações está invertida: primeiro se informa o que fazer quando o valor de transferência é superior ao limite e só depois se informa qual é o limite).

De qualquer forma, esse limite NÃO se aplica ao tipo de transferência que quero fazer - entre uma conta corrente e uma poupança com mesmo número. E o cadastramento de contas para transferências com limite superior a R$500 também NÃO se aplica ao meu caso. Mas como descobrir isso? A interface não me ajuda (eu descobri por tentativa e erro).

Percebeu o quanto foi preciso pensar desnecessariamente no software para “resolver o meu problema”?

Agora veja uma outra parte dessa mesma interface:

Por que eu precisaria informar o número da agência e conta destino se ele é exatamente o mesmo da conta origem?

O bom exemplo

Quando resolvi passar a ler os meus e-mails do Yahoo! a partir da minha caixa de entrada no GMail, fiquei bastante impressionado ao ver como foi mais fácil fazer isso no GMail do que em clientes de e-mail como o Outlook e Thunderbird.

Veja qual a primeira coisa que o GMail me solicitou no seu amigável e sucinto wizard.

Essa é a única informação necessária para começar. Note que, com base no e-mail fornecido, algumas informações foram automaticamente deduzidas.

Um usuário inexperiente poderia facilmente ficar confuso se tivesse que fornecer o endereço e a porta do servidor POP, mas o Gmail sabe deduzir essas informações para o usuário. Por outro lado, se as informações deduzidas não estiverem corretas, é possível para o usuário alterá-las. Continuando...

Essa última captura é a que mais me impressionou. O GMail me ofereceu a possibilidade de enviar e-mails do Yahoo! usando um servidor SMTP do próprio GMail. Neste caso, nem preciso saber qual é o endereço SMTP do GMail – o software por trás dessa interface me poupa da necessidade de conhecer esse dado. Por outro lado, se eu quiser informar o endereço SMTP do Yahoo! poderei fazer isso sem problemas, mas note que a interface foi projeta para o cenário mais fácil e mais provável.

Conclusão

Projetar interfaces como no bom exemplo acima, não é subestimar a inteligência do usuário. É fazê-lo não pensar no software desnecessariamente. O usuário avançado perceberá a facilidade e sentirá que foi levado em consideração quando essa interface foi projetada. O usuário leigo talvez não perceba o quanto foi mais fácil resolver seu problema - ele só sabe que não teve dificuldade para conseguir o que queria, o que é o suficiente. Um software assim passa confiança para o usuário.

A qualidade interna do software sem dúvida é importante, mas ela não significará nada para o usuário se a interação dele com o software for sofrível. Se o usuário frequentemente se pergunta “Será que dá pra fazer X?” ou “Onde será que fica Y?” ou “Como faço Z?” a qualidade do software percebida por ele será baixa.

Portanto, ao projetar interfaces de usuário, seja em sistema web, mobile ou desktop, lembre-se:

Usuários precisam ter a confiança contínua de que estão no caminho correto.
Tornar as escolhas mais claras é uma das principais coisas que tornam um software mais fácil de ser usado.

Gostou do que leu? Deixe seu comentário.

—

Crédito da foto: Jessy Ratfink

Referências:

Steve Krug. "Não Me Faça Pensar"
Google. "Ten principles that contribute to a Googley user experience"
Wikipedia. "Usabilidade"
Chris Parsons. "UX is everything"

// Não comente seu código

2010-07-17T22:00:00.021-03:00

Você usa desodorante nas axilas? Se usa, provavelmente o faz por causa do mau cheiro produzido pelas suas glândulas sudoríparas dessa região.

É por um motivo semelhante que muitos programadores escrevem comentários. Seu código é difícil de compreender, por isso precisa ser comentado. Mas se o código ruim fosse refatorado até se tornar um bom código, a maioria dos comentários seriam desnecessários.

1 - Comentários como desodorante

Com a ajuda do Martin Fowler no seu livro sobre refatoração, me dei conta de que muitos dos comentários que eu escrevia no passado eram usados para minimizar os efeitos de um código ruim (do ponto de vista da clareza, não da eficiência). O código ruim, segundo Fowler, cheira mal e os comentários, neste caso, agem como desodorante. A seguir, alguns desses maus usos de comentários.

1.1 - Para compensar a má nomeação de identificadores

Se você sentir a necessidade de comentar pra que serve uma váriável, constante, função, parâmetro de função, atributo, classe ou método*, provavelmente o nome que você deu ao identificador não é um bom nome.

Sem ser dogmático, sugiro o seguinte:

'Quando você sentir a necessidade de escrever um comentário para explicar o que faz ou pra que serve determinado identificador, transforme o comentário que você escreveria no nome do identificador.' (uma adaptação de algumas frases do Fowler)

Transformar um comentário curto em um nome de variável é fácil (a menos que você use uma variável para várias coisas diferentes). Mas, transformar um comentário de várias linhas em um nome de função dará mais trabalho, porém, neste caso, os comentários longos são consequência de um outro problema: funções longas.

1.2 - Para compensar a escrita de funções longas

Quem escreve uma função com muitas linhas, normalmente sente a necessidade de adicionar um comentário junto à declaração da função para explicar as coisas que ela faz. No corpo de funções desse tipo, também é comum encontrar comentários para explicar certos agrupamentos de código. Em ambos os casos, os comentários são um indício de que o código não está suficientemente claro.

Ao invés de se eximir da responsabilidade pelo mau código atrás de comentários, refatore o código desmembrando a função longa em várias funções menores. Se há comentários ao longo do corpo da função, esses comentários dão uma dica do que pode ser extraído e do nome que você pode dar a cada função extraída.

Laços com muitas linhas de código dentro de uma função são terríveis para compreender, especialmente laços aninhados. Se você reduzir o número de linhas dentro de um laço de forma que possa observar sem usar scroll onde começa e onde termina o laço, seu código será mais fácil de compreender.

1.3 - Para explicar o uso de strings e números literais

Strings e números literais são valores escritos diretamente no código. Por exemplo, em certo programa, pode ser convencionado que os tipos de inscrição CPF e CNPJ serão representados pelos inteiros 1 e 2, respectivamente. Se o programador decidir usar os literais 1 e 2 em todo código que lide com os tipos de inscrição, ele provavelmente compensará isso com o uso de comentários. Exemplo (em Java):

/* Exemplo A */

String getInscricaoFormatada1(int tipoInscricao, String inscricao) {



  if (tipoInscricao==1) /* 1=CPF */

    return formatarTexto("999.999.999-99", inscricao);

  else if (tipoInscricao==2) /* 2=CNPJ */

    return formatarTexto("99.999.999/9999-99", inscricao);

  else

    return inscricao;

}

Apesar de o código acima permitir uma fácil compreensão, o próximo código - que não usa comentários - tende a ser mais adequado.


/* Exemplo B */

static final int TIPO_INSCRICAO_CPF = 1;

static final int TIPO_INSCRICAO_CNPJ = 2;



String getInscricaoFormatada2(int tipoInscricao, String inscricao) {



  if (tipoInscricao == TIPO_INSCRICAO_CPF)

    return formatarTexto("999.999.999-99", inscricao);

  else if (tipoInscricao == TIPO_INSCRICAO_CNPJ)

    return formatarTexto("99.999.999/9999-99", inscricao);

  else

    return inscricao;

}

A alternativa "B" é preferível porque, além de dispensar o uso de comentários, evita erros. Se você digitar incorretamente o nome de uma constante ao fazer uso dela, o compilador perceberá, enquanto ele não poderá ajudar se você fizer uso de um literal incorreto.

3 - Quando usar comentários?

Tudo bem se você achar que estou sendo contraditório neste tópico por causa do título que escolhi para o artigo. A verdade é que eu gosto dos comentários, desde que não sejam usados como desodorante. Aqui vão alguns dos usos que considero adequados.

3.1 - Para organizar o pensamento sobre o código

Quando não uso um quadro ou papel para rascunhar o que vou codificar, uso comentários para criar uma lista de passos que preciso seguir para atingir o objetivo do código. Esses passos não precisam ser precisos, apenas precisam ser "persistidos" em algum lugar para que eu não esqueça deles. À medida que os passos são concluídos, removo os comentários, pois nesse ponto se tornam irrelevantes.

3.2 - Para marcar código duvidoso, passível de melhora ou incompleto

Há casos em que algumas suposições precisam ser temporariamente assumidas como verdadeiras para que a codificação flua sem empecilhos. Nestes casos, é útil marcar o código duvidoso com um comentário precedido por um "TODO" ("fazer", em inglês). O mesmo se dá com códigos passíveis de melhora ou incompletos. Alguns exemplos:


  /* TODO: confirmar se o DV da conta é calculado com módulo 10 */


  /* TODO: refatorar este código para remover as duplicações /*


  /* TODO: validar campos obrigatórios antes de gravar /*

PS: IDE's de desenvolvimento modernas permitem a fácil localização dos comentários marcados com "TODO".

3.3 - Para explicar porque você fez algo

Há certas ocasiões em que você precisa explicar porque fez algo no código - especialmente quando isso torna o código mais complexo. Quando não é óbvio o porquê de uma decisão e você não esclarece isso com comentários, há o risco de que algum programador, ao assumir o seu trabalho, torne o código mais simples - o que pode levar a falhas que ele não tem condições de prever ou a um mau desempenho.

Um bom exemplo é um comentário escrito por nada menos que Linus Torvalds num arquivo fonte do Git (em C) para justificar a criação de um alocador de memória especializado ao invés de utilizar a função malloc() padrão:


  /*

   * alloc.c  - specialized allocator for internal objects

   *

   * Copyright (C) 2006 Linus Torvalds

   *

   * The standard malloc/free wastes too much space for objects, partly

   * because it maintains all the allocation infrastructure (which isn't

   * needed, since we never free an object descriptor anyway), but even

   * more because it ends up with maximal alignment because it doesn't

   * know what the object alignment for the new allocation is.

   */

Conclusão

Para encerrar, duas ótimas citações:

"Qualquer tolo consegue escrever código que um computador entenda. Bons programadores escrevem código que humanos possam entender." (Martin Fowler)

"Sempre codifique como se o programador que vai dar manutenção no seu código fosse um serial killer maníaco que sabe onde você mora." (autor desconhecido)

Gostou do que leu? Deixe seu /*comentário*/.

—

* ^ A rigor, variável e atributo são coisas diferentes, assim como função e método. Mas, para fins de simplificação, quando eu disser "variável", estarei me referindo também a "atributo" e quando disser "função" estarei me referindo também a método.

Crédito da foto: George Marks

Referências:

5 dicas para aproveitar sua inteligência e criatividade

2010-06-26T08:00:00.004-03:00

Tradução: A satisfação dos funcionários dobrou desde o último ano (1% -> 2%) | O crédito vai para o nosso novo programa de demissão das pessoas inteligentes | Você está seguro. YEFF!!!

No artigo anterior, falei sobre o "Estágio House" do bom programador. Esse é o estágio em que bons programadores estão cansados de fazer trabalhos que subutilizem sua inteligência e criatividade e começam a buscar trabalhos mais desafiadores. Como continuação, apresento nesse artigo algumas sugestões do que programadores nesse estágio podem fazer para usar melhor sua inteligência e criatividade.

1 - Torne seus problemas interessantes

Se os mesmos trabalhos pouco desafiadores não saem da sua lista de atividades, você pode encontrar satisfação por automatizar a solução dos seus problemas. Isso pode significar criar bibliotecas, frameworks ou geradores de código. Ferramentas que automatizam tarefas repetitivas (não necessariamente de codificação) também podem ser ao mesmo tempo interessantes e úteis. Bem, se você está no estágio "House", é provável que já esteja fazendo quase tudo o que acabei de sugerir.

Algo que você talvez ainda não esteja fazendo é procurar resolver os problemas de formas que não necessariamente economizem o seu tempo, mas que te ensinem algo novo. Boa parte das suas descobertas significarão absolutamente nada para os seus superiores não-técnicos, mas certamente tornarão o seu trabalho mais interessante. Eventualmente você criará algo brilhante e sua empresa poderá tirar muito proveito disso. Aliás, você deve sempre procurar uma forma de aprender algo novo que resulte em benefícios para a empresa onde trabalha.

Uma palavra de cautela: muito cuidado para não prejudicar projetos com prazo curto e grande pressão com o seu desejo de experimentar algo novo. Dê preferência a fazer isso em projetos com certa "gordura" no prazo. Se você tem a felicidade de ser consultado sobre prazos, ocasionalmente pode experimentar acrescentar um pouco de "gordura" ao seu prazo para comportar um esforço adicional que gere novos conhecimentos.

2 - Proponha projetos interessantes

Fique atento aos problemas existente na sua própria empresa. Identifique um que possa ser resolvido através de software. É o tipo de software em que você se interessaria em trabalhar? Então rascunhe um projeto que resolva ou minimize esse problema e apresente para quem tem o poder de decidir investir nele. Se você conseguir passar confiança de que sabe como resolver o problema e que quer resolvê-lo, pode ser encarregado de cuidar pessoalmente desse projeto.

Há algo nos softwares desenvolvidos pela sua empresa que poderia ser melhor se fosse feito diferente? É o tipo de mudança que você gostaria de fazer? Então crie uma prova de conceito que valide a sua idéia e proponha a mudança.

Você tem uma ótima ideia de projeto na cabeça, mas não tem os recursos necessários para implementá-lo de forma independente? Acha que a sua empresa seria uma boa parceira de negócios? Proponha uma parceria.

3 - Crie seus próprios projetos interessantes

Paralelo ao seu emprego atual, de forma independente, há algo quevocê pode fazer. Robert Kiyosaki, no seu livro Pai Rico, Pai Pobre afirma que as oportunidades estão ao nosso redor o tempo todo. Para nós, que criamos software, isso é ainda mais verdadeiro. Esse mercado está em constante mudança e isso cria oportunidades novas a todo momento.

Em 2008, a Apple inaugurou a App Store, criando oportunidades para programadores independentes desenvolverem aplicativos para iPhone, iPod Touch e, mais recentemente, para iPad. Em 2009, a Google criou a Android Market - loja de aplicativos para dispositivos móveis com o sistema operacional Android. E no mês passado (19/05/2010), a Google anunciou a Chrome Web Store - sua loja de aplicativos na "nuvem".

Você provavelmente já possui algum conhecimento que te permita aproveitar a oportunidade de criar e vender software inteligente e criativo, seja num dos novos mercados que citei, seja em algum outro. Se te falta algum conhecimento, certamente é possível adquiri-lo. Muita informação é oferecida de graça ou com baixo custo na internet.

Se sua idéia fizer sucesso, você pode conseguir um dinheiro extra ou até transformar sua atividade paralela no seu principal negócio. Se, por outro lado, sua idéia não der tão certo, pelo menos você terá adquirido novos conhecimentos e habilidades que poderão ser úteis para você mesmo ou para alguma empresa em que você gostaria de trabalhar (além, é claro, de você ter se divertido no processo).

4 - Trabalhe em um projeto open source

Se você é muito bem remunerado para fazer seu trabalho pouco desafiador, talvez queira considerar a possibilidade de trabalhar em paralelo num projeto open source. Você pode criar um ou apoiar um existente que considere interessante. Sua recompensa imediata não virá em forma financeira, mas em forma de satisfação pessoal e prestígio dentro da comunidade que receber o seu apoio. Por outro lado, dependendo da reputação que você conquistar, oportunidades muito interessantes poderão bater à sua porta.

5 - Procure outro emprego

Se você não consegue fazer trabalhos que te deem satisfação no seu emprego atual e seu salário não é suficientemente alto para compensar isso, mudar de emprego é uma alternativa a considerar. Um problema que você provavelmente terá é encontrar um emprego que junte um trabalho interessante com uma boa remuneração. Mas, mudar de emprego para ganhar um salário menor pode ser vantajoso se o trabalho que você for realizar fizer bom uso da sua inteligêngia e criatividade. Se for numa empresa séria, em pouco tempo o seu talento será reconhecido e você poderá passar a ganhar mais do que no emprego anterior.

Um ponto muito importante é saber como procurar por um novo emprego. A melhor forma - para os realmente talentosos - tem se mostrado ser através de networking. Quanto maior e mais rico for o seu, melhores oportunidades você terá. Você pode aumentar o seu networking participando de grupos de discussão, Coding Dojo's, eventos de tecnologia, cursos e, finalmente, participando de projetos open source.

Você gostou das sugestões ou acha que algo diferente poderia ter sido sugerido? Deixe seu comentário.

—

Fontes:

Wikipedia. App Store
Wikipedia. Android Market
Business Insider. Google Launching "Chrome Web Store"

O estágio "House" do bom programador

2010-06-12T08:00:00.040-03:00

Quando começamos a programar, qualquer problema, por menor que seja, se torna desafiador por ser algo novo. Depois de algum tempo enfrentando os mesmos problemas, nos tornamos bons em resolvê-los e fazemos isso de forma cada vez mais eficiente. Porém, depois de algum tempo aplicando toda a eficiência que adquirimos para resolver os mesmos problemas, nossa inteligência e criatividade começam a ficar subutilizadas. O desafio desaparece; junto vai embora a motivação. Então, começamos a procurar por novos problemas que desafiem a nossa inteligência e criatividade. Esse, pra mim, é o "Estágio House" do bom programador.

Esse termo me veio à mente depois de assistir a alguns episódios da série norte-americana House, que tem como principal personagem o Dr. Gregory House - um brilhante médico que é obrigado a consultar pacientes com problemas comuns, mas detesta fazer isso! Ele gosta mesmo é de encontrar diagnóstico para os casos mais difíceis - aqueles que desafiam a sua inteligência e raciocínio. É na investigação desses casos que o Dr. House encontra satisfação. É aí que seu talento fica evidente. É aí que estão os desafios que o interessam.

O programador no estágio House ainda gosta muito de programar, porém, não mais aqueles "sisteminhas" que programadores medianos podem fazer. Ele quer é trabalhar em projetos que façam bom uso do talento que ele desenvolveu e em projetos desafiadores que o façam desenvolver novos conhecimentos e habilidades.

Infelizmente (para programadores nesse estágio, felizmente para outros) boa parte das oportunidades de trabalho são para fazer softwares que não requerem programadores muito talentosos. Algumas empresas até preferem programadores menos talentosos, pois são mais obedientes e não questionam quando são encarregados de fazer um software ruim (algo comum quando quem está no comando não é bom tecnicamente).

Nem todos os programadores, entretanto, chegam no estágio House. E isso não é necessariamente ruim. O ser humano, de modo geral, gosta de estar na Zona de Conforto. Se você resolve os mesmos problemas ano após ano, provavelmente se tornou bom nisso. Por que arriscar ser mediano resolvendo novos problemas quando você pode continuar sendo bom em resolver os velhos problemas? É uma questão de escolha.

Mas se você está no estágio House e seu trabalho atual subutiliza sua inteligência e criatividade, aguarde, no próximo artigo apresentarei algumas sugestões do que você pode fazer.

E você, já chegou no estágio House? Compartilhe sua experiência.

—

Um dos momentos de House que inspiraram este artigo, pode ser visto, em inglês, aqui. Se preferir, há uma péssima dublagem em espanhol aqui. Lamento não ter conseguido um vídeo legendado em português. Ele diz algo mais ou menos assim:

'Olá gente doente, sou o Dr. Gregory House, mas podem me chamar de Greg. Sou um dos três médicos de plantão esta manhã. Sou diagnosticista certificado e tenho especialidade dupla em doenças infecciosas e nefrologia. Também sou o único médico desta clínica forçado a estar aqui contra a vontade, não é?' (olhando para Cuddy, diretora do hospital) 'Mas não se preocupem porque a maioria de vocês poderia ser tratado por um macaco com um analgésico... Quem quer ser atendido por mim?' (ninguém levanta a mão) 'Quem quer ser atendido pelos outros médicos?' (todos levantam a mão)

Quando usar soluções de contorno

2010-05-29T11:00:00.006-03:00

Quando bombeiros chegam a um local em chamas, qual é prioridade número UM? "Apagar o fogo" talvez pareça a resposta óbvia. Mas a prioridade é salvar as vidas que estão em perigo.

Os momentos de maior pressão que enfrentei como desenvolvedor de software foram similares a um incêndio: bugs críticos em softwares em produção. O que aprendi em episódios como esses? Que a prioridade número UM quando um software em produção para por causa de um bug, não é corrigir o bug, mas fazer com que o fluxo de trabalho do cliente seja restabelecido. É como salvar as vítimas de um incêndio. Na maioria das vezes a solução definitiva (apagar o fogo) leva mais tempo do que o cliente (a vítima) pode esperar. É aí que entram as "soluções de contorno".

Um exemplo simples:

Um megacliente da sua empresa informa que pagou sem atraso a mensalidade do serviço online XPTO, mas o serviço foi bloqueado. Você descobre que o pagamento realmente entrou na conta, mas não consta no software que você fez para processar os pagamentos. O cliente está furioso! Seu gerente também! Até a sua diretoria já sabe do problema!

Você começa a imaginar em que parte do código está o problema, até já tem uma intuição. E então, pronto para pôr as mãos no seu código? É isso o que você faria?

Eu te faria duas perguntas:

Se, como solução de contorno, você lançar manualmente no banco de dados do seu software o pagamento do cliente, ele terá acesso ao serviço bloqueado muito antes do que se você implementar a solução definitiva?
A solução de contorno pode ser feita com baixo risco de "efeitos colaterais"?

Se a resposta a essas duas perguntas for "sim", minha sugestão é que seja adotada imediatamente a solução de contorno. Em seguida, sob menor pressão, que seja investigado o que causou o problema e como resolvê-lo.

Soluções de contorno são o que o nome diz: "de contorno". A causa do problema continuará existindo e o problema voltará a acontecer - a menos que seja implementada a solução definitiva. E você DEVE implementá-la enquanto o problema está fresco na sua cabeça.

Priorizar a correção do software ao invés de resolver o problema do cliente é perigoso especialmente quando você não tem noção de quanto tempo levará para concluir a correção. E os efeitos dessa demora podem ser irreparáveis - vidas estão envolvidas (inclusive a sua).

Se você já usou uma solução de contorno numa situação excepcional, deixe seu comentário.

—

Créditos da foto: http://www.firetactics.com

O que fazer quando o prazo é curto e a pressão é grande?

2010-05-15T10:40:00.016-03:00

Em mais de uma década de experiência profissional, foram raras as ocasiões em que não estive envolvido num projeto com prazo curto e grande pressão. Isso pode ser familiar para você, que também desenvolve software. Muitas vezes, você talvez se sinta como eu: dividido entre manter a qualidade do seu código e atender ao prazo.

Como cumprir prazos sem abrir mão da qualidade? O que fazer quando não for possível cumprir o prazo? São pontos que pretendo abordar neste artigo.

Nota: Partirei da premissa de que a pressão é para concluir um projeto ou lançar um release. Em outro artigo abordarei a pressão para a correção de falhas críticas de software em produção.

1 - Reduza o escopo

Quando é evidente que o prazo é curto demais para determinado projeto, minha primeira proposta é a redução de escopo. Particularmente, acho maravilhoso deixar de fora funcionalidades não essenciais. Além de favorecer o cumprimento de prazos, isso geralmente torna o software mais simples de usar, evoluir e manter.

"...os melhores programadores não são os que possuem as melhores habilidades... e sim aqueles que podem determinar o que não importa." (37signals) ^[1]

"Inovação... é dizer NÃO para tudo exceto as funcionalidades mais cruciais." (Steve Jobs) ^[2]

Algumas funcionalidade que sugeri não implementar em projetos onde estive envolvido, nunca foram implementadas, mesmo depois de anos. Não por esquecimento, e sim porque se mostraram irrelevantes ou porque novas necessidades mais importantes foram identificadas.

2 - Comece pelo que é mais importante (para o cliente)

Mesmo com o escopo reduzido, ainda é necessário avaliar o que merece ser implementado primeiro. Se, ao terminar o prazo, o projeto não estiver concluído, você não desejará ter em mãos um software inutilizável porque deixou pra fazer por último as funcionalidades mais complicadas (que por acaso eram as mais importantes). Implemente primeiro as funcionalidades vitais, sem as quais seu software não faz sentido. Se algo não ficar pronto a tempo, que seja o menos importante.

3 - Faça só o que tem que ser feito

"Sempre implemente as coisas quando você realmente precisar delas, nunca quando você prevê que precisará delas" (Ron Jeffries, um dos criadores do XP) ^[3]

Muitas vezes, o próprio programador encurta o seu prazo por querer "ir além", fazer aquilo que ele tem certeza que será necessário implementar no futuro, mas ainda não foi solicitado. Essa atitude traz consigo três implicações:

Exige um tempo maior para implementação, testes e ajustes;
Torna o software maior e mais difícil de manter;
O que se pensa ser necessário no presente, talvez nunca se torne necessário; ou se torne necessário, mas não como foi imaginado.

Não é por acaso que a expressão "You ain't gonna need it" (Você não vai precisar disso) ou sua abreviação YAGNY são tão populares entre os adeptos do Extreme Programming.

4 - Tenha moderação ao se preocupar com a performance

"Devemos esquecer as pequenas eficiências, digamos 97% do tempo, otimização prematura é a raiz de todos os males." (Donald Knuth)^[4]

Segundo Knuth, na maioria dos casos, você não deve se preocupar com a performance do código que escreve. Isso pode soar estranho e talvez gere polêmica em torno do assunto, mas faz sentido - mesmo que você não tenha um prazo curto.

Um código otimizado para ter melhor performance, geralmente se torna menos legível e mais difícil de manter. Que percentual do código que você escreve merece se tornar menos legível em benefício da performance?

Outro ponto a considerar é quando os usuários tolerarão aguardar um pouco por uma resposta do software. Uma geração de relatório que acontece uma vez por mês tende a ter uma tolerância alta, enquanto uma pesquisa realizada dezenas ou centenas de vezes por dia tende a ter uma tolerância baixa.

Tornar um algoritmo 10 vezes mais veloz pode ser excitante para você, mas não para seus usuários se isso significar reduzir o tempo de resposta de 100 milissegundos para 10 milissegundos. Por outro lado, se você tornar um algoritmo "apenas" 2 vezes mais veloz, seus usuários ficarão felizes se isso significar uma redução de 60 segundos para 30 segundos no tempo de resposta.

Por último, mas não menos importante, quanto tempo você demorará para implementar um mecanismos que faça algo X vezes mais rápido? Seu prazo comporta esse tempo?

5 - Compartilhe decisões que diminuirão a qualidade do software

Há, infelizmente, casos em que a solução capaz de ser implementada dentro do prazo diminua a qualidade do software.

Por exemplo, você começa a codificar uma nova funcionalidade que será adicionada a um software em produção. Depois de alguns minutos, percebe que já escreveu algo parecido em outra parte do programa no passado. Como um bom programador, você logo pensa em tornar genérica a parte comum entre as duas funcionalidades e isolar os códigos específicos. Só que você talvez precise de alguns dias para concluir essa generalização, criar e testar a nova funcionalidade (além de retestar a funcionalidade antiga), enquanto precisará de apenas algumas horas se fizer o famoso "copy & paste", além de algumas alterações no código copiado. Seu gerente (que não te consultou antes de passar o prazo para o cliente) te deu apenas 1 dia para terminar esse trabalho.

Você sabe que duplicar código é algo horrível! É uma daquelas práticas que acabam com a manutenibilidade do software. Se for descoberto um bug no código original, será necessário alterar todas as cópias desse código (se você lembrar delas). Mas você está sob pressão. E então, o que você faria?

Em situações como essa, é preciso ser muito franco. Explique claramente ao seu gerente (que talvez nunca tenha sido um programador) os prós e contras de cada alternativa e deixe-o tomar a decisão junto com você (ou por você, se ele preferir). Se, compreendendo as implicações negativas, seu gerente disser quer a solução mais rápida, coloque seu chapéu de cowboy ^[5] ^[6] e atenda a vontade dele. Apenas lembre de adicionar comentários significativos no código que facilitem a manutenção no futuro.

Se você for pressionado a agir como um "Programador Cowboy" por muito tempo, talvez seja bom considerar uma mudança de emprego.

6 - Se perceber que vai atrasar, avise antes que aconteça

Não tente adiar o sofrimento. Se o prazo está terminando e você percebe que não conseguirá concluir o projeto, avise com antecedência. Essa ocasião pode ser um bom momento para sugerir uma reavaliação do escopo (ou uma alteração do prazo).

Lembre-se:

"É melhor fazer meio-produto do que um produto meia-boca" (Getting Real) ^[1]

—

Foto: Escravos numa galé romana - Filme Ben-Hur, 1959

[1] ^ 37signals. "Caindo na Real"

[2] ^ Derek Sivers. "Say NO by default"

[3] ^ Ron Jeffries. "You're NOT gonna need it!"

[4] ^ Donald Knuth. "Structured Programming with go to Statements"

[5] ^ Online Etymology Dictionary. "Cowboy"

[6] ^ Tim Bowen. "Wordof the week: Cowboy"

Você ama seu código?

2010-05-01T18:30:00.020-03:00

Algum tempo atrás, numa das comunidades de programação que participo, alguém pediu "ajuda" para resolver um problema com matrizes. Era, provavelmente, um iniciante querendo uma solução fácil para um trabalho de faculdade. Não era algo complexo, mas se tratava de um desafio interessante. Naquele mesmo dia, à noite, implementei uma solução para o problema. Fiquei feliz por ajudar o aspirante a programador, mas confesso que o amor ao próximo não foi o único motivador da minha ajuda.

Acredito que algo semelhante aconteça com muitos dos talentosos programadores que apóiam produtos open source. Não creio que seja apenas o interesse em contribuir com a liberdade de usar, estudar, modificar e distribuir software^[1] o que os motiva a trabalhar em prol de algo que não lhes dará retorno financeiro direto. Concordo com Mårten Mickos, ex-CEO da empresa que criou o MySQL, que cita^[2] o desejo de "construir uma reputação" como um dos maiores motivadores. Como essa reputação é construída? Escrevendo código útil e de qualidade. Eles amam programar, amam o código que escrevem e amam a reputação que isso lhes dá.

Acho que a maioria dos programadores não ama seu código. Se amassem não escreveriam código de tão má qualidade. Ou será que amam seu código, mas simplesmente não se dão conta de que escrevem código ruim?

Quando preciso fazer manutenção em algum código escrito por outro programador, é inevitável fazer algumas suposições sobre esse programador. Dois exemplos comuns são:

Não é prático: criou uma solução extremamente complexa sem necessidade;
É desleixado: a organização do código é terrível e nada recebeu um nome adequado (variáveis, classes, funções etc).

Por causa dessas suposições alheias que faço, ao codificar a solução de algum problema em software, sempre penso no que meu código dirá a meu respeito. Isso me motiva a fazer um bom trabalho. Por acreditar que bons programadores terão uma impressão positiva a meu respeito ao olhar o código que escrevo, eu amo meu código.

É claro que escrever código de qualidade é um desafio quando o prazo é curto e a pressão é grande, mas isso é papo para outra thread.

A propósito, aqui está o problema e a solução (em Pascal) que citei no início.

E você, ama seu código?

—

[1] ^ Open Source Initiative. "The Open Source Definition"

[2] ^ MIT Sloan Management Review. "The Oh-So-Practical Magic of Open-Source Innovation"