disclaimer: esse texto é pra ser um texto sucinto, recomendo que voce coloque essa música de fundo pra deixar a experiencia mais interessante.
De onde vem a complexidade?
Um software é por natureza um trabalho complexo. Criar sistemas de informação é lidar com múltiplas camadas de abstração, decisões técnicas, regras de negócio e pessoas, tudo isso orquestrado para parecer quase mágico.
A verdade é que essa simplicidade é propositalmente construída. Ela esconde uma cadeia de decisões, testes e falhas. Aqui entra o papel da senioridade: ver o que está escondido, entender o invisível e tomar decisões pensando além da tela.
Como tudo começou pra mim
Quando decidi aprender a programar eu não tinha o objetivo de me tornar engenheiro de software.
Como muitos, meu primeiro impulso foi aquele imaginário de hacker, o cara de capuz estilo Mr. Robot quebrando sistemas, encontrando vulnerabilidades, explorando brechas durante o período noturno e magicamente o dinheiro caia na minha conta bancária. Eu não sabia nada sobre engenharia, processos ou arquitetura. Tudo parecia tudo fácil. Era só “invadir”.
Nosso modelo de ensino não costuma incentivar a construção de abstrações e analogias como entendimento da construção do processo de entendimento, é mais como algo robótico em que toda prática profissional está em sempre fazer mais do mesmo, trabalhar com tecnologia, portanto, ainda é enxergado dessa forma.
Comigo não seria diferente, comecei aprendendo sobre técnicas de invasão. Mas aos poucos, durante meu processo de reflexão comecei a me perguntar: o que exatamente significa invadir ou quebrar um sistema?
Cada sistema tinha um bug, uma falha, uma brecha, será que inspecionar um elemento e mudar o que aparece no navegador já era “invadir”? Eu nem mesmo sabia o que tava rodando na minha máquina ou o que era um servidor.
Foi aí que entendi algo essencial: sistemas são feitos por pessoas e a força de uma corrente é medida pelo elo mais fraco.
Se eu queria entender como quebrar, precisava primeiro entender como construir.
A necessidade de escrever minhas próprias ferramentas
Logo percebi que depender de ferramentas de outros hackers me deixaria exposto. Qual a garantia de que elas próprias não tinham falhas? Quando um hacker quebrava algum sistema, gerava um crack de um software que custava 2000 reais, o que ele ganhava com isso?
Por que aquele sistema custava tão caro? Se as ferramentas que eu usava eram tão potentes, o que poderia me garantir que elas também não pegavam alguma informação minha?
Então comecei a tentar construir as minhas.
Se eu soubesse como um site era feito, poderia criar o meu próprio site, será que alguém me pagaria por isso?
Foi aí que, em 2017, com 16 anos, escrevi minhas primeiras linhas de código. Comecei com C++.
Não fazia ideia de como transformar aquilo em algo útil, mas mergulhei nos livros do Deitel. Demorei uns meses até entender o que era um for e o que significavam todos aqueles ;, {}, ().
E depois de muito sofrer, acabei indo pro lado Python das coisas (deixo aqui meus profundos agradecimentos ao professor Gustavo Guanabara), passando consequentemente por várias outras linguagens.
Quando entendi que podia descrever um processo uma vez e o computador faria isso por mim inúmeras vezes algo mudou na minha cabeça. Era mágico, agora eu podia fazer qualquer coisa.
Se eu pudesse ensinar uma máquina a fazer algo por mim, isso me economizaria tempo, pois ela poderia no meu lugar fazer coisas que eu não queria ou eu poderia fazer só uma vez, entender o processo e deixar por conta do meu robozinho.
Nessa época eu achava que seria engenheiro elétrico. Tinha a ideia de criar coisas.
Sempre fui daquelas crianças que quando os brinquedos quebravam, aproveitava pra ver como funcionavam. Circuitos, engrenagens, ferramentas, tudo isso era mágico.
Foi isso que a programação se tornou pra mim, uma forma de criar, abstrair processos e transformar o mundo em dados e ações automatizadas.
Criar uma interface ou um algoritmo que funciona sozinho, resolver problemas sempre me interessou. Só que agora eu não ia precisar mais de depender de uma fábrica ou de uma linha de produção pra me expressar, certo?
A ilusão do "é só fazer funcionar"
Com o tempo, fui entendendo o que significava de fato ser um profissional de tecnologia. TI não significava "Técnico de Informática", não era só quem formatava computador ou mexia com algum tipo de eletrônica.
Passei pelo processo de aprender HTML, CSS e JavaScript. Meus primeiros sites eram quase estáticos, só mostravam conteúdo, eu ainda não sabia ao certo como fazer alguem acessar meu http://localhost:80. mas eu ainda tinha aquela mentalidade de “quebrar” sites, alterando coisas no navegador.
Aos poucos, fui entendendo a diferença entre montar uma página e construir um sistema. Com o tempo vi muita gente vendendo a ideia de que com 6 meses de curso, você vai ganhar 5 mil reais por mês programando, na própria faculdade eu enxergava uma oportunidade de crescimento vendo todos aqueles carros no pátio do curso e aquelas pessoas nem mesmo tinham se formado.
Mas aqui vai um choque de realidade:
Qualquer calouro de Ciência da Computação pode replicar a interface do ChatGPT em um mês, mas fazer o ChatGPT de verdade e toda a estrutura que o sustenta leva anos, envolve milhares de profissionais e toneladas de conhecimento técnico, matemático e computacional.
O que diferencia um profissional sênior não é só entregar um sistema funcional, mas saber abstrair soluções, entender o que está por trás, comunicar com clareza e sustentar aquilo que parece simples.
Pensando nisso a gente tem acesso à complexidade invisível: o usuário comum só vê uma caixinha de texto. Um robozinho que responde.
Por trás disso: modelos matemáticos absurdamente complexos, terabytes de dados processados, uma infraestrutura distribuída, escalável e segura, lógica, estatística, o tal machine learning e a inteligência artificial, arquitetura de sistemas, engenharia de produto, testes, governança e toda essa estrutura é feita para parecer simples.
Pra que o usuário leigo só precise apertar alguns botõezinhos na tela.
Um exemplo do iFood: um clique são centenas de sistemas e integrações.
Você clica na tela, escolhe a comida, paga e rapidinho ela chega quentinha na sua mesa.
Mas por trás disso tem vários sistemas de autenticação, cardápio, pagamento e logística, integrações com restaurantes, motoboys, sistemas internos e externos. Telas pra você, pro restaurante, pro entregador, pro gerente do resturante, pro gerente do iFood, sistemas de rede, telecomunicações, backoffice, dashboards.
E ainda tem o porteiro do seu prédio que te liga quando chega
Sem falar no que acontece antes do app: agricultura, transporte, cadeia de suprimentos, tudo isso é invisível e funciona porque alguém pensou em cada detalhe.
A engenharia da simplicidade
A grande arte da engenharia de software está em tornar a complexidade invisível. Fazer com que o processo seja fluido, simples e confiável mesmo sendo absurdamente complicado por trás pois se você não pensou em tudo isso, alguém pensou por você.
"If I have seen further it is by standing on the shoulders of Giants". Sir Isaac Newton – 1675.
No final das contas, construir software é sobre resolver problemas. Mas num mundo cada vez mais automatizado, onde tudo parece fácil, vale a pena parar e se perguntar:
Qual parte da cadeia você decidiu assumir?
Qual problema você escolheu resolver?
Porque, no fundo, é isso que diferencia quem só escreve código de quem realmente constrói sistemas. E apesar de tudo, somos apenas mais um tijolo no muro.