Category Archives: paideia

Minhas leituras ruins de 2016 – como avalio livros técnicos

Todo final de ano publico algo neste blog sobre minhas boas leituras do período (farei isto agora em dezembro). Este foi um ano de muitas leituras e, infelizmente, boa parte delas considerei puro desperdício do meu tempo. Vou falar aqui de livros técnicos:  poderia listar uma longa lista de títulos, mas creio que é mais produtivo, ao invés, expor como avalio um livro técnico.

Não será uma avaliação geral sobre livros técnicos, mas sim sobre aqueles que me interessam, isto é, livros de programação. Talvez este post soe agressivo: é por que  é. Livro é algo que levo muito a sério. Literalmente minha vida se funda neles.

Entenda, minha crítica não é a blogs ou tutoriais. É a livros, vendidos como livros, pelos quais você paga ou com seu tempo ou com seu dinheiro ou com ambos.

O tutorial disfarçado de livro

O que busco ao comprar um livro técnico: um conhecimento aprofundado a respeito do assunto que estou estudando. A leitura vai além do simples “aprender como se faz”, vai além de um mero “passo a passo”.

Não quero aprender como persistir dados usando um banco de dados NoSQL, por exemplo. Quero saber como eles são persistidos, por que são persistidos como tal, o quê motivou a tecnologia a ser daquela maneira, os limites da tecnologia. Quero que minha experiência de leitura me leve a um nível superior de conhecimento. Estas perguntas foram respondidas? Meus livros favoritos responderam a estas perguntas ou ao menos tentaram e, ao tentar, me criaram questionamentos que me motivaram a pesquisar mais a respeito.

Entre gastar meu dinheiro lendo um mero “passo a passo” a ler a documentação oficial, prefiro a segunda opção. É de graça, é fonte primária, foi escrito por quem criou a tecnologia ou tem um contato mais íntimo com esta.

Mais do que isto: um bom livro vai além. O autor irá tratar dos conceitos que envolvem aquela tecnologia, se termino a leitura aprendendo e entendendo novos termos, tive uma boa leitura, terá valido à pena.

(Wittgenstein dizia que nosso mundo é nossa linguagem. Se você aprende novos termos, seu mundo cresce. E eu não creio nisto, eu tenho certeza.)

Nada impede um livro de ter lá seus tutoriais embutidos (tem de ter mesmo!), mas estes obrigatoriamente devem ser precedidos de uma boa abordagem conceitual ou estarem mergulhados nela.

Livro é pra aprofundar, tutorial é pra quebrar seu galho. Não seja tonto, economize seu tempo!

(agora, se o livro se vende como tutorial, é válido!)

O conhecimento que surge do autor, e apenas do autor – por que a bibliografia importa (e muito)

O livro tem bibliografia? Não? Tutorial disfarçado de livro detectado.

O autor foi o criador da tecnologia? Se sim, esta tecnologia foi criada a partir do nada? Se não, aonde o autor aprendeu sobre ela? Autor que não cita fontes caracterizo em uma das opções abaixo:

  • Desonesto intelectual.
  • Alguém que não tem o preparo mínimo necessário para publicar seu trabalho.

A bibliografia, que muita gente ignora, é vital. Ela nos possibilita:

  • Ter acesso às fontes primárias que possibilitaram a escrita do livro.
  • Nos aprofundar no conteúdo do livro através da leitura do material auxiliar.
  • Validar o que está escrito. Mostra que o autor não está expondo sua mera opinião.
  • Mostra a fonte que o autor estudou para compor seu trabalho. Isto é fundamental para entender de onde vêm as opiniões do autor. Mais do que isto, mostra que o autor estudou!

(livro técnico fundado em opiniões é livro furado)

Recentemente comprei um livro sobre um dos meus frameworks favoritos e fiquei chocado com o fato do autor decorrer o texto inteiro sem fazer uma citação sequer e, claro, sem bibliografia e, claro, era um reles “passo a passo”. Se este livro fosse físico, talvez eu o usasse para limpar cocô dos meus cachorros.

Resumindo: livro não tem bibliografia? Desconfie. Sempre olhe o índice. No exemplo acima cometi este pequeno deslize e mais uma vez perdi meu tempo.

(e olha: tem autor famoso (muito) por aí que além de não citar fontes, muda o nome de conceitos conhecidos há décadas para você achar que são criação sua. Fique esperto, nem o nada surge do nada)

Autor despreparado

Aqui entra um ponto que considero ser fundamental: a responsabilidade do autor. Quando você compra um livro, o faz esperando que o autor seja alguém que tenha vivência técnica com aquela tecnologia, certo? E quando não tem? Indo além, como detectar isto?

Fácil: primeiro que hoje temos ferramentas como LinkedIn, Facebook e blogs, que nos permitem, pelo menos checar o currículo do autor. Sabe aquela orelha na qual fala um pouquinho sobre o autor? Leia aquilo! Vai te poupar muito tempo. Não tem texto falando sobre o autor ou o texto é exageradamente curto? Desconfie.

E no livro, é possível detectar a experiência do autor? Yeap, mas é algo um pouco mais sutil. Normalmente autores que não tem uma vasta experiência com a tecnologia só falam bem dela. Não expõem dificuldades inerentes ou suas limitações (e todas elas são limitadas em algum aspecto, não se esqueça).

E aí entra outra pergunta: um autor com pouca experiência no assunto está proibido de escrever livros? Respondo: pode  se for intelectualmente honesto. O que quero dizer com isto? Simples: é 1000 vezes mais válido se apresentar como alguém que está iniciando-se na tecnologia que como um expert.

Aliás, ler as dificuldades de quem está começando em algo sempre é uma leitura extremamente enriquecedora dado que o leitor normalmente também está começando e portanto se identifica com o autor e suas dificuldades. Agora, já o expert com seis meses de experiência… desculpe, é picareta.

Título enganador (ódio!)

Alguns meses atrás na itexto quis comprar para um estagiário material sobre REST. Queria que ele entendesse bem os conceitos fundamentais e também algumas técnicas essenciais.

