Minha biblioteca particular é um pouco maior já que todo mês chega um novo pacote, geralmente da Amazon, eventualmente da Livraria Cultura. Este livros, juntamente com tudo o que se pode encontrar disponível na web, de tutoriais a blogs, formam minha base de aprendizado constante, além dos amigos programadores e eventos.

Vou relacionar aqui algumas das leitura (técnicas) interessantes que tive. Quase todo material que leio é inglês. Livros técnicos traduzidos são uma tijolada na cabeça. Quase todos contém erros graves de tradução. O maior problema sñao as traduções de termons técnicos que ouvimos todo dia. Esbarrar com uma tradução como “arranjos” para arrays, ou “classes internas” para inner classes torna a leitura desagradável. O cérebro tem que parar de seguir o conteúdo do livro para fazer o de-para dos termos. Além disso, dado que um livro técnico muitas vezes fica desatualizado em pouquíssimo tempo, esperar por uma tradução pode ser uma péssima idéia.

Estou relacionando os clássicos. Livros sobre framework não contam pois a lista não teria fim (EJB, Spring, Hibernate, JQuery, Struts, WebWork, JSF etc).

• Programming Ruby de Dave Thomas sem dúvida é “o” livro pra aprender Ruby.
• Agile Web Development with Rails de Dave Thomas e David Heinemeier. Ótimo início para conhecer e programar usando o framework Rails. Sugiro que pratique um pouco de Ruby antes o que tornará a leitura e programação fácil, fácil.
• The Mythical Man-Month de Frederick Brooks. Conta a estória do desenvolvimento do OS360 da IBM e como foi gerenciar o projeto. Muito interessante, um clássico.
• Refactoring de Martin Fowler. Apresenta técnicas de refactoring para deixar seu código sempre atualizado, limpo, daqueles que dá orgulho de mostrar pra mãe.
• C++ Effective Object-Oriented Software Construction de Kayshav Dattatri. Ah, bons tempos. Eu realmente gosto de C++ já que foi uma das primeiras que trabalhei e na época este livro ajudou muito. Aconselho a todos que estão iniciando sua carreira em C++.
• Code Complete de Steve McConnell. Leitura pesada. Aborda detalhes na codificação que vão desde a melhor forma de criar seus if/elses até como realizar testes unitários e documentar seu sistema.
• Design Patterns de Erich Gamma e amigos (GoF). Sem dúvida um dos que constam na lista dos de leitura obrigatória. Os exemplos são em C++/Smalltalk e se preferir outra alternativa sugiro o livro Head First Design Patterns, da Katy Sierra e Bert Bates. Fácil, didático e divertido (sim, livros de TI podem ser divertidos, seu pessimista!)
• Domain Driven Design de Eric Evans. Aborda a análise e o desenvolvimento do projeto OO através dos objetos de domínio além de patterns e boas práticas. Excelente.
• Effective Java de Joshua Bloch. Acha que sabe programar em Java? Leia este livro e depois conversamos.
• Extreme Programming Explained de Kent Beck. Fazer propaganda de metodologias Ágeis em pleno 2009 é como falar que a internet é uma “rede mundial de computadores”. Escrito pelo próprio criador da metodologia este material é o clássico sobre o assunto.
• Agile Project Management With Scrum de Ken Schwaber. Outro livro da série obrigatório, Scrum traz práticas para o desenvolvimento e gerenciamenteo de projetos (qualquer projeto).
• Joel On Software de Joel Spolsky. Coletânea dos melhores textos de um dos blogs pioneiros e mais lidos de TI desde 2000. Se não quiser ler o livro, acompanhe o blog.
• Só Por Prazer – Linux de Linus Torvalds. Há muito tempo esbarrei com este livro mas não tive curiosidade de lê-lo até 2006 quando um amigo voltou a sugerí-lo. Este livro conta a estória da criação do SO; um livro de leitura fácil e divertida para nós nerds.
• The Pragmatic Programmer de Andrew Hunt e David Thomas. Este livro é obrigatório para qualquer desenvolvedor. Espero que leiam este livro já nos primeiros contatos com progamação pois terão dicas que vão desde código, organização, metorologias, testes etc.
• Thinking in Java de Bruce Eckel, considero um dos melhores livros sobre Fundamentos Java e OO. Além de didático, o livro pode ser encontrado gratuitamente no site do autor.

