A cada poucos anos as ferramentas mudam completamente, e a cada poucos anos o mesmo pequeno conjunto de ideias acaba explicando o que deu errado.
O problema da meia-vida
O conhecimento técnico não se degrada num ritmo uniforme, e essa diferença é a coisa mais útil que uma organização pode entender sobre como treinar seus engenheiros.
Conhecimento de framework e biblioteca se degrada rápido. Uma técnica específica de uma versão, aprendida hoje, costuma ficar obsoleta em poucos anos, às vezes antes disso. O conhecimento de plataforma e fornecedor se degrada quase tão rápido, e os comandos e interfaces específicos mudam o tempo todo.
Abaixo disso existe uma camada que praticamente não se move. Como um computador executa instruções. O que uma estrutura de dados custa. Por que alguns algoritmos escalam e outros não. O que um sistema operacional faz com memória e com espera. Como as redes efetivamente entregam uma mensagem.
Treinar pessoas só na camada que se degrada rápido significa retreiná-las a cada três anos, para sempre.
Isso não é um argumento contra o treinamento prático. É um argumento sobre proporção. A maior parte do desenvolvimento técnico corporativo investe pesado na camada de vida mais curta e quase nada na camada que torna a próxima ferramenta aprendível em uma semana em vez de um trimestre.
O que a trilha cobre
O escopo: algoritmos, estruturas de dados, sistemas operacionais, redes e computação.
Quatro áreas.
Algoritmos e estruturas de dados. Quanto cada operação custa, qual estrutura combina com qual padrão de acesso, e como raciocinar sobre escala.
Sistemas. Processos, memória, escalonamento, arquivos e as abstrações que escondem o hardware.
Redes. Como os dados se movem, o que pode dar errado, e por que sistemas distribuídos são difíceis de um jeito específico.
Teoria da computação. O que é computável, o que é tratável, e onde estão os limites rígidos.
Complexidade, a única ideia que se paga sozinha
Se uma organização ensinar só um conceito desta trilha, deveria ser este.
Complexidade algorítmica descreve como o trabalho de um algoritmo cresce conforme a entrada cresce. A distinção não é acadêmica. É a diferença entre código que funciona em teste e falha em produção.
Três consequências práticas.
Dados de teste escondem o problema. Um algoritmo cujo trabalho cresce com o quadrado da entrada parece bom com mil registros e se torna inutilizável com um milhão. A falha não é um bug que aparece depois. Ela estava presente desde a primeira linha e era invisível na escala do teste.
O laço aninhado sobre um banco de dados é o erro caro mais comum em software comercial. Uma consulta dentro de um laço, em que cada iteração faz sua própria ida e volta ao banco, tem desempenho aceitável com poucos itens e trava com volume real. Esse padrão aparece o tempo todo, em qualquer linguagem, escrito por gente com anos de experiência, porque ninguém mostrou a eles como enxergar isso.
Escolher a estrutura certa costuma valer mais do que otimizar o código. Buscar algo em uma lista significa examinar cada elemento. Buscar em uma tabela hash é praticamente imediato independentemente do tamanho. Mudar uma linha vale mais do que reescrever cem.
Nada disso exige sofisticação matemática. Exige o hábito de perguntar o que acontece quando isso fica dez vezes maior, e esse hábito pode ser ensinado rapidamente a quem já escreve software.
O que o sistema operacional está realmente fazendo
A camada que a maioria dos desenvolvedores em atividade trata como invisível, e de onde vem uma parcela surpreendente dos problemas em produção.
Memória. Como funciona a alocação, quanto custa a coleta de lixo e quando ela pausa a execução, por que a localidade de memória afeta a velocidade muito mais do que o número de instruções, e o que realmente acontece quando um processo esgota a memória disponível. Problemas de memória estão entre as falhas de produção mais difíceis de diagnosticar sem esse quadro.
Processos e threads. O que significa isolamento, quanto custa uma troca de contexto, e por que adicionar threads além de certo ponto torna um sistema mais lento em vez de mais rápido.
Entrada e saída. O motivo pelo qual a maioria das aplicações passa mais tempo esperando do que computando. Operações de disco e rede são ordens de magnitude mais lentas que o acesso à memória, e é por isso que abordagens assíncronas e não bloqueantes existem. Engenheiros que não internalizaram isso otimizam o cálculo em programas que passam a vida esperando.
Concorrência. Condições de corrida, deadlocks e o fato de que operações que parecem atômicas no código-fonte não são. Essa é a categoria de bug que passa em todo teste e falha em produção sob carga, e não dá para raciocinar sobre ela sem esse modelo.
Onde isso se encaixa no domínio
Ciência da computação é a primeira de oito trilhas no domínio de IA, dados e computação da Astra Trainer, e está por baixo de todas as outras. Engenharia de software, ciência de dados, nuvem e DevOps, cibersegurança e machine learning se apoiam nas mesmas ideias computacionais, e quem as domina aprende cada nova camada mais rápido.
Conecta-se mais diretamente com engenharia de software, que é esse conteúdo aplicado sob restrição comercial, e com sistemas de TI e redes de computadores, onde as camadas de sistema operacional e rede são o trabalho do dia a dia. Você pode ver as oito trilhas aqui.
Por que isso importa mais agora, não menos
A suposição comum é que ferramentas de geração de código tornam os fundamentos obsoletos. O argumento contrário é mais forte, e se apoia no que o trabalho está se tornando.
O trabalho passa de escrever para julgar. Revisar código que você não escreveu, e decidir se ele está correto, exige mais entendimento do que produzi-lo, não menos. Uma função que parece plausível, mas tem características de complexidade erradas, é exatamente o tipo de coisa que passa numa revisão casual e falha em escala.
Código gerado é confiante sobre desempenho de um jeito que não consegue justificar. Ele não conhece seus volumes de dados, seus padrões de acesso ou seu orçamento de latência. Alguém precisa conhecer.
Depurar continua sendo a parte difícil. Quando um sistema se comporta de forma inesperada em produção, a pergunta é o que está realmente acontecendo, e isso se responde a partir de um modelo de como a máquina funciona.
Decisões arquiteturais não vêm de autocompletar. Escolher entre consistência e disponibilidade, decidir o que colocar em cache, julgar onde colocar uma fronteira: essas são as decisões que determinam se um sistema sobrevive, e todas são questões de fundamentos.
A formulação honesta é que essas ferramentas elevam o piso da produção de código e elevam o valor de saber avaliá-lo. Organizações que leem só a primeira metade e não a segunda vão descobrir qual das duas tinham.
As funções, nomeadas
Engenheiros de software em todos os níveis, já que isso é o substrato.
Engenheiros de sistemas e programadores de sistemas.
Engenheiros de desempenho, uma especialidade distinta e persistentemente escassa.
Engenheiros de sistemas distribuídos.
Engenheiros de compiladores e runtime.
Engenheiros de banco de dados, onde estruturas de dados e armazenamento se encontram.
Pesquisadores de segurança, cujo trabalho depende de entender o que a máquina realmente faz, não o que o código-fonte diz.
Arquitetos técnicos, que tomam as decisões que esse conteúdo fundamenta.
Engenheiros de pesquisa em sistemas de machine learning, onde eficiência em escala é o problema inteiro.
Quem pode ser treinado para isso
Desenvolvedores autodidatas e formados em bootcamp. O maior e mais recompensador grupo. Frequentemente têm forte habilidade prática, bons hábitos de ferramentas e experiência real de entrega, com uma lacuna específica exatamente aqui. Preenchê-la é um trabalho bem delimitado, não um programa genérico de capacitação, e o efeito no teto de crescimento dessas pessoas é grande.
Analistas e cientistas de dados. Para desempenho e escala, onde consultas e pipelines que funcionam em amostras falham com dados completos exatamente por esses motivos.
Administradores de TI e de sistemas. Já têm conhecimento de sistema operacional e rede pelo lado operacional, precisando da camada de programação.
Engenheiros de outras disciplinas. Formados em matemática, física e engenharia convertem bem, já que o estilo de raciocínio se transfere.
Analistas de qualidade e engenheiros de teste. Para funções de engenharia, já com um forte senso de como as coisas falham.
Engenheiros de suporte. Para desenvolvimento, com conhecimento real do que quebra em produção e por quê.
Sobre fundamentos e contratação. Entrevistas algorítmicas são amplamente usadas e amplamente criticadas como filtro de contratação, e o desempenho nelas se correlaciona de forma imperfeita com o desempenho no trabalho. Esta trilha existe para tornar as pessoas melhores em construir e diagnosticar sistemas, não para otimizar para um formato de entrevista. Organizações que usam este conteúdo deveriam deixar claro qual dessas duas coisas estão fazendo, porque o treinamento que serve a uma não necessariamente serve à outra.
O que levar disso
O conhecimento técnico se degrada em ritmos diferentes, e a maior parte dos orçamentos de treinamento é gasta na camada que se degrada mais rápido.
Complexidade é o conceito único de maior valor, porque prevê a falha em escala antes de o código ser escrito.
A maioria dos problemas de desempenho em produção são problemas de memória, espera ou concorrência, e os três moram na camada de sistema operacional que a maioria dos desenvolvedores trata como invisível.
A geração de código eleva o valor do julgamento, e julgamento aqui significa fundamentos.
E as pessoas que mais se beneficiam já estão escrevendo software para você, com uma lacuna específica, visível e rápida de fechar.
Por que ensinar fundamentos em vez de frameworks atuais?
Porque o conhecimento de framework se degrada em poucos anos, enquanto as ideias computacionais por trás se mantêm há décadas, e quem domina os fundamentos aprende cada novo framework numa fração do tempo.
Qual é o conceito único mais útil?
Complexidade algorítmica. Ela explica por que código que passa em teste falha em volume de produção, por que uma consulta dentro de um laço trava com dados reais, e por que escolher a estrutura de dados certa costuma valer mais do que otimizar o código.
Por que conceitos de sistema operacional importam para desenvolvedores de aplicações?
Porque a maioria dos problemas de desempenho em produção são problemas de memória, entrada e saída, ou concorrência. Aplicações costumam passar mais tempo esperando do que computando, e otimizar o cálculo em um programa que espera não resolve nada.
Ferramentas de geração de código tornam os fundamentos menos importantes?
Elas tornam os fundamentos mais importantes. O trabalho passa de escrever código para julgar código que você não escreveu, e o código gerado não consegue conhecer seus volumes de dados, padrões de acesso ou orçamento de latência.
Quem mais se beneficia desse treinamento?
Desenvolvedores autodidatas e formados em bootcamp, que costumam ter forte habilidade prática e uma lacuna específica e ensinável aqui, seguidos por analistas de dados que esbarram em problemas de escala e administradores de sistemas migrando para desenvolvimento.