Foi quando cometi o erro de comprar um livro sobre o assunto escrito por um autor que muito considero só pela capa: qual não foi minha surpresa ao descobrir que mais da metade do livro era sobre Java, e não REST? Por que a merda do livro não colocou no título isto, ou mesmo no subtítulo? O que eu queria? Conceitual sobre REST. O que ganhei? Java EE!  AHHH!!!!! Pior. Eu nem li o livro e já passei pra ele! Até hoje peço desculpas!

Sabe o subtítulo? Ele tem uma boa razão para existir: sua função é enriquecer o título mostrando um detalhamento melhor sobre o que aquele livro trata. Assim idiotas como eu, que compram na correria não compram errado (e não, piadinha no subtítulo de livro técnico é muito sem graça, vai por mim).

Pior: muitas vezes você deixa de ler algo excelente por causa do título enganador. O melhor livro que já li sobre uma certa linguagem de programação, por exemplo, tem um título mais ou menos assim: “Linguagem X com Framework Y”.

O livro quase não fala de Y, e o que fala sobre X é brilhante e profundo. Muita gente não o compra achando que é sobre Y. Ao questionar o autor, sabe o que ele me respondeu? “A editora me disse que venderia mais se eu também falasse sobre Y”. Resultado: cagaram no livro (e num puta livro!).

Destraduções

Existe tradução e destradução no vocabulário Kiconiano. O ato de se traduzir um livro é de uma responsabilidade monstruosa. O tradutor, além de cumprir o seu papel literário, está também cumprindo um papel social. Está tornando acessível a uma camada enorme da população que não domina o idioma original da obra acesso a esta.

Aí você, que não sabe nada de inglês lê em seu livro “tipos de costume”. Pensa se tratar de uma abordagem social ligada à computação, certo? Errado, são tipos customizados. Agora dou nome a alguns bois como exemplo. Tenho uma cópia em português do “Arte do Desenvolvimento Ágil” e outra do “Hibernate em Ação” que se eu jogar na parede grudam de tão nojentas. Recentemente tive uma experiência péssima de leitura com o “Clean Code” para português também.

Mas aqui preciso ser justo: as traduções tem melhorado muito de uns anos pra cá. Ainda há problemas? Há, mas estão reduzindo e não posso tirar daqui esta minha crítica a livros que são bons no original e um cocô na tradução.

Ausência de índice remissivo

Sabe o índice remissivo? Aquele outro índice, normalmente presente no final do livro que é usado para que a gente saiba aonde um termo aparece no texto? Parece inútil né? Né não!!!

Dado que livro é material de referência, se ele for físico não ter esta informação toma muito meu tempo quando quero me lembrar aonde um conceito foi tratado. Sabe… não tem Ctrl+F em lívro físico. E por falar em livro físico…

O aspecto do livro físico

Parece futilidade, mas não é. Ainda sou uma pessoa que compra livros físicos e considero um tapa na minha cara, enquanto consumidor, quando vejo em minha prateleira um livro que comprei há seis meses simplesmente se desfazendo em minhas mãos.

Entendam algo editoras (nacionais e estrangeiras): se alguém compra um livro físico, tem dentre os interesses a durabilidade do que está comprando. Eu, por exemplo, gosto de livros físicos como material de consulta, no meu caso são inclusive ferramenta de trabalho.

Engana-se quem acredita que livros de informática têm curta durabilidade: no meu trabalho com pesquisa de legados, por exemplo, uso material que foi impresso duas, às vezes três décadas atrás (acredite se quiser).

Livro não é como periódico que tem curta duração. Já notou que as pessoas deixam os livros expostos em estantes por anos? É coisa feita pra durar, não pra se desintegrar com o tempo!

Claro, há livros e livros. Se o valor for muito baixo e o material for vagabundo, é até válido. Já se for caro, é inaceitável. Exemplo: minha edição do Introduction do Algorithms (paguei quase R$ 400,00 na época!) do Cormen: conteúdo lindo, fisicamente um LIXO.

Concluindo

Bom, estas foram minhas leituras ruins deste ano e do passado. Talvez como autor eu tenha cometido alguns destes erros (torço para que não). Achei que seria interessante compartilhar aqui o que mais tem me incomodado.

Claro que há exceções, sempre há. Sim, há um ou outro tutorial disfarçado de livro que é livro mesmo, mas são muito raros, extremamente raros. E naturalmente, esta é apenas a minha avaliação literária de livros técnicos então, se te ofendi… problema seu.

Daqui a pouco escrevo sobre as minhas excelentes leituras que fiz em 2016. Muito livro bom!

PS: este foi um post desabafo.

Minha apresentação “Enriquecendo seu ‘legado'” na DevCamp 2016 acaba de ser publicada!

Olha que legal: o InfoQ acabou de publicar o vídeo da minha apresentação “Enriquecendo seu legado” que foi realizada na DevCamp 2016.

Nela falo basicamente como vejo código pré-existente (vulgo legados), mas assistindo de novo, é essencialmente uma apresentação sobre aquilo que mais gosto: código e as pessoas que geram este negócio.

Espero que gostem! Segue o link: https://www.infoq.com/br/presentations/enriquecendo-o-legado

Quando o comentário realmente documenta o código

Como alguém que lida com muito código fonte que não é de minha autoria, neste post vou listar algumas dicas para tornar seus comentários no código realmente úteis. São hábitos simples que, se bem seguidos, tornam a vida de quem manterá aquele sistema mais fácil e, portanto, aumentam a produtividade de toda a equipe.

Naturalmente, não irei incluir aqui todas as dicas possíveis, razão pela qual no final deste post irei citar algumas boas dicas de leitura sobre este assunto.

Não vou falar do óbvio: “o comentário deve dizer o que aquele método ou classe faz” ou “comentar o óbvio é bobagem” ou “comente apenas o necessário” pois, convenhamos, é chover no molhado ou mero “preenchimento de linguiça”.

Tudo é história

Todo software é gerado dentro de um contexto: a situação da equipe no momento em que foi criado, quem o escreveu, assim como seus conhecimentos naquela época, quais as tecnologias estavam em voga, etc.

