Existe uma façanha que o desenvolvedor normal parece não possuir, a interpretação 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. Alguém que passou 40 minutos em contato com a bolha já reparou nisso e acho de suma importância isso ter alguma mudança.

Neste post, vou apresentar alguns argumentos sobre o porquê da leitura influenciar na sua carreira (e na convivência humana, pois você dev, não é um pato).

Todas suas tarefas serão escritas por um humano.

Seja um PO, um Scrum ou um Tech Writer alguém vai ter que escrever aquilo para você como desenvolvedor inserir no código. Grande parte dos erros de softwares hoje são causados não pela inabilidade do desenvolvedor e sim pelo não entendimento da task passada. O que parece inofensivo, na curva do desenvolvimento de um projeto acaba sendo custoso, um desenvolvedor que requer correção de parâmetros de regras de negócio simples toma o tempo da equipe em testes, correções, reavaliações, manutenção e por fim critérios de aceite. Não seja esse cara, leia, releia, pense e se surgir alguma dúvida, pergunte ao seu PO ou pessoa responsável.

O fato de cada vez mais existirem reuniões que poderiam ser um email vem do fato de pessoas não entenderem o que o email tem a te dizer.

Ninguém quer conversar com dev, no final das contas, a única tarefa que o desenvolvedor deveria focar com necessário gasto de tempo para o desenvolvimento seria na programação do seu produto. Na prática, temos diversas reuniões ritualísticas que muitas das vezes são necessárias, porém em outras tantas poderia ser um e-mail bem redigido. O que não acontece com muita frequência pois há uma Gap de informações 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 informações de maneiras concisas a equipe. E lá se vão 40 minutos de todo mundo que deveriam ser economizados com um e-mail de 4 linhas, mas desenvolvedor não ler.
Cada vez mais informações tem que se aparecerem mastigadas e mais pessoas para fazer isso e mais tempo do desenvolvedor e mais reuniões e isso é tudo um saco. Tente sempre manter a comunicação assíncrona e saber tirar dúvidas de maneira a não se perder tempo em uma reunião e sim redigindo um e-mail.

A área não te ensina a ter pensamento crítico.

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 código era quase feito por primatas que escreviam nome de variáveis como x e y sem pudor algum? O Uncle Bob surgiu com um livro de práticas de programação que não passa de um código de etiqueta de desenvolvimento. Em momento algum a limitação para se seguir aqueles bons costumes foi mencionada em algum dos seus livros, ao contrário, ele sempre abre o pressuposto de que há uma constante evolução dentro do campo do desenvolvimento mas que existem coisas como regrinhas de nomes de variáveis que devem ser seguidas até o presente momento, como há nas regras de etiquetas. Afinal tu não vê mais ninguém comendo com as mãos ou arrotando na mesa. Não em público e com a presença de outros seres humanos (a mesma coisa para variáveis 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! Porém segue afirmando o que um carinha com a leitura péssima e o senso crítico 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 pragmático, DDD a bíblia azul, anyway. Leiam, se puderem apliquem e julguem se para aquele momento do desenvolvimento, tal coisa faz sentido.

Somos condicionados a procurar a solução e não a aprender com a necessidade

Quantas vezes estamos desenvolvendo um código e empacamos em algum funcionamento indevido ou sem a mínima ideia de qual método utilizar naquele devido trecho e como fiéis recorremos ao santo StackOverFlow? para nos salvar sem ao menos consultar a documentação da linguagem? E quantas vezes você repete isso com o mesmo erro? 10 minutos perdidos zapeando entre uma página e outra da documentação 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 próxima vez que você se deparasse com aquela incógnita, seria muito mais simples que perder o seu tempo escolhendo qual resposta de fórum mais se assemelha ao seu erro e a sua necessidade. Fóruns como StackOverFlow não deveriam ser fonte de aprendizagem e sim de auxílio por último recurso, como por exemplo, um novo erro descoberto por uma falha em uma atualização da linguagem, pacote, framework que você está utilizando. Usar o StackOverFlow como auxiliar de desenvolvimento só te deixa preguiçoso e muito limitado a pensar como Solucionador e não como desenvolvedor.

Nós não temos tempo suficiente.

Se você já trabalha ou estuda dentro de TI, sabe que o nosso tempo é dinamicamente proporcional a quantidade de tarefas que possuímos. Não temos tempo para parar e ler tudo o que precisamos para o desenvolvimento quando o prazo é tão curto para uma entrega, daí surge a fama de Solucionador . Infelizmente temos sempre que produzir valor ou então o fantasma do layoff volta a assombrar. Porém, como desenvolvedor você é condicionado a sempre se atualizar de novas tecnologias, formas de solução de um requisito, desenvolvimento. Não devemos se limitar ao que já conhecemos e ao grande limite do que estudamos em um curso, faculdade, técnico 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 possível, traga o avanço para dentro do seu desenvolvimento.

Infelizmente, a leitura é uma das poucas softskills caras de se obter, tanto com o custo ( livro não é barato) quanto o tempo empregado para isso, para adicionar o hábito de ler a sua rotina é necessário um frequente exercício. Pelo lado bom, pode se dizer que o programador que possui o hábito (softskill) de leitura e de aprendizado contínuo têm 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 não 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 incríveis (o cofundador do stackoverflow) que vem falando um pouco sobre o que eu comentei sobre a filosofia do fórum da plataforma e outro post de um desenvolvedor inglês 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 read books