Category Archives: paideia

books-pile

Minhas boas leituras de 2016

Apesar de ter lido muitos livros ruins em 2016, o contrário também se manifestou: peguei muita coisa boa para ler. Houve um lado positivo no atraso deste post anual: pude comprovar aqueles livros que realmente me fizeram bem. Sem demora, vamos à lista.

Configuration Management Best Practices – Bob Aiello e Leslie Sachs

cm_best_practices

É grande a chance deste ter sido o livro mais importante do ano para mim. Inclusive o mencionei na apresentação no DevCamp 2016. Em nosso trabalho com legado sem sombra de dúvidas o mais importante (junto com a análise inicial do projeto) é a aplicação de boas práticas de gestão de configuração e mudança.

O problema com esta disciplina (tenho vontade de escrever um livro sobre) é que se fala muita bobagem a seu respeito. Ainda pior: em praticamente todas as equipes pelas quais passei (com exceção, naturalmente, da itexto) esta é vista mais como um fardo que uma ferramenta capaz de alavancar projetos. Em grande parte por que as pessoas simplesmente não sabem escrever bem a respeito.

Este livro é o exato oposto: bem escrito e focado na prática apresentando diversas histórias (que os autores dizem ser reais) que batem com situações similares às que presenciei pessoalmente. Há um único porém neste livro: tive a impressão de ser um jabá monstruoso do site dos autores: http://cmbestpractices.com/ .

Vale cada centavo. Comprei na Amazon.

Software Estimation – Demystifying the Black Art – Steve McConnell

software-estimation

Se é do Steve McConnell há 90% de chance de que eu ame, e com este livro não foi diferente.

Já havia tido um contato com este livro alguns anos atrás, mas nunca o havia estudado a fundo, tal como fiz este ano. Sabe aquele papo de “no estimates”? Pois é, é bobagem, pois todo cliente quer ter uma ideia sobre quanto quer pagar.

E se você acha que sabe fazer uma estimativa, este livro te prova o contrário logo no primeiro capítulo. Tal como o próprio subtitulo diz, ele realmente desmistifica o processo de estimativa, te faz pensar o que realmente significa estimar algo. É um livro que te faz pensar e que me ajudou bastante neste ano de 2016.

Melhorou algo no qual já somos bons na itexto, que é o processo de estimativa em nossos projetos arquiteturais. Ajuda a te tirar da zona instintiva (mas não totalmente, pois isto é impossível).

Código Limpo – Robert C. Martin

codigo-limpoo

Finalmente li este livro, mas confesso que fiquei bastante decepcionado. Talvez tenha sido a tradução para o português (achei bem fraca), mas creio que a razão foi outra, e a culpa é do Steve McConnell com seu Code Complete, que li em meus anos de formação.

Sendo assim este livro não me trouxe grandes novidades, foi mais um repeteco com pouca profundidade do Code Complete. Isto não quer dizer que seja um livro ruim, muito pelo contrário. É também um bom livro de formação para quem está começando.

Na minha opinião os capítulos sobre como dar nome a variáveis e o sobre a definição de parâmetros em função já justificam sua leitura. Leia estes capítulos (faço muita pressão na itexto para que os mesmos sejam lidos por quem entra).

Não consigo pensar neste livro sem lembrar do Code Complete (ei, li as duas edições do Code Complete em inglês e português, se sou fanboy de algo, é deste livro, então desconfie do que vou dizer). Minha recomendação é a seguinte: Código Limpo te tornará um bom júnior, mas a boa leitura do Code Complete te prepara para ser um excelente pleno.

TDD com PHP – André Cardoso e Maurício Aniche

tdd-com-php

Em 2016 voltei a estudar PHP, então achei que seria interessante começar a partir do TDD. Comprei dois livros sobre o assunto e um deles foi este que adorei: vale ouro. Apesar de ser bem raso no que diz respeito ao PHP (o que é justo, visto que a linguagem é usada apenas para ilustrar o TDD), o que é tratado sobre TDD achei simplesmente excelente. Uma palavra para descrever este livro? Excelente. Merece uma review só para ele.

