Você precisa ler pelo menos um livro para poder entrar no Ride
(ludic.mataroa.blog)- Mesmo sendo reconhecido no trabalho como um engenheiro acima da média, quando comparado com gente realmente muito boa a diferença pode ser enorme, e essa distância geralmente aparece na quantidade de estudo feito de verdade
- A experiência de ter desistido da arte depois do ensino médio mostra, com apenas um exemplar de Drawing On The Right Side Of The Brain e algumas horas de prática, que o material certo pode baixar a barreira
- Em engenharia também há uma grande diferença entre quem leu pelo menos um livro sobre um tema específico e quem quase nunca tentou, e em muitas profissões o segundo grupo é a maioria
- A especialização se divide em camadas, como na esgrima em nível local, nacional e olímpico, e quem lê vários livros e se aprofunda fica mais perto da competição pelas vagas de elite
- Ler livros por si só não basta; sem a meta-habilidade de escolher bons materiais e descartar as partes ruins, é difícil ter resultado mesmo se agarrando a materiais sobre Scrum, Agile ou liderança
O ponto de partida: “acima da média, mas ainda insuficiente”
- O autor diz que sempre foi reconhecido no ambiente profissional como um bom engenheiro
- Afirma estudar até dezenas de vezes mais do que o engenheiro mediano ao seu redor
- Já recebeu uma proposta em nível sênior de uma das melhores empresas da região
- “Serious People” querem contratá-lo de novo e ficam irritadas com mensagens de commit preguiçosas
- Mas, comparando-se com muitas das pessoas que lhe mandam e-mail, ele se considera claramente insuficiente
- Tem 3 a 4 anos de carreira e formação em psicologia
- Fora projetos pessoais, quase nunca escreveu testes, e os empregadores que teve não tinham testes funcionando nem vontade de adotá-los
- O código da dissertação de mestrado foi escrito sem controle de versão, e ele comenta que uma das melhores universidades do país não ensinava controle de versão
- Ele desenvolve essa contradição com exemplos de arte, engenharia e esporte, enfatizando a distância entre “quem aprendeu um pouco direito” e “quem mal tentou”
O efeito de “um livro certo” na arte
- No ensino médio, ele odiava arte mais do que qualquer outra coisa e, depois de decidir que não era artsy, passou cerca de 10 anos sem desenhar quase nada além de cubos rabiscados
- Em 2022, tentou o curso Drawabox, mas o achou muito chato e sem progresso real
- Depois, por recomendação no Hacker News, conheceu Drawing On The Right Side Of The Brain, de Betty Edwards
- O título o incomodou, já que ele havia deixado a psicologia para trás, mas havia recomendações e exemplos de antes/depois
- Os desenhos do depois pareciam tão irreais que lembravam golpe de emagrecimento
- O primeiro exercício do livro era desenhar sua própria mão da melhor forma possível, e ele desenhou por 30 a 45 minutos
- Pelos padrões que tinha na época, foi o melhor desenho da vida, mas ainda assim ruim
- Depois fez exercícios de seguir com os olhos as linhas de desenhos de cabeça para baixo e, ao produzir mais algumas páginas, ficou surpreso com o resultado
- Quando voltou a desenhar a mão, após apenas 6 horas de leitura e prática, o resultado estava muito melhor do que antes
- Para ele, isso virou um exemplo de como quase passou a vida inteira sem o prazer da arte, até cruzar a barreira com o livro certo
A “barreira de um livro” e a distribuição dos engenheiros
- Os engenheiros se dividem em dois grandes grupos
- Engenheiros que leram 1 livro ou mais sobre um tema específico geralmente parecem muito competentes
- Não precisa ser literalmente um livro; uma quantidade suficiente de blogs técnicos ou aulas também pode cumprir papel parecido, embora com diferença de eficiência
- Do outro lado estão engenheiros que quase nunca tentam isso ao longo da carreira inteira, além de pessoas de outras profissões, e ele acha que esse grupo é a maioria
- O engenheiro muito bom Seth Newman descreve o profissional mediano como alguém mais próximo de “passar a vida de trabalho sonâmbulo”
- Há movimento, mas falta percepção para evitar cair rolando escada abaixo
- O próprio autor se vê, na maioria dos temas ligados ao trabalho, como alguém que leu um bom livro e parou por aí
- Com Pro Git, entende bem o modelo de dados do Git, mas não os algoritmos por baixo dele
- Ainda assim, considera isso mais do que suficiente para atropelar um engenheiro escolhido ao acaso
- Ao olhar para projetos como Evennia, ele reconhece que existem pessoas em um nível muito mais profundo
- Conversando com gente de alta performance em várias áreas, ouviu repetidamente que em quase todos os campos há muita gente que nem sequer tenta de verdade
A especialização se divide em camadas sem fim
- A conversa com Seth avança para até onde pode ir a especialização profunda
- Como exemplo no basquete, cita um vídeo em que um jogador conhecido como um dos piores da NBA, aposentado havia 10 anos e com o corpo já deteriorado, ainda domina amadores e jogadores de nível profissional inferior
- A experiência do autor na esgrima mostra a mesma estrutura
- Em Melbourne, ele era considerado um sabrista razoável e vencia a maioria dos amadores
- Mas era completamente atropelado por alguns atletas que competiam no campeonato estadual
- Um colega de treino depois venceu o Nationals da Austrália, mas não conseguiu marcar um único ponto contra alguém que tentava se classificar para as Olimpíadas
- Yu Peng Kean, da Malásia, perdeu por 15 a 1 para o campeão olímpico de 2012 naquele ano
- Essa estrutura em camadas não é estranha em si, como no caso de Magnus Carlsen esmagando enxadristas que treinaram a vida toda, mas a sensação é totalmente diferente quando você enfrenta isso pessoalmente
- O atleta de topo sempre parece um pouco mais distante, mais rápido e mais preciso, e o adversário sente como se uma criança estivesse avançando sobre um adulto
Incentivos e “pessoas que entraram errado na indústria de tecnologia”
- O autor admite que, em áreas como piano, ele também vive em estado quase sonâmbulo
- Sente falta de talento, mas na prática também não treina o suficiente
- A diferença é que ele não escolheu piano como profissão, e ninguém lhe paga para tocar piano
- Na tecnologia, ele acha que a sociedade errou ao criar incentivos para a participação de gente sem talento ou interesse real
- Muitas dessas pessoas poderiam estar despertas em esportes, artes, matemática ou outros campos
- Como há áreas com muito dinheiro, grandes organizações difíceis de operar e movimentos para converter verba corporativa em status pessoal, até maus programadores e maus líderes acabam recebendo salários altos
- Ele critica duramente a função de PowerBI developer como uma forma de ganhar acima da média e passar facilmente mais de 6 horas por dia enrolando
- Citando a experiência do primeiro emprego de Christopher Hitchens, destaca que às vezes ser incapaz de continuar em uma área por ser ruim demais nela pode empurrar a pessoa para outro caminho
A vantagem competitiva criada por um livro
- Ligando ao texto de Dan Luu, very little effort, ele argumenta que às vezes é preciso muito pouco esforço para se tornar alguém de alta performance
- Essa pessoa pode ser alguém capaz de fazer uma tarefa evidente, como um backflip, ou apenas alguém que entrega resultados maiores do que os demais
- Um livro normalmente já leva você até o nível de “adicionar uma nova funcionalidade a um app React sem criar dívida técnica”
- Se você escolher com inteligência um trabalho que a sociedade recompensa, isso já pode bastar para ganhar a vida de forma ética
- Ler vários livros o aproxima da disputa pelas vagas com os maiores salários
- Aí passa a importar se você faz a mesma coisa em um dia ou em uma semana
- Se o concorrente leu N livros, você precisa ler N+1, numa corrida armamentista
- Como Deloitte e o desenvolvedor médio não leem livro nenhum, ele acha fácil competir com eles
- Quando você está preso como funcionário dentro de uma organização, pode se sentir impotente por ter de trabalhar com esse tipo de gente
- Movendo-se de forma mais mercenary, ele acredita que dá para atropelar essas pessoas em entrevistas e reuniões
- Em entrevistas técnicas, sugere perguntar ao candidato qual é seu livro técnico favorito e só aprofundar a conversa com quem citar um livro cujo conteúdo o entrevistador consiga verificar, o que já eliminaria a maioria dos dud candidate
- Um candidato que leu um livro excelente que o entrevistador não conhece pode virar um false negative
- Ele supõe que false positive quase não haveria
Pessoas que se esforçam, mas não geram resultado, e a habilidade de filtrar materiais
- Há um caso mais complexo: gestores de equipe que realmente se esforçam, mas não conseguem produzir resultado
- Atormentam engenheiros, entram em pânico, não sabem contratar e superestimam a própria capacidade, mas estão sinceramente tentando
- Continuam tentando fazer Scrum do jeito certo, mas no fim parecem sonâmbulos entrando num lago a pé
- A habilidade que lhes falta é a meta-habilidade de saber que livro ler
- A diferença entre Drawabox e o livro de Betty Edwards é o exemplo principal
- Drawabox parecia bom na superfície, mas, para o objetivo do autor, o livro de Edwards era muito melhor
- Ele acha que Drawabox já pressupunha o conhecimento dos truques centrais enfatizados por Edwards e pulava direto para técnica mecânica
- Por causa dessa peça faltando, seria possível terminar o processo inteiro e ainda assim quase não progredir
- Em tecnologia, ele tende a confiar mais em material produzido por quem construiu algo impressionante diretamente
- Dá nota alta a sinais como manter projetos open source ou demonstrar conhecimento difícil de fingir
- Resultados mais nebulosos, como “trabalhou em empresa grande”, valem menos porque podem vir de sorte ou pose
- Código é difícil de falsificar quanto ao fato de compilar ou não
- Ele também sugere regras soltas para avaliar material
- Nomes chamativos demais contam contra
- Livros bons costumam ter capa sem graça ou elegante
- Se o título contém “leadership”, há grande chance de ser besteira
- Quanto mais o autor se gaba de prêmios, mais falso parece
- Estilo excessivamente coloquial perde pontos, embora não seja defeito fatal se o tema for sutil
Críticas a Agile, The Phoenix Project e aprendizado pelo LinkedIn
- Entrou um Agile consultant no trabalho, a diretoria adorou, mas perguntaram aos engenheiros para avaliar o “Agile training” de 1 a 5
- O autor considera a própria pergunta sem sentido
- Diz que há quase 100% de correlação entre quem gostou da sessão e quem lê os livros errados
- Mesmo dentro de um livro, é preciso saber jogar fora as partes sem valor
- The Phoenix Project tem boas ideias, mas, ao contar a transformação organizacional, coloca só um agente ruim e faz todo o resto parecer extremamente competente e diligente, o que não combina com a realidade de grandes empresas
- Você precisa extrair as boas ideias e perceber que o resto se aproxima mais de “fanfic de liderança”
- Sem essa capacidade de filtragem, o aprendizado e a autoevolução ficam fortemente bloqueados
- Quando um executivo divulga o que anda lendo, isso muitas vezes revela de imediato que a chance de essa pessoa ser boa no trabalho é pequena
- Quando um líder diz que aprende pelo LinkedIn, o autor afirma sentir forte rejeição
Conclusão: abrir livros funciona muito bem, mas não é preciso recomendar isso aos concorrentes
- No início, o texto pretendia ser uma reflexão sobre o efeito anormalmente grande de abrir um livro na era do YouTube
- A conclusão real, em tom irônico, fica mais perto de nunca recomendar leitura para ninguém em hipótese alguma
- Se os outros continuarem sem ler, isso vira dinheiro fácil para quem lê
- O autor encerra brincando que o próximo texto virá cheio de anti-Git propaganda e links de material sobre Scrum
2 comentários
Mesmo para aproveitar uma tecnologia, primeiro é preciso saber que ela existe para ao menos tentar usá-la, então é importante conhecer nem que seja superficialmente.
Opiniões do Hacker News
O texto é bem escrito, mas parece subestimar o conhecimento tácito de um engenheiro experiente que iniciantes não têm
Às vezes, isso simplesmente parece bom senso, mas na prática não é, e o resultado pode facilmente levar a uma falta de empatia. Passar tempo com crianças ou idosos, ou ajudar um parente que está com dificuldades ficando do lado dele, pode desenvolver esse tipo de empatia. É parecido com a diferença entre um falante nativo que simplesmente fala com naturalidade e alguém que sofre enquanto aprende uma língua
Ele teve dificuldade justamente em coisas que eu considerava óbvias, como manter indentação consistente ou realmente ler as mensagens de erro do compilador e usá-las para depurar. Levou alguns anos para ele chegar ao nível de conseguir um emprego como programador e, na verdade, eu também levei alguns anos; eu só tinha esquecido meu ponto de partida
Na consultoria, o melhor engenheiro quase não lê livros por causa de um TDAH severo, mas tem uma experiência prática enorme e lê documentação e posts de blogs de alto nível o suficiente para parecer haver certa equivalência. Uma pessoa muito brilhante certa vez disse que “livros não ajudaram muito”, mas ainda assim recitou sem hesitar os cinco livros que tinha lido naquele ano; mesmo que os livros em si não tenham sido muito úteis para ela, a disciplina de abrir cinco livros parece tê-la levado ao topo
Essa sensação vem de uma quantidade enorme de prática deliberada
A parte sobre “engenheiros que nunca tentam de verdade ao longo de toda a carreira” bate 100% com a minha experiência
Não sou um desenvolvedor genial; acho que tenho competência para criar soluções decentes para problemas de pequena escala que me são atribuídos e também algum senso sobre abordagens certas e erradas, mas nem tenho certeza se conseguiria passar por uma entrevista na FAANG. No trabalho, estou sempre em estado de alerta, como se, se eu desviasse o olhar por um instante, gremlins fossem se infiltrar
É o tipo de coisa em que olho por 30 segundos para um PR já aprovado por dois engenheiros sêniores e encontro uma falha de segurança crítica; ou vejo um padrão de carregamento que funciona bem nos 5 registros testados, mas no conjunto de dados real dispara 300 consultas ao banco de dados por página; ou vejo código que gasta 75% do tempo de CPU reconstruindo objetos de data a partir de timestamps que serão descartados logo em seguida. No fim, parece falta de curiosidade, interesse e paixão inatos por programação
Para mim, boa programação se aproxima de artesanato. Quando preciso publicar um remendo provisório por causa de requisitos de negócio, surge um desconforto difícil de expressar, e, se é algo que eu criei, quero fazê-lo bem mesmo que eu não tenha grande apego ao produto em si. Ouço com frequência “não sabia como fazer funcionar, então fiz assim”, mas o significado real quase sempre está mais para “a primeira coisa que tentei bateu em um pequeno obstáculo e eu não tentei mais”. Quanto pior fica a base de código, mais difícil se torna contribuir com algo de que se possa ter orgulho
Fico me perguntando se eu só trabalhei em empresas excepcionalmente ruins, ou se o setor inteiro é mesmo assim
Ele não sabe, mas o rockstar do nosso time é justamente ele. Pelos exemplos, parece que os colegas não se importavam muito com o próprio trabalho
Eu sou a pessoa que todos chamam quando algo dá errado, quando é preciso resolver conflitos de opinião, quando é preciso consertar algo que parece inconsertável ou quando é preciso descobrir alguma coisa. Nunca me senti qualificado, e acho que não duraria um dia em um lugar como o Facebook. Não tenho a capacidade de me ajustar bem a uma equipe nem de suportar estruturas políticas, então prefiro cantos escuros
Se a pergunta é se o setor inteiro é assim, na prática é muito pior. O número de pessoas no setor está maior do que nunca, e é quase impossível encontrar alguém que realmente saiba alguma coisa. Ao longo de 5 a 10 anos, é preciso montar uma lista de pessoas confiáveis e manter esses relacionamentos sem jamais largá-los
Porque é mais difícil se esconder na multidão, embora, claro, existam pessoas inteligentes e dedicadas em empresas de todos os tamanhos. Não continue apenas apagando incêndios; procure pessoas que compartilhem ou respeitem seus princípios, e deve ficar tudo bem
Vi gente demais simplesmente jogando código em uma issue sem muito interesse, atenção ou curiosidade e achando que estava tudo bem. Um gerente antigo procurava pessoas com “faísca”, e, pelo fato de ele ter me contratado, acho que eu também a tinha naquela época
Desenvolvedores sem essa faísca também têm para onde ir, e já vi organizações sofrerem tentando reunir apenas pessoas assim. Mas também há muitos formados em bootcamp que entraram pelo dinheiro ou por acharem que era uma profissão estável, e em muitos casos não têm muito interesse além disso
Se em 2025 houver receita suficiente para que possamos contratar em 2026, seria bom enviar um e-mail para a consultoria
A parte de ler os “livros certos” é importante. No ensino médio, li alguns livros de autoajuda e, depois de poucos, dá para perceber que a maioria é praticamente fanfic, como o autor diz
Durante a leitura, você fica se perguntando o tempo todo: “isso é óbvio? Eu já sabia disso?”; há muitos exemplos e histórias, e aparece com frequência o padrão de tentar expandir uma metáfora ou slogan simples, como “skin in the game”, para uma filosofia de vida inteira
O segundo grupo lembrava das informações muito melhor. As pessoas são atraídas por histórias, e há um motivo para as epopeias mais antigas serem narrativas. Livros de autoajuda seguem essa fórmula porque ela funciona. Ler algo, entender algo, aplicar algo e dominar essa aplicação são coisas muito diferentes entre si
Vejo o ponto central desses livros como levar alguém a adotar plenamente uma ideia, rotina ou processo e criar a capacidade de aplicá-lo quase por instinto quando a situação aparecer. Em alguns casos, um post de blog bastaria, e também há os piores discursos intermináveis só para aumentar o número de páginas; mas muitas histórias e narrativas servem como mecanismo para que o leitor se encontre em uma delas e guarde a lição com força. Não dá para culpar um livro por ter recebido um título adequado
Muitas vezes me perguntam se leio Cal Newport, mas acho difícil aguentar porque ele mistura bons pontos com observações banais e depois se apoia em exemplos e histórias. Há lugares em que exemplos e histórias são necessários, mas esse método não me parece convincente. É uma pena eu não ter lembrado dos três itens anteriores ao escrever, e também é engraçado que “Skin In The Game” seja justamente um livro do Taleb. Não quero dizer que o livro seja ruim; só acho curioso que um livro do autor que me imunizou contra esse padrão tenha aparecido como exemplo
Normalmente há uma ou duas boas ideias no começo, e o resto é repetição e enchimento. Esse problema é tão comum que acho que, na maioria dos casos, basta ouvir um vídeo-resumo no YouTube. Outro truque é sempre procurar a primeira edição, que em geral é mais curta e mais clara
Voltar a ler livros aumentou muito minha capacidade de manter a atenção e minha concentração, e também reduziu a vontade de ficar no doomscrolling
Muitas coisas que as pessoas veem em si mesmas como parecidas com TDAH também se sobrepõem a uma capacidade de concentração pouco desenvolvida ou negligenciada de propósito. Não estou dizendo que seja o caso de todo mundo. Se você se autodiagnosticou ou recebeu diagnóstico profissional de TDAH, vale refletir se está treinando regularmente o músculo da concentração fazendo tarefas que exigem foco, e se está se afastando de lixo como doomscrolling ou vídeos curtos. Será que você não está evitando o que é difícil, como servo do próprio sofrimento, e caindo em comportamentos que reforçam o problema? Concentração é uma capacidade que se esgota para todo mundo
É um pouco exagerado, e a realidade é mais complexa, mas concordo como princípio geral. Só de se importar de verdade com o que faz, você já consegue ficar muito à frente de quem aparece só para receber o salário
Concordo em grande parte com a ideia de que “há algo muito errado em uma sociedade que começou a empurrar para a área de tecnologia pessoas sem talento ou interesse”, mas esse modo de pensar leva a conclusões interessantes
Primeiro, todo o processo de contratação em tecnologia pode ser vários níveis mais ineficiente do que as reclamações internas do setor sugerem. Mesmo ao procurar talentos iniciantes, talvez as empresas estejam filtrando pelas coisas erradas
Segundo, em carreiras de cauda longa, como esportes profissionais ou artes, os incentivos financeiros são muito ruins. Para lidar com o problema que o autor enxerga, seria preciso tratar disso também, e isso por si só é uma toca de coelho profunda
Terceiro, se a situação é tão ruim assim, por que as empresas não treinam os funcionários diretamente no trabalho?
Quarto, quase nunca perguntamos se esse custo de oportunidade é mais caro do que uma renda básica. Isso porque, hoje em dia, a tomada de decisão nos setores privado e público tende a ser ortogonal uma à outra
Mesmo que eles consigam passar por todo o curso, ninguém sabe o que acontecerá com suas carreiras caso de fato consigam um emprego em desenvolvimento de software
A maioria dos lugares trata todos os funcionários como se estivessem, na prática, “totalmente treinados” e, de forma estranha, encara treinamento durante o trabalho como um favor feito ao funcionário. Isso provavelmente está ligado à cultura em que trabalhadores de tecnologia permanecem pouco tempo em cada empresa
O aumento dos salários em tecnologia é um sinal de que não há programadores suficientes. A maior parte do crescimento econômico dos EUA agora se baseia em programação e tecnologia
No fim, parece uma história do tipo “piledriver dominante de Matlab”
É como pegar qualquer coisa da própria experiência de vida — ler mais de um livro, tocar violão, ter um hobby estranho, tornar-se ginasta semiprofissional — e encaixá-la em uma estrutura narrativa que justifique, com pouco esforço, um longo rant sobre como você é brilhante ou como os outros são burros
A leitura é mais um catalisador e ponto de partida; o que faz as coisas realmente se encaixarem é a prática. E é importante ter interesse suficiente para pesquisar e testar várias coisas por conta própria
https://ludic.mataroa.blog/blog/i-will-fucking-piledrive-you...
Concordo muito com essa premissa. Minhas habilidades se dividem em três categorias: as que inventei diretamente a partir de primeiros princípios, as que aprendi lendo um livro, e as que não sei fazer.
Uma das coisas que não sei fazer é encontrar bons livros. Livros estão por toda parte e a maioria é lixo, mas todos os livros que me recomendaram foram excelentes. Será que existe um bom livro sobre como encontrar bons livros?
https://www.gnooks.com/faves.php
Gnod geral: gnod.com
https://www.literature-map.com/
Também há sites que reúnem listas de livros
https://www.goodreads.com/review/list/21394355-william-adams...
https://www.goodreads.com/review/list/21394355-william-adams...
Se as recomendações não chegarem naturalmente, dá para procurar nas recomendações e bibliografias de livros que você leu e gostou, em outros livros de autores de que gostou, ou em outros livros de uma série da qual você leu um volume e gostou
Ao usar ferramentas que combinam modelos de linguagem de grande porte com dados em tempo real, como o Gemini, os resultados melhoram
Isso se conecta à frase: “aprender com algo que outra pessoa pensou e preparou por muito tempo, enquanto eu tento assimilar aquilo em muito menos tempo”
https://news.ycombinator.com/item?id=40147526
Ler HN também conta como autoaperfeiçoamento? Não consigo contar quantas habilidades ou “pistas” de ideias ganhei passando tempo neste site
Acho que, se não fossem as histórias daqui, eu não teria largado meu emprego para me tornar fundador solo. Ainda é cedo para dizer se foi uma boa escolha
Absorvo por osmose muito conhecimento que não teria obtido de outra forma. Usei de fato apenas uma parcela minúscula das tecnologias, mas acabei ficando bastante por dentro do ecossistema de programação como um todo. Ajuda a saber “o que existe por aí” e “o que pesquisar”
Dito isso, provavelmente 95% desse conhecimento por osmose poderia ser obtido com apenas 10% do tempo gasto rolando a página. No geral, HN costuma ser um bom uso do tempo, mas normalmente eu estou desperdiçando tempo de propósito