Executando verificação de segurança...
-13

"Eu Já Sei Programar!" – Mas Precisa Googlar o Que É Uma Árvore? Tá de Sacanagem?

Hoje em dia, qualquer um que seguiu um tutorial no YouTube ou fez um CRUD em React já sai falando "eu sei programar".

Beleza, então bora testar essa confiança:

"Implemente uma árvore binária do zero."

O cara abre o Google na hora.

MEU AMIGO… Se você precisa pesquisar o que é uma árvore antes de implementar, sinto muito, você NÃO sabe programar de verdade.

Saber programar não é só saber sintaxe
O mercado está lotado de "programadores" que sabem decorar frameworks, mas não fazem ideia de como resolver problemas sem Stack Overflow e ChatGPT.

Sinais de que você NÃO sabe programar de verdade:

  • Você só programa com frameworks e entra em pânico sem um ORM.

  • Você nunca implementou uma estrutura de dados na mão.

  • Você só pensa em "Googlear a solução" ao invés de entender o problema.

  • Se você não sabe a diferença entre um array e uma árvore, uma fila e uma pilha, uma busca linear e uma binária, então você só sabe seguir receita de bolo.

"Ah, mas eu não preciso saber isso no dia a dia!"
Típica desculpa de dev preguiçoso. Você pode até não precisar implementar uma árvore AVL no seu trampo, mas entender a teoria por trás de estrutura de dados é OBRIGATÓRIO se quiser evoluir na carreira.

Por que isso importa?

  • Porque sem isso você não entende desempenho e otimização.
  • Porque isso melhora sua capacidade de resolver problemas.
  • Porque você vai parar de depender de código pronto e começar a pensar por conta própria.

O que falta para você REALMENTE saber programar?
Se você quer ser levado a sério como dev, pare de correr de desafios e aprenda a base da computação.

O que você deveria saber ANTES de dizer "eu sei programar":

  1. Algoritmos e Estruturas de Dados → Árvores, Listas Ligadas, Hash Tables, Grafos.
  2. Complexidade Computacional → Big O não é opcional, é essencial.
  3. Banco de Dados → Não basta saber usar o ORM, entenda índices, normalização, transações.
  4. Redes e Protocolos → HTTP, TCP, UDP, DNS, criptografia básica.
  5. Sistemas Operacionais → Processos, gerenciamento de memória, concorrência, threads.

E um detalhe importante: SEU CÓDIGO NÃO É SEU PROGRAMA.

Você pode até saber usar bem a sintaxe de uma linguagem, mas um programa não é apenas o código que você escreve. Ele é um conjunto de abstrações, camadas e interações com hardware, redes, banco de dados e sistemas operacionais.

Se você não entende como essas peças se encaixam, então você não sabe programar, sabe só escrever código.

O mercado não precisa de decoradores de framework
Se programar fosse só saber escrever console.log("Hello, World!"), qualquer um que aprendeu JavaScript em 3 meses estaria ganhando 20K. Mas não tá, né?

Sabe por quê? Porque o mercado não paga por quem "sabe usar React". Ele paga por quem sabe resolver problemas.

Se seu conhecimento se resume a saber chamar funções de biblioteca, sinto muito: você não é programador, é só um operador de stack.

Agora me responde: você sabe programar ou só aprendeu a procurar no Google?

Carregando publicação patrocinada...
9

Concordo que é preciso ter base, mas calma aí. Tudo depende do nível de abstração do seu trabalho. Se você tá projetando um sistema embarcado, usando C, seus recursos geralmente são muito limitados e você é responsável por gerenciar quase tudo. Mas se você tá desenvolvendo um aplicativo em SwiftUI, talvez você não tenha que pensar em nada disso, até porque você não tem esse nível controle sobre os recursos que o seu app usa. (os dois exemplos são experiência própria)

O mundo é inteiramente contruído em cima de abstrações. Você sabe desenvolver o código em Assembly necessário pra fazer uma CPU funcionar? Pode até ser que sim, mas que diferença isso faz? A não ser que você trabalhe desenvolvendo CPUs (ou sei lá, algo do tipo), esse conhecimento é puramente um exercício mental ou entretenimento. Nada de errado em aprender isso, mas não é essencial. Sempre existe um nível de abstração mais baixo que o seu.

E se não saber implementar algo sem consulta fosse um problema, programação seria apenas um exercício de memória. Quem consegue memorizar mais?