Conhecer este contexto é muito importante para compreender as razões pelas quais o código se encontra em sua situação atual. Infelizmente, na esmagadora maioria das vezes em que encontramos o código pela primeira vez só temos conhecimento do seu estado atual se ignorarmos seu histórico no sistema de controle de versões (seja sincero, quantas vezes já percorreu aquele histórico ao ter seu primeiro contato com uma base de código pré-existente?).

Lidando com o passado – reconstruindo o histórico perdido

 

Comentários podem ajudar e muito aqui. Neste momento entra a primeira dica: use um sistema de controle de issues e replique informações deste sistema nos seus comentários. Como fazer isto? Basta mencionar o número da issue em seu comentário. Seguem alguns exemplos:


/*
Classe responsável pelo envio de e-mails no sistema /* (isto é óbvio) */
Issue na qual se encontra documentado o requisito que deu origem ao
requisito: http://meusistemadeissues/issue/825
*/
class EmissorEmail {

É bastante simples: com isto seus comentários não ficam imensos e quem estiver dando manutenção no sistema poderá entender melhor o contexto no qual aquele código foi criado. Um excelente local para se incluir este tipo de comentários é em código no qual você esteja corrigindo um bug, tal como no exemplo abaixo:

int diasEntreDatas(Date dataInicial, Date dataFinal) {
/*
Havia um erro no código abaixo que não considerava sábados e domingos,
gerando resultados inválidos.
Issue: http://seusistemadeversoes/issue/847
Alterado por Henrique Lobo - 1/3/2016 - 14:20
*/
}

Entra a segunda dica: assine seus comentários. Com isto, caso alguém encontre problemas no código que você alterou, poderá lhe procurar para obter maiores informações a respeito daquela situação que, talvez, não se encontrem documentadas no seu sistema de issues ou qualquer outra fonte de documentação.

Mais do que assinar os comentários, creio que também seja muito importante incluir a data e hora no mesmo. Isto contribuí para entender o contexto histórico daquela alteração e muitas vezes agiliza ao extremo a compreensão do problema e aplicação da solução. Esta portanto é minha terceira dica: date seus comentários.

Três dicas simples relacionadas ao histórico que, se aplicadas em conjunto, facilitarão demais a vida de todos:

  • Use um sistema de issues e o referencie em seus comentários
  • Assine seus comentários para que as pessoas possam lhe procurar (quem não tem culpa no cartório não se esconde)
  • Sempre inclua uma data nos seus comentários para saber quando a alteração foi realizada

Lidando com o passado recente

Há também aquelas situações nas quais você fez uma alteração no código mas não se sente 100% seguro a seu respeito, mesmo que tenha escrito testes para validar o comportamento esperado. É normal e te entendo perfeitamente. Nestes casos, não há problema algum em deixar comentada a versão anterior do código apenas para comparação com o que você fez, tal como no exemplo a seguir:


int soma(int x, int y) {
return x + y;
/*
Acho a versão anterior pura frescura, por isto substituí pela
minha alterantiva melhor otimizada e que não usa ifs!
Issue: http://www.meusistemadeissues.com/issue/13
Henrique Lobo - 2/2/2012 - 13:13
return (x > Integer.MAX_VALUE || y > Integer.MAX_VALUE) ? -1 : x + y;
*/
}

Lidando com o futuro (usando lembretes)

Muitas vezes a pressão do dia a dia faz com que precisemos incluir débitos técnicos em nossos sistemas. É normal: no futuro você vai resolver estas questões (se se lembrar delas).

A maior parte das IDEs hoje, além de sistemas de análise estática de código como o SonarQube oferecem suporte a um tipo especial de comentário: o “TODO”. Nunca o viu? É simples: vamos a um exemplo rápido e completamente fora da realidade.


boolean autenticar(String login, String senha) {

/*
TODO: meu gerente me obrigou a isto para o release 1.0.0 do sistema
Henrique Lobo - 12/3/2004 12:00
Issue: http://www.meusistemadeissues.com.br/issues/666
*/
if (login == "dede") {
return true;
}
}

Comentários do tipo TODO mostram pontos a serem melhorados no sistema. Na imagem abaixo podemos ver um exemplo do uso deste tipo de comentário no Eclipse (práticamente todas as IDEs possuem este recurso atualmente):

todo_eclipse

Mesmo que você não se lembre de ter feito o que estava no comentário, alguém do futuro saberá a respeito e poderá fazer algo a respeito.

Refatorando comentários?

Se você usa um sistema de controle de issues e assina e data seus comentários, passado algum tempo você talvez precise refatorá-los. Como assim?

De duas maneiras: você pode excluir aqueles comentários que envolvam código antigo (pois o tempo já mostrou que as alterações realizadas funcionaram) ou você pode simplesmente remover aqueles comentários que não agregam coisa alguma.

Resumindo: de tempos em tempos é uma boa prática apagar os comentários inúteis. Lembre que você tem o sistema de controle de versões e nele já está presente todo o histórico de alterações.

Não divulgue segredos

Parece estranho o que vou dizer, mas seu comentário pode expor segredos relativos à sua empresa ou contratante. Apesar de ter mencionado no início deste post que não iria mencionar o óbvio, me assusta a quantidade de informações sigilosas que programadores publicam em seus comentários. Alguns exemplos:

  • Credenciais de acesso a serviços ou servidores
  • “Recados” a outros membros da equipe – “Kico, resolva isto depois, ok?”
  • Críticas ao empregador ou outros membros da equipe
  • Críticas à natureza do próprio código fonte (isto você documenta como débito técnico no sistema de issues normalmente)

Quer um bom exemplo histórico? Algum tempo atrás vazou o código fonte do Windows 2000. Que tal ler o que a mídia da época comentou a respeito?

Lembre que remover commits do sistema de controle de versões não é uma tarefa trivial.

Boas leituras

Há dois livros muito bons que possuem capítulos dedicados aos comentários em código fonte:

Code Complete – Steve McConnell – Editora Microsoft (diga-se de passagem, o melhor livro que já li sobre programação em geral, leitura obrigatória) – Traduzido para o português pela editora Bookman

Clean Code – Robert C. Martin – Editora Prentice Hall – Traduzido para o português pela editora Alta Books

As duas traduções são muito boas e ambos são leitura obrigatória apesar da minha preferência pelo primeiro.

Concluindo

Não creio naquela história de que “a documentação do meu sistema é meu código”, no entanto, se for o caso, pelo menos bons comentários irão lhe ajudar na manutenção futura deste sistema.

Sobre minhas críticas ao “código como única documentação”, provávelmente será meu próximo post neste blog (ou quando encontrar uma forma mais polida de lidar com este assunto). :)

