nome

Coisas que não sei em 2018 – tradução do artigo do Dan Abramov

Publicado em 7 de janeiro de 2019
Autor: Mateus Ávila Isidoro

Este artigo é uma tradução para o português brasileiro do texto do Dan Abramov. Seguindo os ensinamentos do grande mestre Mauricio Samy Souza, o Maujor, ter conteúdos em língua portuguesa são condição de acessibilidade para os desenvolvedores que ainda não sabem inglês.

Coloquei em conchetes algumas notas de tradução, pois tomei um caminho de algumas interpretações de algumas palavras que julguei problemáticas do inglês para o português. Creio que tenhamos pouco prejuízo da ideia central do texto.

O texto abaixo trata de uma verdade que deveríamos considerar: que não dá pra saber de tudo. Para quem não conhece o Dan Abramov, ele é um dos líderes de desenvolvimento do React Js. Pedi a permissão dele, que gentilmente me concedeu, desde que eu citasse a fonte dele. If you reading this, thank so much to allow me to translate, Dan! 🙂


As pessoas assumem que eu sei mais do que eu realmente sei. Isto não é um problema ruim e eu não estou me desculpando. (Pessoas de grupos minoritários as vezes sofrem o viés contrário, apesar das suas credenciais conquistadas com grande esforço [NT: hard-earned credential], e isto é uma droga [NT: sucks].

Nesta postagem, irei lista uma lista incompleta de tópicos de programação que as pessoas erroneamente supõe que eu sei. Eu não estou dizendo que eu não preciso aprendê-los – ou que eu não sei outras coisas úteis. Mas desde que eu não estou em uma posição vulnerável agora, posso ser honesto enquanto isso

Por isso acho que é importante.

Primero, as vezes tem uma expectativa irrealista de que um engenheiro experiente sabe todas as tecnologias em seu campo. Você já vium uma “roteiro de aprendizagem” que consiste em centenas de bibliotecas e ferramentas? É util – mas intimidador.

Tem mais, não importa o quão experiente você é, você pode se sentir alternando entre se sentir capaz, inadequadro (“Síndrome do Impostor”) e super-confiante (“efeito Dunning-Kruger“) [NT: no texto original não há um link apontando para o tópico. Foi uma decisão que tomei considerando a relevância do tema]. Isto depende do ambiente, trabalho, personalidade, colegas, estado mental, tempo do dia, e assim vai.

Desenvolvedores experientes as vezes são abertos sobre suas inseguranças para encorajar iniciantes. Mas temos um mundo de diferença entre um cirurgião experiente que ainda tem nervosismo e um estudante segurando o seu primeiro bisturi!

Ouvir como “‘nós’ somos desenvolvedores júnior” pode ser desalentador e soar como conversa vazia com os alunos que enfrentam uma lacuna real de conhecimento. Ouvir confissões de pessoas bem intencionadas como eu não irá fazer a lacuna sumir. [Feel-good confessions from well-intentioned practitioners like me can’t bridge it. NT: eu fiz um esforço de converter a parte can’t bridge it no contexto da frase. Se houver uma solução melhor, por favor, comente para melhorarmos o texto.]

Ainda assim, mesmo engenheiros experientes tem muitas lacunas de conhecimento. Esta postagem é sobre mim, e eu encorajo aqueles que possuem a mesma vulnerabilidade para comentarem as suas. Mas não desvalorizemos nossa experiência enquanto fazemos isso.

Nós podemos admitir nossas lacunas de conhecimento, podemos ou não nos sentirmos impostores, e ainda teremos um profundo expertise de tudo que leva muitos anos de trabalho duro para desenvolver.


Com este disclaimer, aqui estão algumas coisas que não sei:

  • Comandos Unix e Bash: eu sei ls e cd, mas eu procuro pelo resto. Eu sei o conceito de piping [NT: resolvi usar o termo em inglês aqui, pois é mais comum pesquisarmos por piping do que por tubulação], mas eu só uso em alguns casos. Eu não sei como usar xargs para criar cadeias complexas, ou como compor e redirecionar diferentes saídas de streams. Eu também nunca aprendi corretamente Bash, então eu só posso escrever scripts de shell muito simples (e muitas vezes com erros).
  • Linguagens de baixo nível: Eu entendo que Assembly permite que você armazene coisas na memória e pule o código, mas é só. Escrevi algumas linhas de C e entendi o que é um ponteiro, mas eu não sei como se usa malloc ou outra técnica de gestão de memória manual. Nunca testei o Rust.
  • Networking stack: Eu sei que computadores tem endereços de IP, e DNS é como eles resolvem os nomes de hosts. Eu sei que tem alguns protocolos de baixo nível tipo TCP/IP para trocar pacotes que (talvez?) garantam a integridade. Mas é isso – sou confuso com os detalhes.
  • Containers: Eu não faço ideia de como se usar Docker ou Kubernetes. (eles são relacionados?). Eu tenho uma vaga ideia de como eles permitem criar uma VM separada de maneira previsível. Parece legal, mas nunca testei.
  • Serverless: Também parece legal. Nunca testei. Eu não faço a menor ideia de como este modelo muda a programação back-end (se isso acontece) [NT: Obrigado Prem Prakash pela solicitação de melhoria na tradução.].
  • Microsservices: Se eu entendi corretamente, ele apenas significa “muitos endpoints de API conversando entre si”. Eu não sei exatamente qual é a vantagem prática ou desvantagens desta abordagem, porque nunca trabalhei com ela.
  • Python: Me sinto mal por isto – eu tive que trabalhar com Python por muitos anos até o ponto que eu nunca me incomodei em realmente aprendê-lo. Tem muitas coisas que tem comportamento de importação que são completamente opacas para mim.
  • Back-end em node: Eu entendo como executar o Node, usei algumas APIs tipo fs para ferramentas de compilação, e eu posso configurar o Express. Mas eu nunca relacionei o Node com uma base de dados [NT: But I’ve never talked from node to a database] e eu não sei como escrever um back-end nele. E também não sou familiarizado com os frameworks React como o NEXT além do “hello world”.
  • Plataformas nativas: Eu tentei aprender Objective C, mas não deu certo. Eu não aprendi Swift também. O mesmo acontece com o Java (eu poderia provavelmente aprender, desde que trabalhei com C#).
  • Algoritmos: O máximo que vai sair de mim é tipo um bubble sort ou talvez um quicksort em um dia bom. Eu posso provavelmente fazer uma tarefa simples de travessia de grafos se eles estiverem ligados a um problema prático específico. Eu entendo a notação de O (n), mas meu entendimento não é muito mais profundo do que “não coloque loops dentro de loops”.
  • Linguagens funcionais: A não ser se você contar Javascript, eu não sou fluente em alguma linguagem funcional tradicional. (Sou apenas fluente em C# e Javascript – e eu já esqueci um monte do C#). Eu esforço para ler código de linguagens inspiradas em LISP (tipo Clojure) tanto inspiradas em Haskell (tipo Elm), ou mesmo tipo ML (como Ocaml).
  • Terminologia funcional: map e reduce é o tanto quanto eu vou. Eu não sei monoids, functors, etc… Eu sei que o que é uma monada, mas talvez seja uma ilusão.
  • CSS Moderno: Eu não sei Flexbox ou Grid. Me viro nos floats.
  • Metodologias de CSS: Eu usei BEM (significando a parte CSS, não a BEM original), mas é tudo que eu sei. Eu não tentei OOCSS ou outras metodologias.
  • SCSS/SASS: Nunca consegui aprendê-los.
  • CORS: Eu temo estes errors. Eu sei que preciso configurar alguns cabeçalhos para consertá-los, mas perdi horas aqui no passado.
  • HTTPS/SSL: Nunca configurei. Eu não sei como isto trabalha além da ideia de chaves públicas e privadas.
  • GraphQL. Eu posso ler uma consulta, mas eu não sei realmente como expressas as coisas em nodes (nós) e edges (bordas), quando usar fragmentos, e como funciona a paginação.
  • Sockets: Meu modelo mental é eles fazem computadores falarem entre si fora do modelo request/response, [NT: usei o termo mais pesquisado, ao invés da tradução requisição/resposta] mas é tudo que eu sei.
  • Streams: Além de Rx Observables, eu não trabalhei com streams de perto. Eu usei num Node antigo stream uma ou duas vezes, mas sempre me atrapalhei com tratamento de erros.
  • Electron: Nunca testei.
  • Typescript: Eu entendo o conceito de tipos e eu posso ler anotações mas nunca as escrevi. Nas poucas vezes que tentei, eu tive dificuldades.
  • Deployment and devops: Consigo enviar alguns arquivos via FTP ou matar alguns processos mas é o meu limite de habilidades de devops.
  • Graphics: Seja em Canvas, SVG, WebGL ou gráficos de baixo nível, eu não sou produtivo. Eu tenho uma ideia geral, mas eu teria que aprender os princípios [NT: ele trabalha com o termo primitives, mas não fazia sentido em língua portuguesa].

Claro que esta lista não é exaustiva. Há muitas coisas que eu não sei.


Pode parecer estranho discutir isso. Até parece errado escrever isso. Estou me gabando da minha ignorância? Minha conclusão que pretendo neste post é que:

  • Seu desenvolvedor favorito pode não saber muitas coisas que você sabe.
  • Não importa o nível de conhecimento, sua confiança pode variar muito.
  • Desenvolvedores experientes tem expertises valiosas apesar de lacunas de conhecimento.

Estou ciente das minhas lacunas de conhecimento (pelo menos, algumas delas). Eu posso preenchê-las mais tarde se eu ficar curioso ou se precisar delas num projeto.

Isto não me desvaloriza o meu conhecimento e minha experiência. Há muita coisas que eu posso fazer bem. Por exemplo, aprendendo tecnologias que eu preciso delas.


[NT: Optei por esconder o link de um update que ele fez no final da postagem apontando para outra página que ele comenta as coisas que ele sabe. Se tiver interesse, deixo o link aqui. O objetivo principal é demonstrar que mesmo um desenvolvedor sênior de grande experiência tem conhecimentos que ele nem sabe de como começar, e assumir isto ajuda: a ter consciência do que precisa melhorar; a ajudar iniciantes a trilharem o seu caminho, sem se basear em outros; a demonstrar que a nossa área é muito complexa. Logo, espero que este texto traduzido ajude a desenvolvedores no Brasil e no mundo a não assumirem papeis de super-homem].