o mercado não paga por quem "sabe usar React". Ele paga por quem sabe resolver problemas.

Exatamente, o mercado paga por quem sabe resolver problemas. Ele não liga se você tem base ou não. Se "sabe usar React" resolve o problema, então é isso que você precisa pra ser pago. Em algum momento você certamente vai precisar de mais, mas o que te impede de aprender assim que você precisar? Qual o problema de pesquisar no Google ou perguntar pro ChatGPT?

Nunca memorize o que você pode consultar.
Einstein (tradução livre)

Pensa em algo similar ao argumento do quarto chinês. Imagina uma pessoa que só sabe o básico de programação e tá sozinho, sem internet, sem IA, sem livros, sem nada, presa em um quarto. Essa pessoa não vai conseguir fazer muita coisa útil. Vai chegar em um ponto em que ela simplesmente não vai mais saber. Mas se ela tem acesso a todas essas ferramentas, então o conjunto pessoa + ferramentas sabe programar e fazer algo útil, e pode muito bem ser pago por isso. Fato é que todo desenvolvedor depende de alguma ferramenta. A pergunta é apenas: até que nível de dependência isso é aceitável? Até aquele que não funcione mais, que o problema não seja mais resolvido.

4

Sempre existe um nível de abstração mais baixo que o seu.

Essa frase já pode fechar o post.

É como a frase atribuida ao Carl Sagan "Se você quiser fazer uma torta de maçã do zero, primeiro você deve inventar o universo"

O mundo evoluiu por conta das abstrações, ter uma base de lógica é importante, mas tu não precisa saber, nem vai saber, tudo que está por trás do que tu faz.

1

Exato. Abstrações são a base da evolução tecnológica. Se cada desenvolvedor precisasse entender o funcionamento da eletrônica, da física quântica por trás dos semicondutores e do design da arquitetura de CPU antes de escrever um "Hello, World", ninguém programaria nada.

O ponto é: entenda o suficiente para saber onde procurar quando algo dá errado. Você não precisa saber como funciona uma árvore binária para usá-la, assim como não precisa saber construir um motor para dirigir um carro. Mas se um dia o motor parar no meio da estrada, é bom ter noção do básico para não ficar na mão.

O mercado não quer saber se você implementaria uma estrutura de dados do zero ou se apenas chamaria um .map(). Ele quer saber se você entrega resultado. No fim do dia, abstrações são só ferramentas—o que importa é o que você faz com elas.

1

Perfeito! Tudo depende do nível de abstração com que você trabalha e do problema que precisa resolver. Não faz sentido exigir que todo programador entenda Assembly ou gerenciamento manual de memória se o trabalho dele nunca vai exigir isso. Mas, ao mesmo tempo, quem entende melhor os fundamentos pode ter vantagens em certos cenários—como depuração de problemas complexos ou otimizações.

O mercado realmente não paga por "saber React", e sim por resolver problemas. Se usar ferramentas de alto nível resolve, ótimo! Mas quem tem um conhecimento mais profundo geralmente se adapta melhor a mudanças e encontra soluções mais eficientes.

A questão da dependência de ferramentas é interessante. Hoje, temos IAs e motores no-code que fazem cada vez mais trabalho pesado, mas sempre há um limite para o que essas ferramentas podem fazer sem intervenção humana. Então, o equilíbrio está em saber usar bem as abstrações sem ser refém delas.

E, claro, nunca memorize o que pode consultar. Mas sempre entenda o suficiente para saber o que consultar quando precisar.

2

Vou dar meu pitaco em cima da minha experiência.

O mercado paga de tudo, inclusive pro cara que só sabe fazer CRUD bobo que há tempos ninguém deveria estar fazendo porque é trabalho repetitivo e não deveria ter tanta gente fazendo as mesmas coisas sempre. Bem, com a IA esse cenário deve mudar, não do jeito certo porque deveria ter algumas formas canônicas, e a IA vai entregar milhões de CRUDs diferentes, é péssimo, mas mais uma vez dará a impressão de um ganho extraordinário de produtividade, quando no longo prazo será um ganho muito bom, mas nada tão grande porque haverá o custo.

Uma das bobagens que se fala sobre IA dominar a programação é que desenvolver software sempre foi mais fazer manutenção do que fazer algo novo e aa IA terá mais dificuldade com isso.