Hoje participei de uma entrevista “evil”. Aquela onde você perde tempo, se estressa e ninguém ganha nada com isso. Entrevista mal elaborada, mal feita, mal aplicada.

Tudo começou quando cheguei até a consultoria. Procuro filtrar antes onde faço meu CV correr para não cair nas empresas fundo-de-quintal-zona-leste-com-pagode. Mas enfim, nem sempre o filtro funciona. Um site bonitinho engana muita gente!

Ao chegar, primeira decepção: um formulário em papel questinando dados pessoais (que estão no meu CV), últimos empregos (que estão no meu CV), idiomas (no CV), skill (no CV) e… vocês entenderam! Considerando que, apesar de eu ser uma pessoa muito calma, em São Paulo, por causa do trânsito, você sempre chega estressado nos lugares, receber um formulário destes é o começo de uma longa lista de erros. Mas já que eu estava por lá e já tinha pago R$10,00 num estacionamento só pela primeira hora, vamos adiante.

Desta vez a pessoa que me recebeu foi até que muito simpática. Não vou mencionar outros momentos “evil” como nas muitas vezes em que fiquei esperando quase uma hora para ser “entrevistado”, uma outra vez que a “menina do RH” me pediu explicações sobre a diferença entre “servidor de aplicação e Java” pois ela achava que era tudo a mesma coisa e ainda outra onde a entrevista foi “coletiva” com pelo menos 12 programadores na mesma sala de reunião com direito a falar 5 minutos; a empresa precisava agilizar o processo de contratação.

Queridas meninas que trabalham no RH, façam testes bizarros como continuar o desenho inacabado, ligar os pontos, grifar adjetivos ou questione sobre “qual nosso maior defeito”. Mas por favor, coloque alguém da área técnica cara-a-cara, frente-a-frente para nos entrevistar.

E é por isto que o post veio ao blog. Entrevistas que não sabem avaliar técnicamente o candidato, especificamente, pedidos pra que você codifique em papel.

Programação SIM; Perder tempo NÃO!

Vou classificar as entrevistas de duas formas daqui pra frente: as que respeitam e as que não respeitam os programadores.

Respeito com os programadores é pedir para que codifiquem um programa e entreguem uma solução válida, compilada e executável como aparentemente é o que encontramos por aí no trabalho. Ou alguém anda commitando código em papel, talvez num arquivo morto pixado em vermelho CVS? E código em planilha Excel? E no Word? Alguém aí é privado de consultar APIs enquanto trabalha? Livros? Internet? Algum chefe como lema “ou programa sem consultar nada ou furo seu olho esquerdo”?

Nas últimas 5 entrevistas que realizei ao longo deste ano somente 2 me pediram pra codificar. O que é lamentável, já que estava fazendo testes para programar! Porém os dois testes de programação foram feitos de forma errada: um em papel, outro em Excel.

Programar em papel já é um velho conhecido de todos os que passaram por testes em consultorias de bodyshop que não tem o mínimo interesse no profissional a não ser limar os que realmente não tem capacidade nem de escrever public static void main... . Programar em papel é tão “evil” quanto tomar chá de boldo do Chile. Simplesmente porquê programação não é a arte de decorar… programação é a arte do saber fazer (e fazer bonito).

Como mostram exames de Raio-X em quadros de artistas famosos, quando pintam um quadro, começam com um esboço a lápis. Um fundo branco. Testes com alguma côr, testes com outra, e desta forma, constroem pouco a pouco uma peça de arte perfeita. Tudo leva dias, meses, anos. A obra está pronta na cabeça do pintor mas não na tela.

