Hey dev, quantos livros voc leu este ano?

Existe uma faanha que o desenvolvedor normal parece no possuir, a interpretao de texto. Notamos isso no dia a dia, no twitter quando voc tweeta A e seus comparsas da bolha dev entendem B e te respondem xingando com C. Algum que passou 40 minutos em contato com a bolha j reparou nisso e acho de suma importncia isso ter alguma mudana.

Neste post, vou apresentar alguns argumentos sobre o porqu da leitura influenciar na sua carreira (e na convivncia humana, pois voc dev, no um pato).

Todas suas tarefas sero escritas por um humano.

Seja um PO, um Scrum ou um Tech Writer algum vai ter que escrever aquilo para voc como desenvolvedor inserir no cdigo. Grande parte dos erros de softwares hoje so causados no pela inabilidade do desenvolvedor e sim pelo no entendimento da task passada. O que parece inofensivo, na curva do desenvolvimento de um projeto acaba sendo custoso, um desenvolvedor que requer correo de parmetros de regras de negcio simples toma o tempo da equipe em testes, correes, reavaliaes, manuteno e por fim critrios de aceite. No seja esse cara, leia, releia, pense e se surgir alguma dvida, pergunte ao seu PO ou pessoa responsvel.

O fato de cada vez mais existirem reunies que poderiam ser um email vem do fato de pessoas no entenderem o que o email tem a te dizer.

Ningum quer conversar com dev, no final das contas, a nica tarefa que o desenvolvedor deveria focar com necessrio gasto de tempo para o desenvolvimento seria na programao do seu produto. Na prtica, temos diversas reunies ritualsticas que muitas das vezes so necessrias, porm em outras tantas poderia ser um e-mail bem redigido. O que no acontece com muita frequncia pois h uma Gap de informaes onde o programador tem que ser avisado e pelo mesmo motivo de se existir um cara somente para redigir tarefinhas, h a necessidade de se haver outro cara (ou o mesmo cara, sobrecarregado) para passar essas informaes de maneiras concisas a equipe. E l se vo 40 minutos de todo mundo que deveriam ser economizados com um e-mail de 4 linhas, mas desenvolvedor no ler.
Cada vez mais informaes tem que se aparecerem mastigadas e mais pessoas para fazer isso e mais tempo do desenvolvedor e mais reunies e isso tudo um saco. Tente sempre manter a comunicao assncrona e saber tirar dvidas de maneira a no se perder tempo em uma reunio e sim redigindo um e-mail.

A rea no te ensina a ter pensamento crtico.

Quer um exemplo? Quantos posts nessa rede ou no LinkedIn criticam o Clean Code sem ao menos ponderar que surgiu em uma poca que o desenvolvimento de cdigo era quase feito por primatas que escreviam nome de variveis como x e y sem pudor algum? O Uncle Bob surgiu com um livro de prticas de programao que no passa de um cdigo de etiqueta de desenvolvimento. Em momento algum a limitao para se seguir aqueles bons costumes foi mencionada em algum dos seus livros, ao contrrio, ele sempre abre o pressuposto de que h uma constante evoluo dentro do campo do desenvolvimento mas que existem coisas como regrinhas de nomes de variveis que devem ser seguidas at o presente momento, como h nas regras de etiquetas. Afinal tu no v mais ningum comendo com as mos ou arrotando na mesa. No em pblico e com a presena de outros seres humanos (a mesma coisa para variveis com x e y, suponho e apelo). Para isso quanto a sociedade dev evoluiu para hoje podemos falar que o Clean Code se tornou arcaico? Mas voc pequeno gafanhoto s saberia disso se tivesse lido o livro! Porm segue afirmando o que um carinha com a leitura pssima e o senso crtico pior afirmam em um post de uma rede social. Mesmo que para discordar de algo, precisamos de um embasamento e isso s conseguimos de duas formas: vivenciando ou estudando. Perca 20 minutos do seu precioso tempo e abra um dos tantos livros comentados por outros programadores, seja o Clean Code, O programador pragmtico, DDD a bblia azul, anyway. Leiam, se puderem apliquem e julguem se para aquele momento do desenvolvimento, tal coisa faz sentido.

Somos condicionados a procurar a soluo e no a aprender com a necessidade

Quantas vezes estamos desenvolvendo um cdigo e empacamos em algum funcionamento indevido ou sem a mnima ideia de qual mtodo utilizar naquele devido trecho e como fiis recorremos ao santo StackOverFlow? para nos salvar sem ao menos consultar a documentao da linguagem? E quantas vezes voc repete isso com o mesmo erro? 10 minutos perdidos zapeando entre uma pgina e outra da documentao da linguagem, da biblioteca ou do framework utilizado te dariam a capacidade de aprender com a leitura o que aquele erro ou funcionalidade te diz como programador, a prxima vez que voc se deparasse com aquela incgnita, seria muito mais simples que perder o seu tempo escolhendo qual resposta de frum mais se assemelha ao seu erro e a sua necessidade. Fruns como StackOverFlow no deveriam ser fonte de aprendizagem e sim de auxlio por ltimo recurso, como por exemplo, um novo erro descoberto por uma falha em uma atualizao da linguagem, pacote, framework que voc est utilizando. Usar o StackOverFlow como auxiliar de desenvolvimento s te deixa preguioso e muito limitado a pensar como Solucionador e no como desenvolvedor.

Ns no temos tempo suficiente.

Se voc j trabalha ou estuda dentro de TI, sabe que o nosso tempo dinamicamente proporcional a quantidade de tarefas que possumos. No temos tempo para parar e ler tudo o que precisamos para o desenvolvimento quando o prazo to curto para uma entrega, da surge a fama de Solucionador . Infelizmente temos sempre que produzir valor ou ento o fantasma do layoff volta a assombrar. Porm, como desenvolvedor voc condicionado a sempre se atualizar de novas tecnologias, formas de soluo de um requisito, desenvolvimento. No devemos se limitar ao que j conhecemos e ao grande limite do que estudamos em um curso, faculdade, tcnico etc. O seu tempo de desenvolvimento deve abranger um tempo de estudo e de aprimoramento, de cargo da empresa que voc esteja de acordo com o seu desafio. Utilize o seu tempo de trabalho para pesquisar tal coisa e se possvel, traga o avano para dentro do seu desenvolvimento.

Infelizmente, a leitura uma das poucas softskills caras de se obter, tanto com o custo ( livro no barato) quanto o tempo empregado para isso, para adicionar o hbito de ler a sua rotina necessrio um frequente exerccio. Pelo lado bom, pode se dizer que o programador que possui o hbito (softskill) de leitura e de aprendizado contnuo tm um grande diferencial daqueles que tem o perfil de Solucionador da parada. Afinal toda empresa possui o sonho do desenvolvedor canivete, aquele que serve pra tudo e pra aquilo que ele no for feito, vai se dar um jeitinho para utilizar.

Antes que achem que eu tirei do meu escondido essas info, deixo as minhas duas fontes de artigos legais, elaborados por devs incrveis (o cofundador do stackoverflow) que vem falando um pouco sobre o que eu comentei sobre a filosofia do frum da plataforma e outro post de um desenvolvedor ingls que possu um bom blog sobre o dia a dia do engenheiro de software, o Ben Husk, que h anos vem atacando essa necessidade de leitura no meio do desenvolvimento de software.

• Programmers Don't Read Books -- But You Should
• Why developers should readbooks