Executando verificação de segurança...
16
kaiqueramos
5 min de leitura ·

5 Livros Que Ninguém Lê (E Por Isso Continuam Sendo Medíocres)

Cara, eu tô cansado. Cansado de ver todo mundo papagaiando os mesmos livros "obrigatórios" enquanto essas joias ficam empoeirando na prateleira. Sério, quantas vezes você já ouviu "ah, tem que ler Clean Code"? E quantas vezes alguém mencionou os livros que realmente vão mudar como você pensa sobre programação?

É como se a comunidade dev tivesse uma lista pré-aprovada de 5 livros e pronto, acabou. Qualquer coisa fora disso é "muito avançado" ou "não é prático". Bullshit total.

  1. "Pensamento Pragmático e Aprendizado: Refatore Seu Cérebro" - Andy Hunt
    Enquanto todo mundo fica debatendo se deve usar tabs ou spaces, Andy Hunt resolveu um problema real: por que diabos é tão difícil aprender coisas novas?
    Este livro é praticamente um manual de como hackear seu próprio cérebro. E não, não é auto-ajuda de coach quântico. É neurociência aplicada na prática, escrita por um dos caras que criou o Manifesto Ágil. Ninguém fala disso porque é mais fácil reclamar que "essa linguagem nova é difícil" do que admitir que você não sabe como aprender direito. O livro expõe que a maioria dos devs estuda igual criança de 8 anos: lendo e tentando decorar.
    Quando você lê, descobre que pode dominar qualquer tecnologia nova em metade do tempo. Não porque você é gênio, mas porque finalmente entendeu como seu cérebro funciona. A parte sobre "modo L vs modo R" sozinha já vale o preço do livro. Infelizmente não achei na versão física, mas está disponível na digital aqui https://amzn.to/44HQMit
    capa

  2. "Trabalho Eficaz com Código Legado" - Michael Feathers
    Todo mundo reclama de código legado, mas quantos realmente sabem lidar com ele? Zero. A galera prefere fazer greenfield eternamente ou simplesmente jogar tudo fora e "reescrever do zero" (spoiler: nunca dá certo). É ignorado porque não é sexy, não tem hype, não tem "10 tricks to refactor legacy code". É trabalho duro, metodologia real, sem glamour.
    A realidade cruel é que 90% do código que você vai tocar na vida é legado. Pode ser aquele sistema PHP de 2008, pode ser aquele microserviço Node.js que alguém escreveu "só por enquanto" há 3 anos. Este livro é literalmente um manual de sobrevivência. Depois de ler, você para de ter medo de código antigo. Feathers te ensina técnicas de "caracterização" que são tipo ser um detetive digital. Você mapeia o comportamento do código sem documentação, cria testes de segurança e refatora sem quebrar nada. É quase terapêutico. Essa obra tem o preço acima da média, mas vale a pena cada centavo https://amzn.to/40b0oki
    capa

  3. "Programação em Baixo Nível" - Igor Zhirkov
    Ah, esse aqui é meu favorito para separar quem programa de quem só usa bibliotecas. Enquanto todo mundo fica discutindo qual framework JavaScript é melhor, você tá lá aprendendo como a máquina realmente funciona. A galera evita porque Assembly "não é prático", porque "não preciso saber disso para fazer CRUD", porque é difícil e não dá para fingir que sabe.
    A verdade que ninguém quer ouvir: quem entende baixo nível escreve código infinitamente melhor em qualquer linguagem. Você para de fazer gambiarra e começa a entender por que certas coisas são lentas, por que certos padrões existem, como debugar problemas impossíveis. Você vira aquele dev que resolve bugs que os outros nem conseguem reproduzir. Entende por que aquele código Python está consumindo 8GB de RAM. Sabe otimizar de verdade, não só jogar mais cache em tudo. Coloquei esse na lista de releitura, é um daqueles livros que você precisa revisitar de anos em anos e sempre aprende algo novo. https://amzn.to/4lj0sXF
    capa

  4. "Refatoração: Aperfeiçoando o Design de Códigos Existentes" - Martin Fowler
    Todo mundo conhece Martin Fowler. Todo mundo cita Martin Fowler. Ninguém leu Martin Fowler completo. É tipo aqueles clássicos da literatura que todo mundo fala que leu mas na real só viu o resumo no YouTube. Fica na prateleira porque o pessoal acha que já sabe refatorar. "Ah, é só melhorar o código né". Não, c#!#!#0. Refatoração é uma disciplina com técnicas específicas, nomes próprios, momentos certos para aplicar.
    O livro não ensina "como melhorar código". É um catálogo completo de transformações, cada uma com nome, contexto, prós e contras. É tipo aprender combos num jogo de luta - você tem que saber quando aplicar cada movimento. A diferença na prática é que você para de refatorar "no feeling" e começa a aplicar técnicas sistemáticas. Código vira algo que você esculpe, não algo que você empurra com a barriga até funcionar. Troque o clean code por esse, faça um favor a todos https://amzn.to/4nF6ao6
    capa

  5. "Test Driven: Practical TDD and Acceptance TDD for Java Developers" - Lasse Koskela
    TDD virou moda. Todo mundo fala que faz TDD. Ninguém faz TDD de verdade. A galera escreve teste depois, chama de TDD e acha que tá tudo certo. Este livro é diferente porque Koskela não fica filosofando sobre TDD. Ele pega sistemas reais, complexos, cheios de integração e mostra como TDD resolve problemas que parecem impossíveis.
    O que a galera não entende é que TDD bem feito não é sobre testes. É sobre design. Os testes são só uma ferramenta para dirigir a arquitetura do seu código. Quando você domina isso, para de escrever código acoplado e difícil de testar. A transformação é que você sai do "ah, depois eu escrevo teste" para "como eu vou testar isso?" antes mesmo de começar a codificar. Muda completamente como você aborda problemas. Esse existe apenas em inglês, e é simplesmente um clássico da literatura técnica https://amzn.to/40aLKcN.
    capa