É excelente não por que concordo com os autores, mas por que sua leitura me fez questionar algumas das ideias que tinha sobre o modo como pratico TDD. É um texto que propicia o diálogo entre leitor e autor(es) de uma forma rica, pois é muito bem escrito.

Pelo que pude entender no site da Casa do Código há versões deste livro para .net e Java que contém essencialmente o mesmo texto, trocando apenas a linguagem usada para ilustrar os conceitos. Dos livros nacionais que li em 2016, este sem sombra de dúvidas foi o melhor: muito bom ver gente daqui fazendo coisa boa!

É o livro técnico tal como deve ser escrito: tem profundidade, te faz pensar, é cheio de referências, apresenta bibliografia decente, não é um tutorial disfarçado de livro, é técnico, tem o peso correto, apresenta a visão dos autores e seus contra-pontos (o que o torna intelectualmente honesto). Resumindo: leia.

Sobre o outro livro de PHP que li… lixo absoluto, profundidade de uma poça em evaporação, mal escrito, sem bibliografia alguma, sem qualquer referência, apresenta conteúdo equivocado…. Vai ter um review aqui no blog assim que encontrar adjetivos menos agressivos a seu respeito.

Aplicações Mobile Híbrigdas com Cordova e Phonegap – Sérgio Lopes

cordova-phonegap

Este foi outro livro que li em 2016 e gostei bastante. Sabe quando disse que detesto tutoriais disfarçados de livros? Este aqui foge à regra. Segue a forma de um tutorial, mas um muito bem escrito e que fornece um bom nível de profundidade sobre as tecnologias que aborda para quem está começando.

Cordova foi sem sombra de dúvidas uma das tecnologias mais importantes para nós em 2016, e este livro com certeza foi a melhor introdução ao assunto que poderíamos ter encontrado.

Não foi surpresa alguma para mim: o outro livro do Sérgio Lopes – A Web Mobile – indico para todos os nossos clientes e uso como referência em qualquer contratação de serviços de design que realizamos na itexto. Aliás, tenho um review deste outro livro, que pode ser lida aqui.

Professional WordPress – Design and Development – Third Edition – Brad Williams, David Damstra e Hal Stern

professional-wordpress-design-and-development1-235x300

Acho muito difícil fugir do WordPress quando precisamos de um bom CMS. Em 2016 investimos bastante em seu aprendizado e sem sombra de dúvidas este foi o melhor material que encontramos a este respeito.

Este livro valeu cada centavo que pagamos nele (foi barato, US$ 35,00 aproximadamente na Amazon). É um excelente material para quem quer se aprofundar no WordPress: se você quer conhecer as entranhas da criatura, este é O livro.

Realiza bem o que se propõe fazer: você irá entender como funcionam e como escrever plugins e templates para o WordPress. Ainda mais importante: te explica como montar o ambiente de desenvolvimento, algo que na minha opinião sempre foi uma atividade feita de uma forma bem porca.

Mais do que isto, é realizada uma verdadeira dissecação do WordPress: você vai entender como seu código é organizado, como são estruturadas suas tabelas e também é feita uma descrição (um pouco rasa, é verdade) sobre o ambiente no qual este é executado (infelizmente só fala do Apache HTTP) que para os que estão iniciando é simplesmente excelente.

Bem escrito, com excelente aprofundamento, bons exemplos, muitas referências interessantes, diversas dicas práticas. Depois da sua leitura posso dizer com certeza que subimos de nível quando o assunto é WordPress: somos muito mais produtivos agora e temos uma compreensão muito maior sobre seu funcionamento. É um daqueles livros que requer dedicação, mas que terá valido cada segundo do seu esforço.

(infelizmente o restante do material que li sobre PHP se encaixa na categoria lixo)

Gerenciando Projetos Grandes e Pequenos – Coleção Harvard Business Essentials – Richard Luecke

gestao_projetos