Eu sei bem o que é uma árvore, implementei algumas, até mesmo para uso pesado, e se me pedir para fazer uma sem consultar nada eu conseguirei porque já tenho experiência, mas será uma implementação bem ingênua. Todas as vezes que eu fiz eu peguei papers e implementações de referência para fazer um trabalho melhor. E não tive 100% de sucesso fazendo o melhor possível, por falta de tempo, fazer 90% é fácil, fazer os outros 90% é que complica.

Obviamente que eu não vou pegar códigos no Stack Overflow, porque eu sei que muitas vezes o código foi feito mais para ilustrar, sem muito compromisso, a maioria das pessoas não sabem disso, e aí que começa ter um perigo enorme. A maioria dos programadores não sabe usar o Stack Overflow, nem mesmo para leitura. Isso é uma tragédia.

Algumas pessoas não sabem usar o Google corretamente, e IA então nem se fala. Na verdade, só o fato de a pessoa confiar tanto na IA já mostra um despreparo bastante importante e que revela um problema estrutural nela, não é uma falha pontual, não é a crença na IA o problema, é amaneira de pensar e agir que gera o problema real.

Grande parte das pessoas não conseguem ter uma posição crítica, então ou só sabem elogiar o que amam ou quando precisam criticar o que odeiam não possuem argumentos. Quase todas as vezes que fiz críticas, argumentei, recebi negativos dos lovers daquela tecnologia ou o que o valha.

Muitas vezes a pessoa aprende errado e aí ela só tem olhos para aquilo. É oque sempre falo de treinar o erro. Quantas vezes recebi negativos porque a pessoa aprendeu de uma forma errada.

Eu sempre estudei muito, procurando sempre que possível me calçar da ciência, do conhecimento real, não da crença popular. Não quer dizer que faço isso perfeitamente, até porque não sou acadêmico, mas boa parte das minhas respostas no Stack Overflow foram em cima de conceitos, de algo que ensinasse algo para as pessoas programarem melhor.

Só uma dica: boa parte das respostas do Stack Overflow em Português são mais completas e cheia de referências, muito mais que o SO em inglês onde tem muita resposta fabulosa, que ensina coisas que só encontra lá, mas também muita coisa feita nas coxas, e nem estou falando das respostas ruins, erradas, estou falando das boas que não tiveram muito capricho. Claro que no SOen tem muito mais respostas. Isso é algo que a maioria das pessoas não sabem, ou seja, não usam direito uma das ferramentas mais sensacionais que um programador já teve acesso. A maioria sequer dá o devido valor, dá um valor que não importa.

Não é questão da pessoa não saber o que é uma árvore, porque ela é importante, se a classe pronta que está usando usa uma delas e qual para saber o que vale a pena usar, a pessoa não sabe que não pode usar float ou double para valores que precisam de exatidão. Até programador de banco famoso não sabe e passa vergonha nacional (na verdade a empresa toda porque todo mundo descobriu que o discurso não bate com a prática).

As pessoas não sabem as definições corretas de quase nada. Xingam goto e adoram exception e isso não faz o menor sentido.

A maioria das pessoas não sabe como um banco de dados funciona, então compram ideias fuleiras de influencers, adotam NoSQL onde não faz sentido, tomam decisões equivocadas.

Eu poderia começar uma lista de assuntos fundamentais, que não tem nada de avançado, que só serve para alguns trabalhos específicos e que as pessoas erram.

Mais uma vez, é um problema de como a pessoa pensa e age, ela não tem a prática de procurar o certo, ela só quer o que funciona, até que para de funcionar. Quem não é assim, nem precisa ler nada disso, mas são poucos.

Eu uso uma frase nas minhas palestras: "você só sabe programar se souber o que caractere do código faz, até o espaço em branco". Mas é saber mesmo, em todos os detalhes.

è verdade que a IA até vai ajudar um pouco nisso, tem IDEs que já vão alertando para mexer no código a fim de evitar determinado problema. Mas é muito falho, e fará as pessoas ficarem amis burras ainda, e vão entregar coisas com problemas porque acham que IA é algo determinístico e vai fazer sempre certo.