Eu e seu currículo: como o percebo

Uma das maiores honras da minha vida ocorreu ano passado quando uma imensa quantidade de pessoas se candidatou nos dois processos seletivos da itexto.

Nossa avaliação é composta por três etapas: a primeira é a seleção de currículos, seguida de uma entrevista técnica (que contém uma prova) e uma conversa final na presença de um profissional de RH. Infelizmente nosso tempo para avaliação é limitado, o que nos força a dispensar diversos candidatos na avaliação de currículos, e isto me incomoda bastante pois tenho certeza que perdemos oportunidades de contratação ali, muitas vezes por bobeira (nossa e do currículo).

Dado que nosso terceiro processo seletivo ocorrerá em breve, resolvi escrever este post descrevendo como os interpreto e minhas principais percepções. Vejo muitos posts com dicas do pessoal de RH sobre como escrever um currículo, mas poucos sobre como este documento de fato é manuseado por quem o recebe. Creio que compartilhar minhas percepções será útil para muitas pessoas. Talvez eu mostre algum erro que cometo neste post: sinta-se livre para me enviar suas críticas, pois são todas muito bem vindas.

Objetividade

No nosso segundo processo seletivo recebemos quase oitenta currículos. Além de avaliá-los, também temos de atender nossos clientes, e isto limita ainda mais o tempo. Alguns dos currículos que recebemos são verdadeiros artigos. Acho interessante a pessoa se esforçar em sua auto-descrição, no entanto quando o currículo é longo demais a impressão que tenho é a de que estou lidando com alguém prolixo, o que não é bom.

Se nossa vaga é para desenvolvimento de software, confesso que não me interessa tanto quais são seus hobbies e séries de TV favoritas. Este tipo de informação talvez mostre suas soft skills (falarei mais sobre isto adiante), mas dado que não lidamos com o ramo de entretenimento (ainda), estes dados não agregam.

Outro ponto importante é a atenção ao cargo oferecido. Se é para desenvolvimento e você nos envia seu currículo no qual só há experiências em outras áreas, é altíssima a chance de não te chamarmos para uma conversa. A não ser, é claro, que no texto de apresentação (sempre é útil) você nos diga que está interessado em mudar de área e demonstra real interesse pelo que fazemos e as atividades que esperamos de você aqui.

Não só a área, mas o nível de experiência pedido também deve ser levado em consideração. A vivência descrita no currículo deve estar de acordo com a que expomos na descrição da vaga.

Soft skills

A grosso modo, são suas capacidades não técnicas ou indiretamente relacionadas ao que esperamos na vaga como, por exemplo, facilidade de comunicação e trabalho em equipe. Na minha opinião a mais importante é a capacidade de comunicação, e no caso dos currículos, textos legíveisem bom português demonstram boa parte desta habilidade.

Vou ser curto e grosso: nunca vi alguém escrever em seu currículo algo negativo sobre si mesmo. Ainda não encontrei descrições como “sou preguiçoso”, “odeio gente”,  “curto ser um babaca”, “persigo meus colegas” ou coisa similar.

(a única exceção foi em uma entrevista anos atrás na qual a pessoa disse ser preguiçosa)

Descobrimos estas características do candidato em dois momentos: nas conversas que temos após a análise do currículo ou, no pior dos casos, durante o período de experiência caso seja contratado, ou seja, no texto do currículo estas descrições não agregam.

Experiências

Sempre agregam bastante no currículo quando bem descritas, especialmente quando o candidato nos conta o que costumava fazer nas empresas pelas quais passou e as realizações de que se orgulha.

Alguns currículos contém contatos para referência. Isto é muito útil, pois nos ajuda a validar quem você realmente é e também nos mostra sua segurança a respeito de si mesmo. Não é um ponto obrigatório, mas com certeza agrega bastante (e positivamente).

Qualquer experiência fora do trabalho também é muito bem vista. Exemplo: ter um blog, participar de projetos open source, palestrar, enfim, demonstrar seu interesse na área através de atividades que sejam relacionadas à área de atuação da vaga.

Claro, se for um cargo para alguém em início de carreira, não possuir experiência profissional alguma não desqualificaria o candidato, o que me faz lembrar do…

Meu primeiro mico em uma entrevista de emprego

O primeiro trabalho pago que tive na vida foi como “tomador de conta” do gabinete de um candidato a deputado federal aqui em Minas Gerais. Minhas tarefas envolviam cuidar do gabinete (varrer, manter o lugar limpo, garantir que o banheiro estava usável), receber as pessoas e passar recados. Isto e nada mais. Este trabalho durou uns dois meses.

Veio minha primeira entrevista de emprego e não sabia o que colocar no currículo, pois só tinha esta experiência. Então, escrevi: “Responsável pela administração da qualidade do ambiente do gabinete do deputado federal (ele foi eleito) Fulano de tal“. Que título lindo, pensei, e fui lá fazer minha primeira entrevista de emprego em uma livraria.

O dono da livraria (uma figura simplesmente GENIAL) olhou pra minha cara, começou a gargalhar e soltou o: “Nossa, como você é uma pessoa importante com seus 19 anos hein?”. Fui contratado, mas até hoje sou zoado por isto. Se for iniciante, evite a zoeira, muitas vezes ela pega e dura anos. :)

Exponha seus conhecimentos reais

Uma vez aprovado seu currículo, iremos validar o seu domínio nos conhecimentos citados em nossa avaliação técnica. É fundamental expor aquilo que você já conhece para nos ajudar no processo seletivo, mas igualmente importante nos contar o quanto você domina os assuntos listados.