Quando me pedem pra programar algum código, minha cabeça começa a pensar rápido e a juntar peças e conhecimentos que adquiri no passado e novas idéias até formar a solução para o problema proposto. Porém na prática a construção é bem diferente.
Apesar de digitar código frenéticamente toda a construção é refeita a todo momento até que o código vire uma obra de arte. Código grande? Extract Method. Construção confusa? Simplifique. Classe comprida? Componentes. Esqueceu um método? Consulte a API. Existe uma classe pronta pra isto? API. Que biblioteca faria isso? Google! Qual o melhor design para este problema? Conversa com amigos durante o almoço. Chegando em casa e ainda querendo aprimorar? Livros, blogs, conversa com amigos nerds no barzinho mais próximo!

Bem, voltando as entrevistas, a gota d’agua foi pedirem novamente pra codificar em papel (ok, era pra codificar num WordPad e depois colar tudo numa célula no Excel (oque dá na mesma)). Além disto, questões mal formuladas e respostas ambíguas as quais você não tem o direito de reclamar e questionar e discutir porquê está sozinho em uma sala minúscula e mesmo porquê a menina simpática que lhe entregou o teste é do RH e não sabe a diferença entre um HD e um cooler.

O que me deixa muito irritado é saber que estes testes são criados por programadores e serão avaliados por programadores. Então, você está sendo avaliado por um programador ruim! Isto é triste. E o resultado final é um cara ruim dando uma nota pra um teste mal feito dizendo que você não tem competência para programar um sistema que usa Struts 1.x, DAO e zilhões de código Java no JSP. Lamentável.

Como se faz uma entrevista

Eu não sou expert em contratação. Não estudei psicologia e quase tudo que li em “O Corpo Fala” eu já esqueci. Mas tem coisas que são óbvias na avaliação de alguém que irá programar.

Primeiramente, o curriculum diz muita coisa sim. Candidatos que mencionam algo como “Conhecimento avançado em Word, Excel e HTML” ou “Curso Data Byte” estão automaticamente eliminados a não ser para a vaga de trocador de galão de 20L de água. Particularmente eu olho apenas 4 coisas num CV: onde trabalhou, idiomas, palavras chaves e a organização do texto. Palavras chaves mudam de tempos em tempos. Nesta época por exemplo, 2009, palavras chaves são por exemplo Ruby, Rails, XP, Scrum, Python, Scala, Haskel, meu usuário no twitter é x, o endereço do meu blog é y. Mostram interesse pela área e um perfil atualizado, que pode ser conferido numa entrevista posterior. Onde estudaram e se estudaram em uma faculdade realmente não me diz nada. Certificações? Se foi por motivação pessoal, aplausos. Se foi esperando uma melhor colocação, perdeu tempo!

Feito o primeiro corte, existem pelo menos 3 coisas a avaliar num candidato: avalie seu código, avalie sua redação e avalie a pessoa.

Código

Mas é claro que um candidato a programador deverá programar. Show me the code! Ofereça condições de avaliar o que ele fará quando estiver trabalhando. Caso o código seja feito durante a entrevista isto inclui deixá-lo a vontade, servir um café, ter acesso a internet para consulta, uma estante cheia de livros atrás, um editor de texto e um compilador. No final, o código tem que executar, óbvio. E SE executar, aí vamos ver a estética, a lógica, a criatividade, a simplicidade, enfim, se o código é ou não de fazer orgulho pra mãe. Sente com o programador e discuta o código. Questione os pontos que podem melhorar e veja se ele dá outras soluções.

Numa das melhores entrevistas que já fiz a empresa me enviou algumas propostas de código por email. Eu poderia escolher qualquer uma, codificar em casa, enviar por email e durante uma entrevista como pessoal técnico discutir meu código! Simples e brilhante!

Redação

É incrível a quantidade de pessoas que NAUM sabem mais escrever. Obrigado Orkut e escolas públicas. Me critiquem se for apenas preconceito mas todos bons programadores que eu conheço sabem escrever corretamente. Como é possível contratar alguém que sabe escrever um código de forma simples e legível e não sabe escrever um português com a mesma elegância? Faça o candidato escrever. Sugira por exemplo para que ele escreva uma crítica sobre o último livro técnico que leu. Aí você já matou dois coelhos!

