Usamos níveis de abstração demais
(unixsheikh.com)- No setor de tecnologia, à medida que cresce o número de pessoas que aprendem apenas a usar ferramentas e automação, a profundidade técnica de entender como as camadas inferiores funcionam está enfraquecendo
- A abstração, como o volante ou a direção hidráulica, facilita o trabalho, mas quando há falha ou indisponibilidade, a capacidade de recuperação cai se não houver ninguém que conheça o que acontece por dentro
- A pressão para lançar rápido e reduzir custos concentra várias funções em uma só pessoa, como em DevOps e DevSecOps, levando a mais automação e menos entendimento profundo
- Na área de segurança, confiar apenas na luz verde de ferramentas de teste de invasão baseadas em GUI pode fazer com que uma invasão real passe despercebida por muito tempo
- Quem está aprendendo tecnologia precisa, em vez de seguir só modismos, experimentar fazer manualmente o que as ferramentas fazem e manter a postura de engenheiro de investigar código e camadas inferiores
A lacuna no entendimento técnico escondida pela abstração
- Hoje, existe o problema de muitos “especialistas” saberem configurar ferramentas, mas não entenderem como a tecnologia funciona em camadas mais profundas
- A abstração em si é necessária
- O volante é uma abstração que facilita dirigir um carro
- A direção hidráulica é outra abstração que melhora ainda mais a experiência de dirigir
- O problema aparece quando a abstração quebra
- Se não houver ninguém que entenda a tecnologia por dentro, fica difícil consertar a camada com falha
- Mesmo que a ferramenta pareça indicar normalidade, pode não ser possível avaliar o estado real do sistema
- O setor de tecnologia é fortemente pressionado por lucro e velocidade de entrega
- Como resultado, mais abstração e automação são introduzidas
- Menos pessoas acabam assumindo mais trabalho
- O uso de ferramentas específicas é enfatizado mais do que o entendimento profundo
- Os papéis tradicionais de programador e administrador de sistemas estão mudando para um modelo que coloca desenvolvimento, segurança e operações no trabalho de uma única pessoa, como DevOps e DevSecOps
- Como é difícil para uma única pessoa dominar completamente desenvolvimento, segurança e administração de sistemas ao mesmo tempo, tenta-se automatizar o máximo possível
- Como consequência, profissionais de tecnologia modernos podem aprender a usar ferramentas específicas, mas saber muito pouco sobre a tecnologia interna
A postura necessária para quem está aprendendo tecnologia
- A vida moderna depende fortemente de tecnologia, mas a própria tecnologia está ficando cada vez mais difícil de entender
- Mesmo na área de segurança, há críticas de que muitas pessoas sabem apenas usar ferramentas prontas de teste de invasão, mas entendem pouco de segurança em si
- Se a GUI web da ferramenta mostrar uma luz verde, pode-se assumir que está tudo bem
- Mesmo que um atacante real já tenha comprometido o sistema e esteja vendendo dados na darknet, o vazamento ou a invasão pode não ser descoberto
- O texto também remete a uma matéria do Slashdot sobre casos de estudantes que nem conhecem os conceitos de arquivos e pastas
- Para quem estuda tecnologia, as práticas necessárias são as seguintes
- Não seguir apenas modas ou tendências
- Não aprender só a ferramenta; entender como a tecnologia subjacente funciona
- Sempre que possível, fazer manualmente ao menos uma vez o que a ferramenta de configuração faz no seu lugar
- Sempre que possível, examinar o código da ferramenta
- Continuar aprendendo e experimentando, aprofundando-se nas tecnologias de interesse
- Se possível, montar um homelab e usá-lo como um laboratório para aprender e quebrar coisas
- Perguntar sobre o que não entende e não presumir, por padrão, que outra pessoa sabe melhor
- Isso não significa que todo mundo precise entender tudo a partir dos primeiros princípios ou que não se deva usar ferramentas
- A abstração é necessária
- Assim como o motorista dirige e o mecânico conserta o caminhão, existem especializações
- O problema central está no enfraquecimento da postura de engenharia que quem trabalha com tecnologia deveria ter
- No desenvolvimento de software, funções antes exercidas por especialistas estão sendo substituídas demais por ferramentas e automação
- Cada vez menos pessoas entendem sequer a camada imediatamente abaixo daquela em que trabalham
- Se um desenvolvedor web cria um site apenas com ferramentas ou frameworks prontos, sem conhecimento de TCP/IP, DNS, HTTP, TLS e segurança, sua utilidade cai bastante quando surgem problemas
1 comentários
Opiniões no Hacker News
Na história da aviação, também houve um momento em que uma pessoa capaz de pilotar um avião podia projetá-lo e construí-lo, e me pergunto se naquela época também se preocupavam com um futuro em que alguém que não entendesse de verdade os primeiros princípios da máquina se sentaria no cockpit
Hoje nos acostumamos à ideia de que pilotar e fabricar são habilidades e profissões distintas, e também aceitamos naturalmente que um engenheiro aeronáutico não precise saber minerar bauxita nem fundir alumínio
É tranquilizador conseguir percorrer todo o caminho, de portas lógicas a uma requisição web, mas isso não é obrigatório. O fato de haver menos engenheiros com essa visão geral parece menos um sinal de alerta e mais um fenômeno que mostra a maturidade da indústria de tecnologia e a especialização das áreas
Por exemplo, nesse tipo de conversa de “vamos todos voltar para assembly”, durante bastante tempo depois que linguagens de alto nível viraram mainstream, programadores ainda precisavam conhecer assembly. Mesmo trabalhando em grande parte com C ou Pascal, as abstrações de compiladores e ferramentas de depuração vazavam
O problema de hoje é empilhar camadas e mais camadas de abstrações com vazamentos sem dar tempo para que amadureçam. Elas são projetadas para reduzir o tempo de trabalho sob a falsa suposição de que o desenvolvedor sempre estará no caminho feliz, mas, na prática, a maior parte do tempo é gasta depurando situações em que as coisas não saem como planejado. Se você torna o caminho feliz mais rápido, mas torna o caminho infeliz mais lento, em geral o resultado líquido é uma perda
Como a automação do Airbus torna um estol quase impossível, a menos que algo dê muito errado e o avião reverta para a lei manual, ele não entendia bem como o estol funcionava. Foi exatamente isso que aconteceu naquele voo e, quando o comandante voltou ao cockpit, reconheceu imediatamente o estol profundo, mas já era tarde demais
Vídeo relacionado do Mentour Pilot: https://invidious.protokolla.fi/watch?v=e5AGHEUxLME&t=1
O processo de voar tem limites físicos desde o início, mas a computação e os modelos mentais para pensar sobre ela são infinitamente variáveis e têm um escopo de aplicação amplo. Se traduzirmos para a analogia da aviação as bobagens que estão sendo vendidas hoje, é mais como vender um passeio de burro dizendo que é voo. Muitos clientes não têm conhecimento para distinguir a diferença
Um ingrediente importante para o progresso é que só se pode dar um grande salto sobre uma base quando se descobre como tornar alguma coisa simples. Quando fica complexo demais, há limites para a distância e a altura que se consegue alcançar. É parecido com ampliar dívida técnica para a escala da humanidade
Infelizmente, não somos bons em reconhecer na história os momentos em que algo ficou um nível mais simples. Olhando para trás, isso parece naturalmente óbvio
Acho que as crianças de hoje não recebem crédito suficiente. Algumas semanas atrás, o filho de um amigo me mostrou, todo empolgado, o jogo no Roblox que estava criando com amigos
Era o Dia de Ação de Graças canadense, então havia muitos familiares e conhecidos por perto, e ele já tinha escolhido as partes que interessariam a cada pessoa; eu era “a pessoa para quem mostrar Lua”
As pessoas acham que, como celulares e notebooks são fechados e não despertam curiosidade, as crianças também serão assim, mas, na verdade, parece que os adultos é que ficaram menos curiosos
Claro que isso é construído sobre abstrações, mas, entre as montanhas de abstração elevada, sempre houve vales por onde uma minoria curiosa entra. O C64 BASIC permitia dar POKE em qualquer endereço de memória, mas também é bem legal ouvir uma criança de 10 anos explicar um jogo 3D complexo de colecionar com elementos de FPS
Tem uma vibe de velho gritando com as nuvens
Não é novidade que algumas pessoas são especialistas e outras só quebram o galho. Nem todo mundo pode ser um salvador como o autor, que passa metade desse texto curto se gabando
O texto tem pouquíssima relação com abstração. Depois dos dois primeiros parágrafos, o autor perde o interesse na própria tese
Os exemplos também são péssimos. Diz que “alguém usou um framework moderno e foi hackeado, mas o problema de desempenho não era por causa do hack, e sim porque o framework era terrivelmente lento”, mas não dá para saber que framework era, como ele concluiu que era lento só olhando o diff, nem o que a incapacidade de ajustar uma ferramenta ao desempenho tem a ver com abstração
Outro problema é que adotamos várias vezes a abstração errada. Hoje, a indústria de software tem uma monocultura arrogante que acredita ter chegado ao ponto final da história e descoberto tudo.
Na prática, acho que em muitas tecnologias recentes seguimos pelo caminho errado. Até por volta de 2014, tudo parecia ir na direção certa; depois disso, parece que o progresso regrediu e todo mundo começou a usar os mesmos frameworks exagerados. Com as empresas impondo esses frameworks a todos, o desenvolvimento de software se tornou ineficiente e desmotivador.
Criei um SDK para usar em projetos pessoais e ele é pelo menos 10 vezes mais produtivo do que os frameworks mainstream que eu usava no trabalho, além de o código ser muito mais fácil de ler e manter. Mesmo mostrando a um júnior que não conhece o framework, ele consegue trabalhar de forma produtiva. Com esse SDK, criei uma plataforma BaaS no-code em dois meses, em tempo parcial; com ferramentas e frameworks mainstream, acho que nem eu nem qualquer outra pessoa conseguiríamos fazer isso em 12 meses em tempo integral.
Claro que ele pode ter pontos melhores que outros frameworks, mas familiaridade gera expertise, e expertise gera produtividade.
Antes de os parafusos para drywall se popularizarem, muitos profissionais experientes tinham certeza de que parafusos eram mais lentos e piores, mas tanto especialistas em pregar quanto especialistas em parafusar terminam o trabalho rápido e bem.
Seja no front-end ou no back-end, há motivos para usarmos “esses frameworks”. Você pode não gostar desses motivos, mas na programação corporativa importam não só a pureza da linguagem, mas também empregabilidade, manutenibilidade, continuidade e outros fatores que geram dinheiro.
O que acontece se a empresa usar seu SDK personalizado e você for embora? Você pode achar que consegue ensiná-lo facilmente a outra pessoa, mas decisões técnicas de uma empresa envolvem muito mais fatores do que isso.
A frase “hoje, muitos dos chamados especialistas só sabem configurar alguma ferramenta da moda, mas não entendem nada de como as coisas funcionam em níveis mais profundos” me pegou forte.
Todo mundo conhece procedimentos decorados, tipo “para fazer X, adicione esta linha ao arquivo de configuração”, mas, quando precisa fazer algo um pouco diferente de X ou uma variação de X, não sabe sair do roteiro. Pior ainda: fazem as pessoas perderem tempo tentando trazer a conversa de volta de algo que não é bem X para X. Isso lembra a analogia de procurar a carteira perdida só embaixo do poste de luz.
Acho excelente termos criado um ecossistema tecnológico, uma espécie de “techosystem”, em que é possível contribuir com um conhecimento bastante estreito. Colocando de forma menos positiva, isso também permitiu que empresas contratassem mão de obra mais barata, que exige menos conhecimento técnico.
Em muitos casos, acredito que uma solução mediana é melhor do que não haver solução nenhuma. A internet de 1995 a 2005 foi construída sobre soluções medianas, e foi muito divertida.
Especialistas que se aprofundam não são uma espécie em extinção, nem um recurso limitado que detém conhecimentos secretos da era pré-abstração. Pelo contrário, há mais deles agora do que nunca. Eles não são definidos por já terem trabalhado em todos os níveis da stack, de cima a baixo, mas pela curiosidade de olhar para além da própria camada.
Isso porque não apenas acrescentamos camadas de abstração por cima; as camadas de baixo também estão mudando, com NVMe, WebGPU, WebAssembly, QUIC, AVX512 e afins.
Ainda assim, acho que especialistas que se aprofundam são um luxo de que a maioria das equipes não precisa, e uma das competências mais importantes de um gestor de tecnologia é saber quando é indispensável contratar alguém assim.
O aumento dos níveis de abstração é necessário. O cérebro humano não fica muito mais capaz a cada ano, mas o número de ferramentas disponíveis aumenta; portanto, precisamos de abstração para conseguir manter o foco.
Não acho que isso signifique que o futuro seja sombrio. Um programador que lida com problemas de negócio pode ser muito produtivo em linguagens de alto nível sem conhecer EUV, compiladores, assembly, conjuntos de instruções, kernel, protocolo USB, HTTP, dies, placas etc. Um piloto também não precisa saber tudo sobre aerodinâmica, resistência à tração, alumínio, borracha, GPS e assim por diante.
Dito isso, o desalinhamento de incentivos na sociedade moderna é algo que vale muito discutir. Em geral, confio mais em pilotos do que em desenvolvedores de software de negócios, pesquisadores ou banqueiros. Afinal, se o avião cair, o piloto é o primeiro a chegar.
Software para catapultas exige uma abordagem diferente de um app CRUD excessivamente genérico que expõe coisas como o número de mansões que você possui.
Há muito software burro no mundo, e tudo bem. Muitos “problemas reais” também são bem burros e não exigem engenharia heroica.
Em uma quantidade assustadora de casos, um software porcaria montado de qualquer jeito já basta.
Eu também odeio isso, mas acabo pensando que só me resta criar um negócio com minha engenharia superior, vencer a concorrência e provar que eles estavam errados, ou então aceitar que estou gritando para as nuvens.
Ao tomar decisões de compra, hospitais não avaliam a qualidade do software além de algo pouco acima do nível “este botão não funciona”.
É curiosamente apropriado o modo como um texto que critica abstrações transformou em hyperlink a frase “hoje há estudantes que nem sabem o que são arquivos e pastas”.
Esse link leva a uma thread do Slashdot, que leva a um artigo da PC Gamer, que por sua vez reescreve e linka um artigo do Verge, e o artigo do Verge leva a uma pergunta no Stack Exchange.
Em outras palavras, é programação cargo cult. Escrevi sobre isso há dois anos [1], e as reações ficaram totalmente polarizadas entre concordância completa e ataques ferozes dizendo que era gatekeeping
Eu gostaria que houvesse uma forma melhor de curar essa doença sem acionar o sistema imunológico profissional de engenheiros profundamente investidos em suas tecnologias favoritas
[1] https://medium.com/the-engineering-manager-guide/cargo-cult-...
As duas pessoas não entenderam a pergunta, e ele nem esclareceu a pergunta nem considerou a possibilidade de que o problema estivesse nela
A frase “pedi a um especialista em React.js que comparasse várias abordagens de SPA, como manipulação direta do DOM, templates client-side baseados em MVC, manipulação do DOM baseada em componentes e compilação para vanilla JS” eu, sinceramente, também não sei o que quer dizer
Não sei se “compilar para vanilla JS” significa compilar TypeScript para JavaScript, nem o que isso tem a ver com o DOM. “Manipulação do DOM baseada em componentes baseada em MVC” também soa estranho. Parece alguém que leu um livro de padrões de design e tira pontos de quem não usa a mesma terminologia que ele, não alguém com uma compreensão mais profunda de desenvolvimento
Acho que quem realmente aprecia a satisfação de fazer um bom trabalho geralmente passa mais tempo tentando entender algo de verdade do que quem só quer terminar a tarefa
Mas o que essa curiosidade nos traz? Lembro desta anedota do fortune(6), e fico curioso para saber quantas pessoas sem curiosidade a entenderiam
Um iniciante tentou consertar uma máquina Lisp com defeito desligando e ligando a energia. Knight viu a cena e disse severamente: “Você não consegue consertar uma máquina apenas desligando e ligando a energia sem entender o que está errado.” Knight desligou e ligou a máquina. A máquina funcionou
É usado como uma cartada do tipo “você está fazendo gatekeeping, então eu venci”, o que é uma ideia absurda. Não há nada de errado em defender altos padrões de competência profissional, e isso é essencialmente gatekeeping. Quando vou a um médico, fico muito grato pelo fato de a medicina ser uma profissão com barreiras de entrada