Este é um ponto bastante delicado: como você pode expor seu domínio sobre um assunto de forma precisa? O ideal é usando alguma referência que não seja si mesmo. Vale aqui as experiências profissionais passsadas, desempenho acadêmico, publicações, blog pessoal e até mesmo pontuação em concursos e sites de desafios de programação. Se você afirma possuir, por exemplo, “sólido conhecimento em X”, de que modo esta base foi construída? “Eu acho que tenho” não é resposta.

Errar algumas questões em uma prova técnica não invalida seu conhecimento. Na realidade, sempre é dado um desconto durante a avaliação da prova, levando-se em consideração a ansiedade natural do candidato. Curiosamente, acertar também não valida o conhecimento tanto quanto se imagina, pois não é raro um acerto por sorte. Na realidade apenas a prática valida.

E justamente por que apenas a prática valida seus conhecimentos é que lhe digo: tentar burlar uma prova ou levar o avaliador na conversa e ser contratado talvez seja a pior experiência pela qual você possa passar.

Formação

Se o cargo exige alguma formação, seu currículo deve estar de acordo com a mesma. É comum incluirmos em nossos currículos certificações e treinamentos. No caso de treinamentos, é muito interessante que também seja exposto seu nível de aproveitamento no que foi ensinado.

Não há problema algum dizer que fez treinamento na tecnologia X mas nunca aplicou aqueles conhecimentos na prática ou mesmo não os assimilou como gostaria. Na realidade, isto é louvável. Quem lê em seu currículo a presença destes cursos supõe que você já domina os assuntos tratados se não fizer nenhuma observação a respeito.

Creio que não seja necessário mencionar aqui que mentir nestes pontos é uma das maiores imbecilidades que alguém pode cometer, certo?

Fontes adicionais

Vejo o currículo como um primeiro contato com o profissional, razão pela qual deve ser o mais objetivo e curto quanto possível. No entanto, fontes adicionais incluídas no texto agregam bastante: LinkedIn, blogs, participação em comunidades, etc.

O LinkedIn possuí, por exemplo, o preenchimento de perfil super completo, o que incluí os projetos em que o indivíduo participou, publicações, indicações e muito mais. Com certeza é a melhor fonte adicional que qualquer um pode incluir em seu currículo (em muitos casos, o vejo como a versão “full” do documento).

No caso de redes sociais, raramente Facebook ou Google+ nos agrega algo (não há nem razão para incluir isto no currículo, a não ser que você mantenha uma comunidade lá ou seja ativo nesta). Em raríssimos casos o Twitter nos agrega.

Depois da contratação

Seu currículo não é esquecido, pois pode será usado em sua avaliação durante o período de experiência. Por isto é tão importante ser o mais objetivo e verdadeiro na escrita deste documento. O currículo é uma proposta de trabalho, do que você está oferecendo: suas habilidades e quem você diz ser.

E aqueles que não foram contratados, mas foram avaliados? Tem seus currículos guardados para o próximo processo seletivo. E são chamados para conversar conforme as oportunidades vão surgindo.

E aqueles que enviaram seus currículos após o processo seletivo? Serão avaliados no próximo.

Concluindo

É importante salientar que, ao menos no meu caso, o currículo não é avaliado só por mim: mais pessoas o lêem, até para que possamos bater nossas percepções e chegar a algum acordo antes de chamar o candidato para uma conversa.

Como disse no início deste post, estas são as percepções que tenho ao avaliar um currículo. Creio que mais empregadores sigam caminhos similares aos que descrevi aqui e com certeza há falhas nesta leitura, razão pela qual gostaria muito de saber a opinião de vocês a respeito.

Minhas boas leituras de 2015

Não me lembro de um ano que tenha me ensinado tanto quanto 2015: realizei meu grande sonho de me dedicar totalmente à itexto (aguardem o post). Mais da metade das coisas que discordava até então se mostraram necessárias (virá um post) e minha visão a respeito do mundo foi impactada de maneiras que eu jamais poderia imaginar.

É curioso olhar pra trás e perceber um paradoxo: foi um ano pobre de leituras. Li muito menos, talvez devido ao fato de finalmente ter publicado meu segundo livro (Falando de Grails), o que é sempre bastante exaustivo para mim. Outra razão foi a itexto: este ano nosso foco foi aprender a como gerir o negócio da melhor maneira possível (e a isto agradeço à Nanna, pra variar), o que demandou boa parte do meu tempo.

Conservadorismo, direita, esquerda, centro… o que sou eu?

Em 2015 ficou claro que eu não sabia o que significava ser de direita ou esquerda. Ainda pior: percebi que termos como “conservadorismo” e “reacionarismo” me incomodavam sem que eu soubesse o que de fato significavam. E o mais interessante: o sentimento positivo que sentia pela “esquerda” também não tinha qualquer fundamento teórico. Como eu podia gostar ou desgostar de algo que não conhecia? Quem sou eu de fato?

Roger Scruton e o conceito de faking (falseamento)

Roger Scruton at Edinburgh International Book Festival 2014.  13th August 2014 Picture by Pako Mera/Writer Pictures WORLD RIGHTS (Writer Pictures via AP Images)

Roger Scruton

Alguns amigos (Túlio e Cyrio) me indicaram um autor chamado Roger Scruton, que se apresenta como conservador. Curiosamente, não me foi indicado devido a esta minha busca política, mas por meu interesse em estética.

Scruton nos apresenta um conceito que achei fascinante e se aplica perfeitamente à área de TI e desenvolvimento: “faking”. Grosseiramente o descrevendo, é aquela situação que com certeza leitores mais experientes já presenciaram: alguém se apresenta como profundo conhecedor de um assunto sem saber de sua própria ignorância e os demais ao seu redor – honestamente ignorantes sobre o tema – abraçam o indivíduo como uma fonte real de conhecimento (isto me motivou a escrever este post).

O autor trata de artes plásticas, performáticas e arquitetura, mas conforme ia lendo seus artigos sobre o assunto e participando de alguns eventos da nossa área ficou nítido que seu conceito de “faking” se aplica muito bem à nossa realidade (com certeza virá um post sobre isto).

Você pode ouvir o próprio Scruton falando sobre o assunto neste excelente episódio do programa “Point of View” da BBC: Faking it.