Por Que Estes Livros São Ignorados?

Simples: eles não vendem sonhos. Não prometem que você vai virar senior em 30 dias. Não têm títulos clickbait. Não falam de tecnologia da moda.
Eles fazem algo muito pior para o algoritmo: te tornam um programador fundamentalmente melhor. E isso dá trabalho. Exige dedicação. Não rola thread no Twitter.
A comunidade dev virou uma máquina de hype. Todo mundo quer a próxima novidade, o próximo framework, a próxima linguagem. Ninguém quer parar para entender os fundamentos que vão durar décadas.

Resultado: Temos uma legião de devs que sabem fazer CRUD em React mas não conseguem debugar um problema de performance. Que decoraram padrões de design mas não sabem quando aplicar. Que falam de arquitetura mas nunca refatoraram código legado na vida.

A Real é essa. Não é sobre ser elitista. É sobre parar de aceitar mediocridade como padrão.

Carregando publicação patrocinada...
-1
GustavoFurtadoFatality

já avisando que sou um adolescente que não tem experencia do mercado, quem estiver lendo gostaria que tomasse suas próprias conclusões:

ok vamos começar uma análise do teu post,

você traz um titulo com uma opinião absoluta, tipíco pra chamar atenção, mas sim acredito que se esses livros for lidos de forma correta você pode sair da mediocriedade, mas não entenda ler de forma correta, como se fosse algo absoluto, apenas aprender e ter pensamento critico e racional, e não um copiador um nato, cada um aprende de seu jeito, é relativo.

**"Cara, eu tô cansado. Cansado de ver todo mundo papagaiando os mesmos livros "obrigatórios" enquanto essas joias ficam empoeirando na prateleira. Sério, quantas vezes você já ouviu "ah, tem que ler Clean Code"? E quantas vezes alguém mencionou os livros que realmente vão mudar como você pensa sobre programação?

É como se a comunidade dev tivesse uma lista pré-aprovada de 5 livros e pronto, acabou. Qualquer coisa fora disso é "muito avançado" ou "não é prático". Bullshit total."**

Realmente eu fico incomodado que muitos livros ficam escondidos, mas uma coisa eu sei, não deve se seguir a bolha dev, pra ser sincero os melhores devs não estão nem nela(ou pelo menos a maioria não), a bolha dev está cheia de pessoas com opinoes absolutas coisas como, "sempre faça isso", "se você não fizer isso você não é dev", só que no geral quem é mais impactado são os iniciantes, ele vê que alguem fala mal de java(mesmo que seja na brincadeira as vezes) e realmente acaba tomando uma ideia errada diante daquilo, no geral a bolha dev é sobre vender algo, opiniões absolutas ou pessoas que não sabem de nada, te influenciando,

Esses livros como o Clean Code são recomendados para iniciantes porque são fáceis de ler, obviamente nenhum desses devem ser tratados como uma bíblia, cada coisa é melhor em um caso algumas nem tanto, um leitor não deve copiar um livro educacional, e sim absorver o conteudo e tirar suas próprias conclusões, se você só copia oque um livro ta dizendo, você é um péssimo aluno, mas eles ainda são importante pra você ser moldado como programador, você não deve aceitar tudo que um livro diz, mas voltando ao assunto da bolha dev é isso, eles só recomendam esses livros pois derão certos pra ele ou alguem botou na cabeça deles que eles são obrigatórios(nada é absoluto).