Pouco a pouco a ideia de que sou um empresário (um programador-empresário talvez seja o mais preciso) agora está influenciando minhas leituras. Achei que seria interessante rever diversos dos conceitos de gestão de projetos tradicional (o PMBOK).

Este livro é uma boa leitura nesta direção: entenda, você não terá aprofundamento algum nesta leitura, mas como uma simples revisão é uma leitura que vale à pena. No meu caso foi bastante importante para que eu pudesse confirmar aquilo da gestão que realmente não iremos usar o que, em si, já valeria um post.

Por ter me ajudado a validar o modo como gerimos nossos projetos estou citando este livro.

O Risco de TI – Richard Hunter e George Westerman

risco-ti

Este livro me tornou um melhor arquiteto de sistemas/corporativo/software sem sombra de dúvidas. É focado em TI, mas voltado para o público que consome nossos serviços. Essencialmente ele diz aquilo que não é dito para nossos clientes: que nós, da TI, além de provermos soluções, também somos uma fonte de riscos.

Na minha experiência infelizmente a gestão de riscos é vista como tabu na esmagadora maioria dos projetos. É como se as pessoas fossem supersticiosas a este respeito: como se simplesmente tocar no assunto magicamente materializasse as ameaças.

Os autores apresentam um framework muito interessante para ser levado em consideração na gestão de riscos envolvendo TI. Nos é provido o linguajar necessário para que provedores de serviço e consumidores possam se entender bem, tornar claras as ameaças e projetar estratégias para lidar com os riscos detectados.

O impacto deste livro em nós foi muito forte: digo com certeza que além de me ter tornado um arquiteto melhor, também me tornou um gestor mais atento, pois usamos a abordagem descrita no material para lidar com as ameaças que envolvem o nosso negócio, o que nos tem feito dormir com muito mais tranquilidade.

Recomendo sua leitura: especialmente para aqueles que pensam em gestão de riscos em TI como apenas o aspecto “segurança da informação”.

The Best Software Writing I – organizado por Joel Spolsky

the_best_software_writing_1

E este foi o livro que mais gostei de ler em 2016. Infelizmente o li com 11 anos de atraso! Joel Spolsky (você já conhece o blog dele, certo??? Se não, tá aqui o link!) organizou neste volume uma série de artigos publicados até 2005 (ano de publicação) que considera serem os textos mais bem escritos sobre desenvolvimento de software.

Sem sombra de dúvidas são alguns dos melhores artigos que já li e tratam de questões que eram extremamente relevantes em 2005 e continuam hoje, 12 anos depois. Outsourcing vale à pena? Devemos forçar padronizações em nossa equipe de desenvolvimento? Como tratar bem quem trabalha conosco? O que torna você um excelente hacker? PowerPoint nos deixa estúpidos?

Artigos escritos por pessoas que você já tenha ouvido falar: Aaron Swartz, Raymond Chen, Cory Doctorow, Bruce Eckel, Paul Graham, Why the Lucky Stiff (lembra dele?), Eric Johnson… Muitos deles autores que eu lia naquela época e que pude reencontrar neste livro. Há alguns clássicos aqui, como, por exemplo, o Starbucks does not use two-fase commit.

É um livro escrito na época em que redes sociais começavam a se materializar, então você lerá alguns artigos muito interessantes, que mostram a percepção inicial do fenômeno naquela época. Claro, talvez você se interesse mais pelo que está acontecendo neste momento, mas se curtir história como eu, este livro é um prato cheio.

O tempo inteiro a sensação que tinha ao ler estas páginas era o de “puta merda, se eu tivesse lido isto antes não teria feito aquela merda!”. Está a venda na Amazon também, então compre este negócio o mais rápido possível para não demorar os 11 anos que levei para ler isto!

Sim, este livro me tornou um autor melhor, e creio que este meu post (Leitura: modo de usar) foi fortemente influenciado pelas leituras que fiz aqui.

E que venham as leituras de 2017

Durante este ano pretendo publicar aqui algumas resenhas sobre o que estou lendo. Especialmente sobre as coisas que estou detestando ler. Espero que algum destes livros que citei te inspire de alguma forma.