Há também um excelente artigo em inglês: “The Great Swindle”

E também há um livro que ainda não li: Beauty

Scruton conseguiu verbalizar uma intuição que tenho há anos.

Scruton conservador

scruton-conservador

Coincidentemente, no mesmo ano a editora Record publicou uma tradução do livro “How to be a conservative” do Scruton: comprei na hora. Finalmente pude entender o que o conservadorismo realmente significa e, ainda mais importante: identifiquei, chocado, muitos traços conservadores na minha personalidade (será que minha paixão por legados vêm daí?).

Scruton faz uma análise muito profunda do conceito de conservadorismo, mas você deve levar em consideração o fato do livro ser focado no contexto inglês, que é bastante diferente da nossa realidade nacional. Se conseguir levar em consideração este fato e não tomar o livro sem uma boa pitada de sal, com certeza aprenderá bastante com ele.

Finalizada a leitura percebi que tinha uma visão muito preconceituosa a respeito dos conceitos de direita, conservadorismo e reacionarismo. Mais que isto: percebi traços conservadores e mesmo reacionários em mim, o que me leva a assumir isto aqui publicamente sem qualquer vergonha.

Leia o livro antes de me julgar. :)

Bobbio como contraponto

direita-esquerda-bobbioScruton é tendencioso, então para contra-balançar, que tal ler um autor de esquerda falando sobre direita e esquerda? Reli “Direita e Esquerda” do Norberto Bobbio. O autor busca definir os dois termos no seu livro. Não me impactou tanto quanto a leitura de Scruton por não ser um texto novo para mim: comprei o livro em 2003 e nunca o havia lido com atenção.

É uma excelente leitura: no Brasil é publicado pela editora Unesp. Bobbio explica os conceitos do ponto de vista histórico e ideológico em um texto bem curto.

O que percebi? Que tenho familiaridade com alguns ideais de esquerda e direita. Minha busca pela minha própria definição ficou ainda mais confusa. :)

Leituras técnicas

Um ano de blogs

Finalmente coloquei o /dev/All no ar: um agregador de blogs nacionais sobre desenvolvimento de sistemas, TI e assuntos relacionados. O site cresceu significativamente: conta hoje com bem mais de 100 blogs e já estamos caminhando para os 200.

Li posts excelentes no site e (re)descobri alguns blogs que, acredito, vale muito à pena citar aqui:

Dado meu tempo reduzido, /dev/All foi vital para que me manter atualizado durante o ano. Estes foram os blogs que mais gostei e que me lembrei enquanto escrevia este post. Tenho certeza de que fui injusto ao não mencionar mais alguns, mas no futuro corrigirei este erro.

Docker e minha volta ao Linux

docker

Foi a tecnologia que me fez voltar ao Linux com força total e a que mais me impressionou nos últimos anos. De repente me vi com uma ferramenta que me permite realizar experimentos de configuração em servidores com uma produtividade que jamais imaginei ser possível.

Docker me deu a desculpa ideal para que eu pudesse finalmente me aprofundar no Linux. Seguem os textos e livros que mais gostei.

Docker

Docker Jumpstart – Foi o texto no qual realmente aprendi a usar o Docker.

Getting Started with Docker – Versão júnior do texto acima. Leia o Jumpstart primeiro, use este como referência

(em breve deve sair um guia da itexto sobre Docker)

Linux

Foi em 2015 que finalmente resolvi criar vergonha na cara e aprender a escrever shell scripts no Linux. Estes textos foram fundamentais:

The Linux Command Line – Um livro gratuito maravilhoso sobre a linha de comandos do Linux. Finalmente aprendi como dominar esta criatura e já escrevo alguns scripts com ela. Foi muito importante para que eu pudesse tirar um proveito ainda maior do Docker.

Conquering the Command Line – outro livro excelente sobre o mesmo assunto. Não tão bom quanto o primeiro, mas bom também. :)

AWK

Das linguagens de programação que vi em 2015 a que mais me impressionou foi AWK. É um monstro que provávelmente está instalado no seu Linux e você nem nota. Escrevi inclusive um post a seu respeito, que você pode acessar neste link.

Posso dizer com segurança que AWK me tornou uma pessoa mais produtiva em 2015. Interessado em conhecer a criatura?

An AWK Primer – Este livro está no Wikibooks e é um bom início.

GAWK: Effective AWK Programming – Trata-se do manual do projeto GNU para a sua implementação do AWK. A leitura é bem tranquila e também me ajudou bastante.

Git

Em 2015 troquei o Mercurial pelo Git. Inicialmente por que todos os nossos clientes preferiam o Git, depois por que comecei a estudar mais a fundo a ferramenta e aprendi diversas coisas interessantes a seu respeito.

Um dos resultados foi o primerio Guia da itexto: Usando o Git. Já estou trabalhando na segunda edição.

E o que mais gostei de ler sobre Git este ano?

Pro Git – Um livro gratuito escrito por Scott Chacon e Ben Straub que irá lhe expor essencialmente tudo o que você precisa (e não) saber a respeito do Git.

JavaScript

Por mais estranho que eu ache as pessoas amarem hoje uma linguagem que era odiada há poucos anos atrás, não pude deixar de me aprofundar um pouco mais no assunto. O que li e gostei?

JavaScript: the Good parts – Finalmente li este livro do Douglas Crackford. Me impressionou? Não, mas é um livro interessante. Gosto muito dos diagramas que ele usou para descrever a linguagem.

AngularJS – Comecei a usar o AngularJS. Após passar por diversos livros e textos horríveis sobre ele, acabei ficando com a documentação oficial mesmo, que foi a melhor coisa que li a respeito.

Dominando JavaScript com jQuery – escrito por Plínio Balduino e publicado pela Casa do Código. É um dos melhores livros sobre JavaScript que conheço (melhor que o do Crackford na minha opinião). Voltei a este material algumas vezes este ano. Ei: é um livro escrito aqui no Brasil com qualidade internacional! Se ainda não leu e quer entender JavaScript, LEIA!

Nota importante: minhas piores leituras