Pessoa

Por último avalie a pessoa. Como eu já disse, não sou mestre em avaliar questões subjetivas como, candidato desenhou a linha pra esquerda? É psicopata. Linha pra direita? Matou a mãe! O que eu converso com o programador é o que eu converso com meus amigos programadores. Converso sobre tecnologia específica sim, seja Java ou C# mas converso a maior parte do tempo sobre livros, blogs, linguagens de programação, frameworks, eventos, open-source, web, twitter, etc. Eu converso para saber se a pessoa gosta da área, se ela está atualizada e se vai saber o que procurar e o que fazer no dia-a-dia.

Concluíndo

Entrevistar é uma arte e fazer uma entrevista efetiva é trabalhoso. Custa muito caro pra empresa contratar alguém que não retorne todo o tempo e investimento. Por mais criterioso que seja o processo eu não conheço nenhuma empresa que acerte 100%. Só o trabalho lado-a-lado mostra como uma pessoa reage a pressão, a prazos, a demanda por inovação, a criativadade necessária para as soluções mais complexas. Contudo, fazer da entrevista um processo agradável e avaliar com critérios é o começo para encontrar bons profissionais e criar desde o início uma imagem boa da empresa e das pessoas.

Desde que minha noiva adquiriu um iBook no começo do ano passado fiquei com a impressão de que todos os outros sistemas operacionais eram inferiores, pelo menos no quesito “olha que bonitinho”.

Este ano, quando ela foi comprar seu segundo Mac (um iBook) não resisti e comprei um MacBookPro.

Quando eu estudava arquitetura comentávamos sobre a diferença (mito?) entre um projeto elaborado por um engenheiro e um projeto elaborado por um arquiteto. Enquanto um engenheiro terá como principal preocupação fazer projetos estáveis, seguros e econômicos o arquiteto irá criar projetos com base em praticidade, elegância e sofisticação. Ambos são de extrema importância para o produto final – a não ser que você não se preocupe em morar num casa bonita mas que pode desabar a qualquer momento.

Meu MBP foi criado por arquitetos.

O hardware tem sensores de luz e assim que o ambiente escurece as teclas ficam iluminadas. O mouse pad reconhece quando deslizo dois dedos e realiza a função de scroll. O hardware é fino, compacto e elegante. O sistema operacional Tiger é também elegante, amigável, fácil. Os ícones da barra de ferramenta aumentam quando deslizo meu mouse sobre eles. Tudo é bastante configurável, janelas, desktop, etc. Os aplicativos conversam de forma muito eficiente e integrada: iMovie exporta para o iDVD que monta o projeto de DVD utilizando músicas da biblioteca do iTunes e fotos do iPhoto. Aniversários cadastrados no AddressBook são mostrados no iCal (calendário).

Enfim, uma demonstração de recursos feito sob medida para o usuário final. Aliás este é o grande diferencial dos produtos da Apple. As funcionalidades são elaboradas para atender e maravilhar o usuário final (eu gostaria de ver mais programadores, designers e arquitetos pensando desta forma).

Daqui um tempo poderei escrever mais dizendo se os engenheiros também foram consultados na criação do projeto MBP & Tiger!!

Desde a segunda guerra mundial, este é o maior período em que o mundo não presencia uma guerra envolvendo as grandes potências – e a humanidade espera que continue assim por muito mais tempo. Mas nem sempre temos a graça da paz em nossos dias. Durante toda a história da humanidade, de tempos em tempos, as grandes nações entram em guerra uma contra as outras. E nestes períodos, toda a estrutura da nação fica abalada, direta ou indiretamente. Seja pela falta de suprimentos de primeira necessidade – comida, água, medicamentos – ou pela devastação das cidades. A nação fica frágil e sujeita ao desmoronamento por completo.