E no final do ano posto aqui quais foram as leituras mais importantes do ano pra vocês novamente.

p66-2

Leitura: modo de usar

Se você acompanha este blog já deve ter notado que um dos meus assuntos favoritos é a leitura (basta ver os dois últimos posts aqui e aqui, além da minha lista anual de boas leituras do ano). Curioso que a leitura só se tornou algo realmente importante para mim bem tarde: eu tinha lá pelos meus 17, 18 anos.

Ainda mais interessante é saber que fui um analfabeto funcional até os 21 anos, quando ingressei no curso de Filosofia.

Até 2014 eu acreditava que a educação era um problema sério em nosso país, a partir de 2015 passei a ter a certeza de ser o que irá (e já está) destrui(r|ndo) esta nação. Então este post é sobre a única ferramenta que conheço e sei ser capaz de alavancar a vida de alguém: a leitura.

Como ela alavanca sua vida

grafowebadictos

Eu tinha 18 anos, três bombas em meu currículo escolar e uma vida confortavelmente vadia. Escola pela manhã, tarde e noites livres para fazer o que quisesse: ao final do bimestre corria atrás para tirar média nas provas e ao final do ano me safava de outra bomba ao passar nas constantes recuperações. Engraçado pensar como a mediocridade parecia massa naqueles dias…

Alguns conhecidos já estavam na faculdade e uns raros fazendo intercâmbio, eu ainda no segundo grau. Como eram pessoas distantes, não passavam de mera curiosidade: pareciam seres super dotados, sortudos ou beneficiados (inveja detected). Depois de um tempo muitos amigos próximos começaram a ferrar suas vidas de maneiras assustadoras, e ainda não sei como não ocorreu comigo (mortes, acidentes, doenças facilmente evitáveis, sequelas de drogas, paternidade precoce…).

Veio o primeiro vestibular, quase todos os sobreviventes passaram e eu não. Foi quando percebi que aqueles que estudavam conseguiam se distanciar de um destino desagradável. Notei algo que diferenciava os sobreviventes dos demaiso estudo.

A mediocridade agora se apresentava a mim como uma doença: aqueles que chamei de sobreviventes na realidade estavam vivendo. Eu sobrevivia: a cada ano ficava mais velho e sem saber o que fazer. Temia me juntar aos que haviam falhado de maneira tão estúpida. Na realidade, quase todos me viam como sendo pertencente ao grupo dos que ficaram.

Entrei no pré-vestibular e fiquei por quatro meses, na sequência fui para o mercado de trabalho (em uma Livraria), estudei feito um louco e passei em sexto lugar no vestibular de Filosofia. Neste processo de um ano me afastei do cemitério e desde então as coisas só melhoraram.

A leitura me apresentava alternativas que até então sequer imaginava: coisas que não te contam na mesa do bar, experiências que não são facilmente acessíveis, possibilidades que não se espera. Resumindo: os textos me expunham a objetos que só teria acesso em uma conversa se tivesse muita sorte.

Mais do que isto, ao aprender algo novo surgiam conexões entre os assuntos. Eu via, por exemplo, a maçã da Apple, que estava ligada à de Newton, que também referenciava a tentação (por isto mordida). Os videogames se tornavam mais ricos também: o cogumelo do Mario não era apenas um cogumelo mágico, era uma referência à “Alice no País das Maravilhas”.

E do ponto de vista financeiro também era ótimo: na livraria o cliente mencionava um assunto, eu sabia que ele estava relacionado a outros e quais livros os continham e nisto vendia mais, o que me incentivava muito a ler mais livros, que conhecia em meu tempo ocioso na loja. Iniciou-se um ciclo: quanto mais lia mais vendia.

Ao vender mais livros, via que o processo de organização da loja era uma merda pois o software era um lixo. Nascia o primeiro produto da itexto, que foi a Plataforma Livreiro. E então eu tinha contato com mais livros de informática para aprender a programar melhor, e com isto fui me tornando o que realmente queria ser e serei sempre: um programador.