Minhas piores leituras foram relacionadas a JavaScript. Li muito material HORRÍVEL este ano, especialmente o relacionado a NodeJS e AngularJS. Se um dia escrever um texto sobre minhas piores leituras com certeza haverá uma longa seção sobre este conteúdo.

BASIC

BASIC

Sim, você leu certo: este ano estudei BASIC. Não para usar a linguagem, mas para escrever melhores textos técnicos (e outra razão que exporei abaixo). Por que melhores textos técnicos? Leia minhas sugestões de leitura e você entenderá. ;)

DartMouth Basic Manual – Publicado em 1964. É um dos textos introdutórios sobre programação mais didáticos que já vi. Repare que é uma fotocópia, e com marcações sobre a mesma! Pura simpatia.

Linguagem BASIC – MSX – Pouca gente se lembra do MSX: sou uma delas. E este foi o primeiro livro de programação da minha vida, quando eu tinha algo entre 6 e 7 anos.

10 PRINT CHR$(205.5+RND(1)); : GOTO 10 – E que tal um livro sobre um algoritmo escrito em BASIC que imprime um labirinto? Leitura divertidíssima para aqueles que, como eu, curtem história da computação. Excelente leitura!

O BASIC nos anos 80 era usado como ferramenta educacional para crianças (fui uma destas). Sabe este esforço recente de popularização da programação? O pessoal já fazia isto 30 ou 40 anos atrás (na minha opinião com muito mais competência e, talvez, honestidade).

Houve um curto período de tempo em 2015 no qual iniciei a implementação do meu próprio BASIC para a JVM, mas as motivações para este projeto e o que ocorreu são assunto para um outro post (esta era a segunda razão).

(que se dane o Dijkstra: eu curto BASIC!)

O que lerei em 2016?

Desejo a todos vocês um 2016 como foi meu 2015: rico em aprendizado e experiências que com certeza me tornaram uma pessoa melhor (assim espero!).

Gostaria muito de saber aqui quais foram as melhores leituras de vocês. O que mais gostaram de ler? Feliz ano novo!

Como aproveitar ao máximo um palestrante

Então você está assistindo a uma apresentação em um evento ou um consultor está na sua empresa mostrando algo que pode tornar sua vida melhor. Terminada a palestra, em uma conversa entre colegas você critica o conteúdo ministrado e obtém como resposta algo como o clássico “quem é você para criticar fulano?”.

Ou então algo ainda mais interessante: a apresentação lhe deu um novo ânimo pois agora sabe que seus problemas acabaram! Você quer aplicar aquele conteúdo em sua vida e no dia seguinte começa a luta. Tudo nos primeiros momentos vai maravilhosamente bem, mas logo você nota que as rosas que lhe venderam possuem mais espinhos do que lhe contaram.

Sou consultor e de vez em quando palestro em eventos ou empresas. Como consultor estou cansado de ver pessoas tendo prejuízos monstruosos devido a algo que foi mal compreendido ou dito em uma apresentação. Como palestrante sempre temo que o que digo gere muito prejuízo a quem me ouviu falar (e creio que todos os palestrantes deveriam ter esta preocupação).

Neste post lhe darei algumas dicas para não cair nestas armadilhas. Como tirar máximo proveito do palestrante, aquela pessoa que aparenta ser tão mais carismática que nós?

Termos fundamentais

Este post gira em torno de dois conceitos que considero fundamentais quando vou avaliar qualquer palestra.

Responsabilidade e irresponsabilidade

amigo-da-onca

Simples e direto: responsável é aquele que será procurado após suas ações serem executadas, tendo estas sido bem sucedidas ou não. Já o irresponsável executa suas tarefas e parte.

Na esmagadora maioria das vezes o palestrante expõe o tópico e sai. Ele irá embora, mas a impressão permanece nos ouvintes. O expectador é o maior responsável pelo que faz com o conhecimento transmitido.

Arrogância

miniature-pinscher

No livro “Direita e Esquerda”, Norberto Bobbio dá a melhor definição do conceito que conheço: é “a confiança excessiva nas próprias habilidades”.

Eu e você já fomos arrogantes ao menos uma vez. Um esforço honesto de memória nos exporá situações nas quais realmente acreditávamos conhecer um assunto e transparecemos isto a alguém, para depois descobrirmos que não eramos tão bons assim naquilo.

Quem está falando?

who_is_talkingA pessoa é mais que um nome, e a pesquisa a respeito do passado do palestrante é um excelente detector de arrogância. Tudo bem que existem exceções, mas como levar a sério alguém que se apresenta para falar de um assunto, por exemplo, desenvolvimento de software e se apresenta assim?

Fulano Simpático é profundo conhecedor do assunto X e possuí três anos de experiência como desenvolvedor

Você busca o currículo da pessoa e descobre que destes três anos, um foi como estagiário, dois em apenas uma empresa e que o assunto X tem pelo menos 15 anos de existência. Se a apresentação for algo como a exposição da sua experiência, talvez seja interessantíssimo: é fascinante ver as dificuldades enfrentadas por iniciantes, mas se for uma aula detalhada sobre o assunto… desconfie: a genialidade infelizmente não é um artigo popular no Universo.

Havendo tempo, uma busca rápida pelo LinkedIn, blog, artigos publicados ou coisa similar já expõe bem a natureza do palestrante. Este é o primeiro passo: detecte a possível arrogância do sujeito. (redes sociais como Facebook não contam: é lugar de se postar trolagem (o meu pelo menos é)).

Experiência não é tudo: o mínimo de consistência também é importante. Se um dia a pessoa fala sobre X, em outro sobre Y, depois sobre Z, A, D, H, E, J  e os assuntos são distantes uns do outros, vejo algumas opções:

  • Estou diante de um especialista em porra nenhuma
  • É alguém que curte novidades e divulgá-las (e isto é positivo, desde que não se venda como profundo conhecedor dos assuntos tratados)
  • Dificilmente a pessoa teve tempo para trabalhar efetivamente com os assuntos tratados na prática

Mas conhecer melhor o passado do palestrante te traz outra vantagem: te ajuda a fazer melhores perguntas. Entenda: ninguém conhece a totalidade de um assunto, pois todo conhecimento é definido pelo contexto em que o sujeito se encontra. Se você me perguntar como se deve aplicar Groovy e Grails no processamento de Urânio não vou saber te responder.