Talvez o maior desafio para uma nação que entrasse em guerra fosse a demanda por recursos bélicos: homens preparados para lutar pelo país e tecnologias e armamentos eficazes contra o inimigo. Até o século XVIII, a preparação para a guerra era feita durante a própria guerra, em tempo de guerra. Toda a sociedade era mobilizada para produzir recursos necessários, no menor tempo, e efetivos. Mas a partir do final do século XVIII as nações perceberam que esta estratégia não poderia mais ser utilizada com sucesso e assim, começaram a preparar-se para a guerra antes da mesma ocorrer, ou seja, preparavam-se em tempos de paz.

A área de TI também pode se beneficiar destes conceitos, pois, em um mercado em que a mão de obra qualificada é escassa (para não dizer rara), você tem basicamente duas alternativas: ou preparar-se para os projetos em tempo de paz ou preparar-se para os projetos em tempo de guerra!

A qualidade do profissional de informática no Brasil é baixa e infelizmente este fato não se resolverá a médio prazo. Nesta área, em que o conhecimento é a base da tecnologia, a formação básica e contínua do indivíduo é essencial para uma mão-de-obra qualificada e atuante. E não teremos recursos qualificados oferecendo cursos técnicos pontuais e de última hora. Isto é comprovadamente uma abordagem falha e ineficiente a curto prazo. A formação desejável para o futuro profissional de informática começa com a escola base, formando indivíduos capacitados, pró-ativos e criativos. Infelizmente sabemos que esta não é a formação existente no país. Nas escolas públicas a má qualidade do ensino parece evoluir, formando gerações de indivíduos acomodados com o descaso da educação e do aprender, tecnicamente mal preparados e culturalmente mal desenvolvidos. Não é de se admirar o crescente número de indivíduos que não conseguem interpretar um simples texto ou escrever uma simples redação sem erros gramaticais. E nas escolas particulares a situação, apesar de mais otimista, não é suficiente para formar indivíduos ávidos pelo aprendizado contínuo, criativos e competitivos.

Mas então, como posso produzir um recurso eficaz durante o projeto, ou seja, em tempo de guerra? É possível? Sim. Produzir recursos eficientes durante o projeto é possível se existir um plano bem definido de formação e treinamento dentro da empresa. Deve existir alguém responsável pelos novos recursos, dedicado em tempo integral ao treinamento e acompanhamento dos recursos e a sua gradativa entrada ao projeto ao qual estão sendo solicitados. Mas esta solução é sempre a mais arriscada. Investir em tempo de paz é sempre a melhor a melhor solução para sua equipe e sua empresa.

Para alguns pode parecer loucura investir em pessoas e treinamentos antes do início (ou certeza) de um projeto. Mas ter pessoas qualificadas e preparadas na equipe traz produtividade, segurança e eficácia na solução de projetos quando estes ocorrerem.

A formação da equipe em tempo de paz deve ser diversificada o quanto mais puder. Nenhuma tecnologia é suficientemente boa para atender qualquer tipo de projeto. Além do mais, uma tecnologia específica pode ser tão passageira quanto o tempo investido em treinamento sobre ela. O treinamento deve ser superficial em tempo de paz. E direcionado em tempo de guerra.

A equipe bem preparada será eficaz na execução de projetos. Este é o retorno por manter a equipe em tempo de paz. Mas manter equipe em tempo de paz é um esforço intelectual e tecnológico muito maior do que manter a equipe em tempo de guerra. Pois como manter a equipe motivada já que não estão com objetivos reais?

Nunca sua equipe pode ficar em descanço. Equipe que não tem nada pra fazer fica desmotivada e vai embora. Pessoas que não se importam em ficar paradas e obsoletas não serão eficazes quando chegar a hora certa e é por este motivo que soldados treinam continuamente (e arduamente) mesmo que provavelmente desejando nunca entrar em uma guerra. Objetivos, mesmo que internos, são fundamentais para manter a tropa em dia, motivada e preparada. E um líder dedicado a este objetivo é fundamental para que todos estejam se movimentando na direção certa. Além disto, a pró-atividade é fundamental. A auto-motivação, mesmo que difícil de ser praticada, deve ser perseguida pelo profissional. Vale este se preparar como se estivesse para começar um grande projeto no dia seguinte. Isto acarreta em: auto-treinamento, ficar sempre alerta com as últimas tendências e sem dúvida, gerenciar sua própria carreira. Profissionais que, em tempo de paz, passam o dia vendo email não estarão preparados para o trabalho. Profissinais que passam o dia se aprimorando, adquirindo conhecimento, implementando novo código apenas por lazer, estarão sempre estimulados e preparados.