Eu já pedi várias vezes para a mesma IA me dar um código de embaralhamento sem repetições. Tem hora que ele me dá usando Fisher-Yates, tem hora que vai na força bruto. Se a pessoa não sabe nada disso ela compra o que a IA informou naquele momento, não sabe porque foi de outro jeito em outro momento. Não sabe pedir para a IA gerar o código usando Fisher-Yates, porque se a pessoa nem sabe isso como ela fará um bom prompt. A IA vai ajudar os medíocres e os abaixo disso, mas vai ajudar muito os bons programares não precisarem mais dos ruins. Tudo no seu devido tempo.

Não é questão de aprender só a abstração ou não, é questão de pensar como um todo. Em medicina você pode ser especialista em algo mas sabe toda a medicina básica, caso contrário você será um péssimo médico (me parece que as faculdades agora regurgitam "profissionais assim), mas em programação grande parte dos programadores são especialistas em algo mas não entendem o todo, muitas vezes não entendem a matemática, algo que é a base da programação, muitos nem conseguem enxergar isso. Existe uma razão para aprender além das sintaxes, bibliotecas e frameworks, de só consumir APIs. Quando o nível educacional é muito baixo é até difícil entender isso, e o Brasil é "campeão" em ter baixa educação, não a toa que temos 92% de analfabetos funcionais, incluindo vários programadores, o que é um feito incrível.

O mercado que faz melhor paga para os melhores. Mas tem espaço para tudo. Um dos aplicativos que as pessoas mais usam hoje em dia é uma das coisas mais malfeitas que já vi na vida, as equipes estufam o peito com orgulho do que fizeram, e não passa no crivo até mesmo de alguém esperto que não estudou a área. Claro que funciona, que escala, mas a que custo? Com sofrimento de quem? E você pode se perguntar se ele é tão popular, como pode ser tão ruim? Simples, o mercado é que manda, a empresa conseguiu quase um monopólio, as pessoas não tem a chance de usar algo melhor. E o pouco de concorrência que possuem também não ajuda.

O que tem de big tech jogando dinheiro fora em projetos fracassados, e muitos que obtém sucesso, raramente é por boa engenharia. Então você tem alguns dos programadores mais bem pagos tomando decisões erradas. Você tem empresa que é referência em microsserviços pagando os juros da dívida técnica que criaram porque adotaram microsserviços que propagaram para todo o mundo, e um monte de gente adotando a mesma coisa sem saber nem porque estão fazendo aquilo. E aí de quem falar que estão errados. Isso é falta de base também. A pessoa até aprendeu certo, mas se perde no caminho. E muitos da equipe sabe que está errado, mas não vai jogar o emprego fora sendo do contra.

Se quisermos algo de qualidade real precisamos parar de aceitar o que funciona e só procurar solução quando para de funcionar e passar a nos preocuparmos com o certo.

Claro que estou falando de programação séria. Existem maneiras de programar só para resolver uns probleminhas bobos, aí é claro que não precisa de um desenvolvedor, de um engenheiro. Mas o assunto que está sendo levantando, até onde eu entendi, é de programação profissional, com P maiúsculo, não apenas que paga as contas.

Espero que isso ajude algumas pessoas a pensar diferente, começar procurar mais do que só entregar códigos, pelo menos para quem quer ter uma carreira mais forte e não ser apenas um codificador. Obviamente que cada faz o que achar melhor, espero que não prejudique a ele, ouras pessoas, incluindo usuários do software que ele fez, que pode ser eu, essa é aparte egoísta da resposta, estou cansado dse udar softwares que fazem passar raiva, até mesmo quando não os uso diretamente mas é no balcão de uma loja ou alguma outra forma indireta.

S2


Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

1

Isso resume bem o problema. O mercado paga por qualquer coisa, de CRUDs sem alma a sistemas robustos e bem pensados. Mas a questão real não é se alguém vai te pagar, e sim: qual o custo disso a longo prazo?

A grande ilusão da IA é que ela parece acelerar tudo. Sim, a curto prazo, milhões de CRUDs inúteis surgirão, feitos sem qualquer critério. No longo prazo, isso se transforma num pesadelo de manutenção, e alguém vai ter que pagar essa conta. Spoiler: não vai ser a IA.

O problema real não é usar abstrações, é não entender o que está por trás delas. É a diferença entre um programador que usa float para valores monetários sem questionar e outro que entende o impacto disso no longo prazo. Se você acha que Stack Overflow é um lugar pra copiar e colar sem critério, ou se acha que IA é um oráculo infalível, parabéns, você já entrou na fila dos programadores que serão substituídos por um autocomplete mais sofisticado.

A programação sempre foi mais sobre manutenção do que criação. Não é a IA que vai resolver isso. O que vai continuar sendo pago — e bem pago — são pessoas que conseguem olhar pra um problema e pensar além do "funcionou no meu computador". Quem entende de verdade o que está fazendo, e não só segue tutoriais no YouTube ou aceita qualquer resposta de chatbot como verdade absoluta.

E se você acha que tudo isso é um exagero, olha ao seu redor. Sistemas mal projetados, dívidas técnicas monstruosas, e um mercado que vive repetindo os mesmos erros. O programador medíocre vai sobreviver? Sim. Mas o programador que pensa, que entende o impacto do que faz, vai estar sempre um passo à frente. A escolha é sua.

1

No longo prazo, isso se transforma num pesadelo de manutenção, e alguém vai ter que pagar essa conta. Spoiler: não vai ser a IA.

Mas é justamente sobre isso. Se a IA está fazendo surgir "milhões de CRUDs inúteis" e depois alguém vai ter que pagar essa conta, essa conta quem vai pagar é a empresa que os contratam e quem vai receber pra corrigir esse estrago é justamente os bons programadores. Ou seja, quem é bom programador não precisa se preocupar com nada disso, pois ele receberá para resolver esses problemas.

A questão principal aqui é como você formula a sua ideia. É simples entender que você está criticando os programadores superficíais que para tudo precisam pesquisar ou gerar código (isso quando sabem aonde pesquisar). Mas a forma como você coloca isso, da a entender que se uma pessoa não sabe traduzir uma string em um código binário ela não tem espaço no mercado ou é um péssimo programador. Mas, apesar de eu ter aprendido como fazer essa tradução na faculdade, até hoje não tem uma única vez que precisei exercer esse conhecimento e, caso precise, uma rapída googlada (que você parece ser contra) lembra o método de fazer esse calculo (isso se for realmente necessário fazer na mão, porque se precisar em 10 segundos você acessa um site gratuito e faz a tradução.

Eu acho válida a sua ideia de se buscar tem um conhecimento geral sobre tudo envolvido na programação, mas não dá pra generalizar, tudo depende de contexto, porque se o programador for obrigado a saber exatamente tudo sem recorrer a uma pesquisa, então não há programadores bons, porque nenhum sabe tudo.

1

Estou vendo cada vez mais este tipo de odio neste espaço, o que só vai dividir a comunidsde já tão dividida. Eu fiz faculdade e nao sei criar uma árvore binária do zero. Trabalho nesse ramo tem 17 anos, ja trampei pra agrncia de publicidade ao governo federal. Seu pensamento é binário demais pra ser real. A vida não é só preto no branco.

1

Se um pedreiro constrói uma casa sem saber exatamente a composição do bloco, ele ainda é um pedreiro – pelo menos na minha visão.

Da mesma forma, um programador não deixa de ser programador só porque não entende profundamente como funciona uma pilha ou uma lista. O que realmente importa, na minha opinião, é ser um bom profissional, capaz de resolver problemas e entregar soluções. isso tornara bom programador cedo ou tarde

O verdadeiro problema não está em ser um “programador de framework”, mas sim na atitude diante dos desafios. Se a pessoa se depara com uma limitação do framework e simplesmente desiste, aí sim temos um problema. Um bom progrmador não se rende; ele busca aprender e expandir seus conhecimentos quando necessário.

No fim das contas, as pessoas gostam de rótulos, pois é da natureza humana classificar e categorizar tudo ao redor.

a e se tirar o auto complete da IDE, talvez eu nao faça um loop.

1

não programa em Assembly ? Nutela.
piadas a parte, sempre é bom saber como as coisas funcionam "por trás dos panos", ajuda a você resolver problemas com mais efetividade, porém nem sempre é necessário, a tecnologia evolui para facilitar nossa vida também. os métodos das linguagens de alto nível ja são muito bem otimizados, então eu nunca vou implementar uma árvore pois O(logn). Alguém já implementou isso!

1

Exato! Entender como funciona por trás dos panos é um diferencial, mas reinventar a roda toda vez não faz sentido. As linguagens de alto nível e as bibliotecas existem justamente para otimizar o trabalho e evitar esforço desnecessário.

Mas é aquela coisa: quando algo dá errado ou precisa de otimização, quem sabe como funciona por baixo sempre tem uma vantagem. Então, não precisa programar em Assembly todo dia, mas saber um pouco nunca fez mal a ninguém. 😆

1

De fato é muito importante que tenhamos o aprendizado em nos fundamentos da programação, inclusive achei bem válido o seu ponto sobre aprender SQL e bases de dados relacionais. São coisas assim que às vezes a maioria dos iniciantes (até pessoas com mais experiência kkk) acabam pulando, é um ponto válido de se reforçar. Apenas acho uma pena que foi entregue na espécie de um Ragebait, onde provavelmente o objetivo é gerar engajamento por tratar de um tema às vezes até delicado que a grande maioria da plataforma terá interesse de acessar.

Nada contra sua pessoa, inteligência e sua experiência, é apenas minha opinião.
Não sou ninguém, só acho importante filtrarmos bem nossas palavras e discurso para que todos possam ter um aprendizado mais eficiente e uma comunicação mais assertiva e agradável.

;)

-1

Ah, o clássico "concordo, mas não gostei do tom".

Sim, fundamentos importam. Sim, SQL e bancos relacionais são ignorados por muita gente. Sim, isso deveria ser reforçado o tempo todo. Mas se precisa ser dito com uma linguagem mais "agradável" para que as pessoas aceitem, então talvez o problema não seja o tom, mas a disposição de ouvir o que não se quer ouvir.

O objetivo não é "ragebait". O objetivo é sacudir um pouco essa complacência que faz com que a maioria dos devs pulem etapas essenciais e depois sofram as consequências. Se o texto fosse só um "vamos todos aprender juntos, amigos", ninguém ligaria. Mas a verdade é que muitos preferem uma ilusão confortável a um tapa na cara que pode realmente fazer diferença na carreira.

No fim, a escolha é simples: você quer ser alguém que entende a raiz dos problemas ou só mais um que copia e cola código sem saber por quê? O mercado já tem um monte do segundo tipo. O primeiro sempre vai ter espaço.

1

Não nego a importância da "chacoalhada" para a falta de pessoas com o aprendizado dos fundamentos da programação.

Foi só um ponto de vista que quis trazer, novamente, não sou ninguém, é apenas uma visão que tive do seu post. Os outros comentários explicam melhor o meu ponto,
Bom dia e tudo de bom pra você e sua família!

0
0

"MEU AMIGO… Se você precisa pesquisar o que é uma árvore antes de implementar, sinto muito, você NÃO sabe programar de verdade."

Parei de ler aqui, provavelmente o restante do texto foi mimimi.

0

Sério que o pessoal ainda programa baixo nivel pra fazer uma árvore binária? Não é mais fácil usarmos uma lib pra isso? Até que ponto a gente precisa ir a fundo pra entender como funciona por debaixo dos panos? Qual seria o nível de abstração que a programação deve ter, para o OPERADOR seja um PROGRAMADOR?

Lembre-se que isso tem mudado MUITO nos ultimos anos, ainda mais com plataformas NO CODE, e agora com as IAs. Você pede um bloco, entra um dado, sai um resultado, e resolve um problema.

As coisas estão mudando rápido, os nomes e cargos vão mudar, você está preparado pra essa mudança de paradigma?

1

Usar lib pra cirar um uma Binary Tree? isso deveria ser crime(ironia)

Depende do contexto. Se o objetivo é apenas resolver um problema rapidamente, usar uma biblioteca pronta faz total sentido. Mas entender como funciona uma árvore binária (ou qualquer outra estrutura de dados fundamental) é o que diferencia um programador que apenas usa ferramentas de um que sabe criar soluções mais otimizadas e adaptáveis.

A programação está, de fato, se tornando mais abstrata, e as ferramentas no-code e IAs estão reduzindo a barreira de entrada. Mas isso não significa que o conhecimento de baixo nível perdeu seu valor—ele só está se tornando menos comum. Ainda precisamos de quem projete as bibliotecas, quem otimize código para performance e quem compreenda os impactos de cada abstração.

No fim das contas, o que define um programador não é o nível de abstração que ele usa, mas sim a capacidade de resolver problemas de forma eficiente. A mudança de paradigma já está acontecendo, mas sempre haverá espaço para quem entende os fundamentos. Você quer só apertar botões ou criar as ferramentas que fazem os botões funcionarem?