E sabe qual a vantagem de boas perguntas? Elas te dão um monte de conteúdo. 

E o lado feio?

duascaras

Você vê a solução e ela parece linda. Mas não tem nenhum porém, nenhum lado feio, nenhuma limitação??? Na minha opinião esta é a pergunta mais importante: quanto custa?

Nos últimos anos a ausência desta pergunta gerou prejuízos imensos que pude ver em primeira mão. Seguem dois exemplos:

  • Equipes que abandonaram completamente o modelo relacional e abraçaram alguma solução NoSQL, como MongoDB, para depois perceberem que coisas “bobas” como integridade referencial não são algo “careta e ultrapassado”.
  • Empresas que realmente acreditaram que seria possível reduzir a complexidade dos seus sistemas adotando micro-serviços que se pegam em uma situação BEM pior que a anterior por que não se falou muito a respeito dos custos envolvidos.

Quando o palestrante não fala muito a respeito dos trade-offs, isto não quer dizer que a pessoa é má intencionada: está apenas apresentando seu aspecto irresponsável e talvez arrogante. Terminada a apresentação, a bola está com você.

Normalmente a pessoa está tão enamorada pelo assunto apresentado que não consegue ver suas limitações: qualquer um que já tenha se apaixonado sabe do que estou falando.

(dica: se o palestrante tem um slide mostrando os custos da tecnologia e o expõe rapidamente, peça para que fale mais a respeito do assunto ;) )

Desconfie do carisma/”atitude”

poison

Já reparou que na natureza as coisas muito coloridas (como a flor acima) normalmente são armadilhas? Numa palestra o que realmente interessa é o conteúdo, mas há aqueles palestrantes que são simplesmente excessivamente carismáticos.

São pessoas divertidas, simpáticas, engraçadas, bem articuladas. Ou então podem possuir aquela postura mais radical, quase agressiva. Aquele sujeito “adoravelmente desagradável” que conquista a sua simpatia. É difícil vencer esta tentação. Todo mundo quer ser como aquela pessoa, e se ela diz algo, deve ser o correto, certo? Certo?

dr_house

Minha dica? Dou tempo ao tempo. Tento resistir ao carisma e prestar atenção no conteúdo. Espero passar um mês e tento me lembrar do conteúdo. O que mais me impressionou? O palestrante ou o conteúdo?

(nos meus 36 anos fica claro para mim que a maior parte das pessoas que me influenciaram eram na realidade tolos carismáticos (e esta descoberta não foi decepcionante, mas sim um alívio))

Pergunte (não precisa ser na hora)

Eu sei que fazer uma pergunta em público pode dar uma vergonha danada. Talvez você fique com medo de dizer alguma bobagem na frente de todos e isto muitas vezes te cala. Mas quem disse que a pergunta precisa ser feita durante a palestra?

Todo palestrante expõe seus dados de contato. Se acha que não é interessante perguntar naquele momento, faça como eu: anote todas as suas dúvidas e em seguida lhe envie um e-mail. Nunca encontrei alguém que não me respondesse, por mais importante que fosse.

Estude antes da apresentação

Quando vou a uma palestra que realmente me interessa costumo estudar um pouco sobre o assunto antes do evento. Isto me ajuda bastante a fazer melhores perguntas e na compreensão do que vai ser exposto.

Não precisa ser um estudo profundo: muitas vezes uma leitura de 20 minutos antes do evento já é suficiente pra te contextualizar.

Peça pelas fontes

Dificilmente todo o conteúdo apresentado foi criado pelo palestrante. Pra tirar máximo proveito do que foi exposto sempre peça as fontes usadas na apresentação. Muitas vezes o que mais aproveito em uma palestra é justamente a bibliografia!

É uma oportunidade excelente de entrar em contato com textos que dificilmente você ouviria a respeito se não tivesse participado do evento. Se o autor não expor suas fontes, apenas pergunte por alguma sugestão de leitura.

Lembre que a bibliografia nem sempre é explícita, mas sempre está presente. Basta prestar atenção nos nomes citados durante a palestra.

Existe mais de uma realidade

infinitas_terras

Conhecer o passado do palestrante traz outra vantagem: você passa a entender sua realidade, que sempre é distinta da sua, e este é um ponto importantíssimo.

Muitas vezes o palestrante é criticado por que o ouvinte não consegue por em prática aquilo que foi exposto. Uma razão comum (quando bobagens não foram ditas) é o fato de estarem em realidades diferentes. Exemplo clássico: alguém que trabalhe em uma empresa gigantesca falando sobre sua infraestrutura de servidores. É uma realidade restrita, dado que a esmagadora maioria dos ouvintes comemora e muito se tiver mais de um (mesmo com a cloud).

Então para tirar máximo proveito do que foi exposto é fundamental a contextualização. O que está sendo apresentado funciona (ou não) dentro do contexto do palestrante. É sua responsabilidade portanto, se quiser aplicar o que viu, adaptar (se possível) o que foi exposto para a sua realidade.

Seja crítico e valorize suas próprias experiências

Não é raro estar em uma palestra e presenciar o palestrante desdenhar um conjunto de conhecimentos que fazem parte do seu dia a dia. Neste momento você deve se fazer o seguinte questionamento: se é tão ruim assim, por que têm funcionado para nós?

Esta é uma pergunta importantíssima. Já cansei de ver o clássico momento “Java sucks, use X que é melhor”. Se não for apresentada uma excelente justificativa para a troca, pulo fora na hora.

Não estou dizendo para você ser um reacionário: apenas para não desvalorizar os conhecimentos que já tem. Não é o fato do outro estar com o microfone na mão que o torna o dono da verdade.

Concluindo

Palestras e eventos são uma fonte praticamente infinita de riqueza intelectual quando bem aproveitados e de prejuízos imensuráveis se o ouvinte não adotar uma postura ativa, questionadora e crítica.

Ter uma postura crítica diante de uma apresentação não deve ser visto como uma postura negativa, mas sim como a tentativa de se extrair o máximo possível de eventos cuja finalidade é nos formar.