Neste momento começo a detectar as ideias e relaciona-las entre si.

Como aprendi a ler aos 21 anos

alessandrotarsia_filosofia02_paideia2

Meus anos na escola foram descartáveis: era péssimo aluno. Creio que o ensino também não era tão bom assim pois nos quatro meses de vestibular “aprendi” tudo o que me fora ensinado nos 14 anos que passei na escola. Claro que agora eu pagaria um preço altíssimo por minha vadiagem.

De todos os cursos escolhi um dos quais a disciplina de estudo era das mais ferrenhas. Eu mal sabia português (até hoje não se sabe como aprendi inglês na infância), e de repente era necessário conhecer o mínimo do francês, grego, latim, alemão. Ainda pior: minha leitura era extremamente ineficiente. Era um procedimento estritamente linear, diversas palavras eu não conhecia e ao final dos textos creio que captava no máximo uns 20% do conteúdo.

Era claro que a coisa não estava funcionando e não iria funcionar: meu destino zumbi se aproximava novamente. O interessante é que os professores detectaram esta falha não apenas em mim, mas na maior parte da turma, razão pela qual tivemos uma matéria especial cujo objetivo era justamente aprender a estudar. Foi quando aprendi a ler de verdade.

Ok, em um primeiro momento eu conectava as ideias que conseguia captar. A partir de agora além de captar mais ideias, eu também as entendia a fundo e as questionava. Como?

Como ler um texto

256_p

Ler não é um ato passivo. Seus olhos não devem simplesmente seguir as linhas repetindo em sua cabeça as palavras impressas. O leitor deve assumir uma postura ativa diante do texto. Pode soar curioso para alguns, mas o texto não é um monólogo e sim um diálogo com o leitor.

Terminou o parágrafo ou frase, se questione: aquilo faz sentido? Você realmente entende aquilo que foi dito? Consegue pensar em exemplos que ilustrem aquela situação? Visualizou a cena? O parágrafo não deve terminar com um ponto ou exclamação, mas sempre com uma interrogação na mente do leitor.

O texto é uma pergunta: o bom autor te incita a pensar (de preferência naquele momento). Ainda mais importante: nem sempre o autor está certo. Uma leitura rica envolve a discordância do leitor em relação ao autor. Discordou? Então tenha certeza de que teve uma experiência foda.  A leitura deve ser uma discussão. E não, um livro do qual se discorda não é necessariamente um livro ruim.

(quer um bom exemplo disto? Leia Platão: em diversos pontos de seus diálogos ideias erradas são inseridas propositalmente para incitar o leitor a discordar. E o mais importante: raríssimas vezes chega-se a uma conclusão – é a aporia)

A leitura proveitosa é um processo lento. Muito lento (demorei 10 anos para terminar as 80 e poucas páginas do Tractactus do Wittgenstein, que talvez tenha sido a melhor leitura da minha vida). Requer que tenhamos o que Hegel chamava de paciência do conceito.

O leitor não pode sucumbir à ansiedade. O autor ao expor a informação o faz de uma forma construtiva, uma ideia por vez, e estas ideias são trançadas como um bordado. Aliás, sabe qual é uma das origens etimológicas da palavra texto? Tecido.

Quando todas as ideias se conectam (você chegou ao final do texto), a tapeçaria final lhe é exposta. Você questionou cada uma de suas linhas e agora tem uma visão global da intenção do autor ou, melhor ainda, da sua interpretação sobre o que foi escrito.

O vídeo ou o áudio não lhe proporcionam de maneira tão fácil este diálogo que descrevi acima. Aliás, temo que o excesso audiovisual dos dias atuais ao nos isolar desta conversa terminará por nos emburrecer. Você pode até mesmo pensar que está aprendendo com um audiobook ou vídeo, mas nossa postura é mais passiva que ativa nesses meios.