Sempre que ouço amigos programadores defenderem com unhas e dentes a idéia de que entregar um excelente código para seus clientes é o diferencial em suas empresas ou vidas autônomas, fico pensando: afinal… o que o cliente irá ganhar com linhas de programação?

Não sei se em algum momento da história da programação as seguintes estruturas fizeram muita diferença para o cliente:

if ("true".equals(s)) {
return "verdadeiro";
} else {
return "false";
}

ou então:

return ("true".equals(s)) ? "verdadeiro" : "false";

Bem, em qualquer entrevista de emprego o candidato que escreveu o segundo código teria melhores chances que o primeiro. Mas, ignorando possíveis diferenças de performance entre um código e outro, digamos que o código acima foi entregue para o cliente e está em produção. Qual a diferença para o cliente?

Código é commodity. E por favor, código bem feito é regra, não é diferencial.

Para qualquer cliente, diferencial é serviço. Todas outras áreas já sabem disso a tempos, mas aparentemente TI ainda insiste em focar o diferencial em linguagem, estilo e produto.

Se deixarmos de lado todos os importantíssimos serviços de comunicação, marketing, acompanhamento, suporte e tudo o mais que não corresponda exatamente a programação, nós programadores temos uma grande chance de entregar para o cliente um pouco além que código bem feito. Mesmo que você seja um programador autônomo, construindo um sistema para a padaria do seu cunhado, seu diferencial não deve ser o código em si. Existe muito mais valor agregado em um sistema se por exemplo:

Você entregar para seu cliente todos os testes unitários (claro, porquê VOCÊ FEZ testes unitários), e desta forma seu cliente tem a possibilidade de adicionar novas funcionalidades (ou modificar as funcionalidades existentes) e ter o sistema testado com um simples comando. Este é um diferencial.

Você entregar para seu cliente um script de construção (via make, via ant, via maven, via seja lá o que for) e desta forma seu cliente terá total capacidade de, primeiro, não ter que baixar uma IDE ou qualquer outra plataforma que seja para apenas ter o projeto compilado e segundo, a possibilidade de ter o sistema compilado, testado, empacotado e instalado com apenas um comando. Este é um diferencial.

Você entregar para seu cliente a base do controlador de versão do projeto, ou mesmo instalar um controlador de versão (CVS, SubVersion ou seja lá o que for) e a base correspondente ao projeto em seu cliente. Porque? Simplesmente porque está aí toda a história de vida do projeto e qualquer alteração deve ser feita com base no repositório, para que esteja documentada e tenha backup. Este é um diferencial.

Bem, digamos que na padaria do seu cunhado você não tem a menor chance de instalar o CVS e fazer com que seu cunhado entenda o que é um teste unitário – e pra falar a verdade, padarias executando controladores de versão me assustam um pouco. O que importa é que o serviço está sendo agregado ao software e este software agora tem muito mais valor. Um software que possa ser baixado do SubVersion, compilado, testado e instalado em um servidor remoto com apenas um comando, sem dúvida, vale muito mais do que um arquivo compactado contendo código fonte gerado em Visual Age, na máquina do último desenvolvedor a alterar o programa (programador que aliás já não trabalha na empresa há três meses).

Algumas pessoas podem argumentar que para o cliente não faz diferença. Bem, tudo isto faz a mesma diferença para seu cliente que o impacto sobre você quando compra shampoo de empresas que não usam animais como cobais, ou um alimento orgânico. O produto pode não mudar muito, mas seu valor sim!

Venda essa idéia ao seu cliente. Até seu cunhado vai sentir que está comprando um produto muito melhor.