Por Que Estes Livros São Ignorados?
Simples: eles não vendem sonhos. Não prometem que você vai virar senior em 30 dias. Não têm títulos clickbait. Não falam de tecnologia da moda.
Eles fazem algo muito pior para o algoritmo: te tornam um programador fundamentalmente melhor. E isso dá trabalho. Exige dedicação. Não rola thread no Twitter.
A comunidade dev virou uma máquina de hype. Todo mundo quer a próxima novidade, o próximo framework, a próxima linguagem. Ninguém quer parar para entender os fundamentos que vão durar décadas.
Resultado: Temos uma legião de devs que sabem fazer CRUD em React mas não conseguem debugar um problema de performance. Que decoraram padrões de design mas não sabem quando aplicar. Que falam de arquitetura mas nunca refatoraram código legado na vida.
A Real é essa. Não é sobre ser elitista. É sobre parar de aceitar mediocridade como padrão.

Essa parte eu concordo bastante, mas não é bem a "comunidade dev", e sim a bolha dev, oque está na superficie, a ponta do iceberg, a comunidade dev pode ser muitas coisas diferente, desde um grupo de pessoas que trabalham com NodeJS a aqueles que trabalham com computação gráfica com Vulkan, a comunidade dev que você está falando é a bolha, os que aparecerem em redes sociais assim que você abre elas, existem comunidades muito boas, mas você deve mergulhar fundo para encontrar elas. Sobre a parte "falam de arquitetura mas nunca refatoraram código legado na viva", porque simplesmente não precisa???, claro pode tirar um bom conhecimento fazendo isso, mas como você disse sobre devs que criam as 5 leis dos livros obrigatórios, você mesmo ta criando uma lei, eu sei que é sobre sair da mediocridade, só que, é algo que fazem por necessidade, claro que pegar simplesmente por querer um código legado e for mexer é legal pra aprender, mas você não precisa disso pra sair da mediocridade, e nem necessariamente fazendo isso você vai sair da mediocridade.

Nada é absoluto, apenas a existencia da relatividade que é absoluta.

0
Programmer404

Você com certeza não entendeu o post. O Título não é uma afirmação absoluta, está algo mais para uma "manchete" que chama atenção do leitor.

Você tentou diferenciar a bolha dev da comunidade dev, e não fez isso bem e duvido que alguém faça.

Eu não cheguei a ler esses livros que ele disse, mas somente os guru dizem que é bom, e claro, devem ser no mínimo, uma leitura que irá render algo.

Existem sim leituras que são obrigatórias. Por exemplo, O programador pragmático é um livro excelente. Ele vai te ensinar muita coisa para se usar em todas as situações. E partir disso você pode aprender outras 10 coisas que não estão no livro e se virar. Não é sobre ler o livro como uma bíblia e achar padrões, é sobre criar a mentalidade para algo e a partir disso conseguir criar coisas novas. Quem não lê certamente tá perdendo algo. E não é apenas este livro.

Outro exemplo, o livro C programming language é sim essencial para qualquer pessoa começando em C, apesar de ser datado com algumas features, ainda assim é essencial e sem ler ele você definitivamente irá perder muito tempo tentando entender o que tá acontecendo, se não corromper alguma coisas usando ponteiros sem entender o que são.

Enfim, você provavelmente está levando no literal a palavra "obrigatório". Quando neste caso é bem provável que esteja sendo usado como uma ênfase para sua importância.

Seu comentário é um tanto confuso. Mistura temas até de física/filosofia.

"falam de arquitetura mas nunca refatoraram código legado na viva", porque simplesmente não precisa???,

Isso demonstra a sua própria surpeficalidade. O código que você está programando vai se tornar legado. Em algum momento a codebase onde você trabalhará vai se tornar legado. Entender arquitetura é o que te sepera dos superciais que acha que um let no JavaScript armazena um valor diretamente na memória. Mesmo que você não precise hoje, vai precisar em algum momento. E neste momento, se não estiver preparado, você é descartado pois o mercado não liga para quem somos, e sim pelo o que podemos fazer.

simplesmente por querer um código legado e for mexer é legal pra aprender, mas você não precisa disso pra sair da mediocridade,

Por quê não? Tenho certeza que a maioria dos devs não sabe refatorar um código legado. Eu mesmo tenho pouca experiência com isso. Adorei a recomendação e estarei lendo. Você sabe o que é mediocridade? Eu sei, pois já passei por isso, até mesmo abaixo, e de duas uma, ou você se contenta com a mediocridade que o que a maioria faz (e eu por bastante tempo), ou você sai da estrada reta que te leva um vazio. Não é uma definição no dicionário que vai te fazer aprender. No mínimo você vai entender. Ironicamente aprendi isso por alguém daqui mesmo, e na prática, é realmente isso que ocorre.

Enfim, você ainda é jovem. Tem bastante tempo para pensar e entender as coisas. Contanto que aprenda a distinguir as coisas de forma correta, já deu vários passos.

Como já diria o bom e velho Miyamoto Musashi:

Agora eu realmente consigo ver verdadeiramente

1