A leitura é um jogo não linear. Ler linearmente é desperdício do seu tempo. Pense naquele texto difícil, você passa pelos parágrafos em sequência? Eu não: na realidade luto com eles. Volto ao início, releio diversas vezes, pego um marcador, o risco em n partes, às vezes até mesmo xingo o autor verbalmente. Há termos desconhecidos? Busco no dicionário/internet, penso no significado e se foi bem aplicado. É o diálogo novamente.

Você também pode voltar não apenas ao início do parágrafo, mas páginas atrás. Nestes casos marco meus livros com o que tiver em mãos. No caso de PDF, melhor ainda, pois as possibilidades são ainda mais interessantes e não preciso comprar mais de uma cópia física do livro (sim, em alguns casos tenho mais de uma cópia do livro, justamente devido às anotações e marcações que faço nestes).

Um texto denso quando lido linearmente normalmente é um texto denso mal lido e portanto pouco compreendido. Pior: é seu tempo jogado fora e talvez uma baixa em sua auto estima.

Sabe aquelas notas de rodapé? Valem ouro, leia todas também. Aliás, uma dica: há livros nos quais as notas são mais interessantes que o conteúdo principal. Não foram inseridas por acaso, estão ali por que abrem trilhas de pesquisa para o leitor: estão ali por que se fossem inseridas no texto principal afastariam demais o leitor do objetivo original da obra.

Vejo as notas de rodapé como “conexões gratuitas entre ideias”. O autor está ali te mostrando que há conexão entre o texto principal e outros assuntos que se encontram fora do escopo original do trabalho.

Ainda mais interessante é quando o leitor se torna autor. Não basta apenas dialogar, você também tem de fazer suas notas a respeito do que está lendo. Por que isto é importante? Por que você só conhece algo quando de fato consegue descrevê-lo em palavras, principalmente quando forem compreensíveis por outras pessoas que não sejam você.

Quando digo notas não quero dizer resumos, digo novos textos mesmo. Nos ensinam errado a estudar: não é repetir o que o autor disse. É externalizar as suas próprias ideias, surgidas a partir da leitura como conteúdo novo. Quando chegamos a este ponto o ciclo da leitura se fechou: leitor se tornou autor, que agora irá interagir com outros leitores e por aí vai.

Este blog, por exemplo,  é a materialização deste ciclo. Basta ver os posts mais antigos, como este.

Dicas de leitura

Eu não podia terminar um post sobre a leitura sem dar dicas de leitura sobre a… leitura, certo? Então seguem dois livros que adoro sobre o assunto.

Uma História da Leitura – Alberto Manguel

uma-historia-da-leitura

O título já diz tudo: é a história do ato de ler. Este livro tem a introdução mais bonita que já li. Uma leitura maravilhosa. Além de tudo é ilustrado, e com excelentes imagens que realmente enriquecem muito o conteúdo.

Uma história inusitada para a nossa ferramenta mais poderosa. De novo: leitura maravilhosa!

Como se faz uma tese – Umberto Eco

156744_1gg

Ainda vou escrever um post sobre como estudar. Enquanto isto, alguém que fez um trabalho muito melhor foi o Umberto Eco neste livro. Nele você aprenderá como é o ofício do pesquisador/autor. Sabe aquele negócio que mencionei de ter mais de uma cópia física do livro como objeto de trabalho? Aprendi aí.

Como se faz um fichamento, como se marca um livro, como se escreve resumos, enfim, como escrever um livro técnico de uma forma minimamente decente.

Interessante que é o ofício do pesquisador antes da Internet.

Conclusão?

Este post não tem conclusões. Quis apenas expor aqui como trato o ato da leitura por saber que é uma forma eficiente de se aprender e também devido ao meu medo de que estejamos iniciando um processo de emburrecimento coletivo com o excesso audiovisual.

Se a leitura for vista como um ato interativo e não como algo passivo tenho certeza de que terei dado minha contribuição.

PS: livros interativos não funcionaram. Prova disto foi a morte da indústria do CD-ROM, que não foi substituída pela Internet.

bostacapa

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.

kico_devcamp2016

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

comentario_agradavel

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). :)

product

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.