Olá Lucas, tudo bem?

Gostei muito do seu texto. Comecei recentemente a produzir alguns conteúdos sobre temas que me agradam, e ainda tenho dificuldades em organizar um material rico desta forma. Parabéns! Vou me inspirar bastante em você para meus materiais futuros.

Eu vejo sentido em uma abordagem Produto vs Plataforma, mas ultimamente tenho uma leve sensação de que várias mudanças deste tipo tem surgido por dois propósitos principais: criar nichos de mercado ou mascarar sobrecarga de função. Me parece que as "big techs" tendem a criar posições cada vez mais específicas para atender demandas específicas. Mas aí vem as empresas de médio e pequeno porte, que não conseguem justificar financeiramente um cargo se restringir a apenas aquele tipo de demanda por um salário de 6 dígitos ao ano, e começam a mascarar a criação de equipes inteiras de um homem só, criando o tal do "fullstack" e outras posições do tipo. Uma época atrás também teve o DevSecOps, que quase sumiu das vagas na mesma velocidade que apareceu (pelo menos é minha impressão). Meu receio é que algumas empresas só utilizem dessa abordagem por conveniência, na expectativa de que um engenheiro de plataforma seja algo como um "super backend".

Acredito ainda que seja interessante contestar uma questão chave: a engenharia de software se estende para além do que muitos acreditam.

Não arrisco dizer que é a maioria pois não tenho dados para embasar uma frase como tal, mas percebo ser razoavelmente comum a concepção que você apresentou. Recentemente contestei um questionamento correlato durante uma entrevista de emprego.

Minha formação foi em uma instituição em que os professores diziam que a ementa do curso foi pensada com enfoque na engenharia de software. Eu já conhecia um pouco de programação, e não só eu como vários de meus colegas tinhamos a definição que você apresentou em mente para o assunto. Meu primeiro professor da matéria discordava plenamente disso, e descobri da pior forma. Fizemos um projeto durante o semestre que compôs 95% da nota, e focamos muito nos aspectos de modelagem e desenvolvimento. Reprovamos. Ainda não concordo com a forma como ele conduziu as avaliações, mas não poderia discordar de que eu não sabia do que se tratava o assunto realmente, só estava preocupado em cumprir o checklist e passar de semestre.
O bendito professor frequentemente dizia algo como:

Um bom sistema deve ser eficaz, eficiente, seguro e legal.

Após minha reprovação fiquei intrigado e decidi investigar mais a fundo o que me faltava. Meu pensamento realmente mudou quando comprei e comecei a ler o principal livro de um dos autores referência do assunto, Roger Pressman (Engenharia de Software: Uma abordagem profissional). A ficha não caiu, ela foi empurrada goela abaixo pelo autor logo no segundo capítulo (isto em menos de 30 páginas de um livro que possui mais de 900 páginas de conteúdo, mesmo não se aprofundando em diversos assuntos que cita).

Lendo o livro, a primeira coisa que aprendi foi que a engenharia de software tem como principal foco a qualidade através do processo de desenvolvimento como todo, desde o problema e a expectativa do cliente, até este ter acesso ao produto/serviço. Eu estava sempre muito focado na metade para o final da coisa, e não prestando atenção no início deste processo.
E aí que a coisa começou a desenrolar na minha cabeça. A ficha que caiu foi a de que aquela frase do meu professor era na verdade a ponta de um iceberg. Estes 4 aspectos são profundos a ponto de termos áreas de estudos e atuação específicas para cada um (produto, arquitetura, segurança e compliance, respectivamente e de forma simplificada).

Pressman introduz a sessão que fala sobre o processo de software da seguinte forma:

No contexto de engenharia de software, um processo não é uma prescrição rígida de como desenvolver um software. Ao contrário, é uma abordagem adaptável que possibilita às pessoas (a equipe de software) realizar o trabalho de selecionar e escolher o conjunto apropriado de ações e tarefas. A intenção é a de sempre entregar software dentro do prazo e com qualidade suficiente para satisfazer àqueles que patrociaram sua criação e àqueles que vão utilizá-lo.

Eu acho muito interessante este trecho pois ele demonstra claramente as preocupações de quando a engenharia de software teve seu primeiro "boom" em produção de conhecimento: qualidade do que é destinado à alguém, e em tempo hábil. O debate sobre o que é qualidade é estenso por si só, mas desde que li este livro (não o li por completo) tive pra mim que esta área sempre teve como ponto principal o cliente. Todo sistema tem como intenção maior o seu cliente, nem que este seja outro sistema. E o engenheiro que não tiver isto em mente, só não entendeu seu próprio propósito ainda. Isto não quer dizer que ele não terá sucesso, mas que corre mais risco de falhar ao tentar alcançar o que o cliente chamará de "um produto de qualidade".

Tomo a liberdade de fotografar e colocar aqui a sessão do livro que sintetiza meu ponto e significou a virada de chave para meu pensamento sobre o assunto, me fazendo decidir por estudar esta área mais a fundo atualmente. Apesar de ser uma solução um tanto preguiçosa da minha parte, eu não poderia te explicar minha colocação inicial melhor que o próprio autor:

Perceba que o exposto como sendo o núcleo de atuação da engenharia de software vai no sentido oposto da imagem apresentada em seu texto sobre o escopo do engenheiro de software. A ideia do que seria um engenheiro de software, pela definição do que é a própria engenharia de software, é tão extensa que cairia exatamente no que foi colocado sobre o "fullstack" (e concordo plenamente): inalcancável pela abrangência do tema.

Eu acredito que foi o mercado de trabalho quem se preocupou mais em cunhar estes "novos" profissionais, os engenheiros que você apontou além de tantos outros (como os polêmicos e recém criados engenheiros de prompt), que são os profissionais "T-shaped" com foco em diferentes aspectos que vejo muitas vezes contidos na ideia mais tradicional e fundamental de engenharia de software, segundo as principais referências do assunto.

E parte disso seria a explicação (aqui já é puro achismo meu) de não ser comum vermos estes termos nas universidades. A maioria das instituições, como sempre, tendem a se moldar ao mercado, seja para suprir as necessidades deste, seja para lucrar em cima do que está em alta. Mas as focadas em formação de corpo docente e pesquisadores (em sua maioria instituições públicas) parecem relutar contra este "desmembramento" do tema durante a graduação. Os discentes "T-shape" se formam a medida que se especializam através da pós-graduação dentro destes contextos e ainda assim não me parece comum estas nomenclaturas (posso estar muito errado neste trecho todo, e seria bem legal me corrigirem se for o caso).