DEV Community: Victor Nassif

Como um desenvolvedor generalista pode fazer o uso de IAs na resolução de problemas?

Victor Nassif — Wed, 27 Mar 2024 19:30:48 +0000

This article was written in portuguese. The english version will become soon and it will be linked here.

Sempre fui um entusiasta a respeito de novas tecnologias voltadas para desenvolvimento de software e nos últimos anos com a demanda de IA crescendo cada vez mais, me sinto muitas vezes atrás do mercado.

Como um bom brasileiro, iniciei a carreira profissional muito cedo, e foquei em desenvolver habilidades que pudessem me manter empregado, ou que ajudassem no meu crescimento em determinadas empresas.

Quando fazemos isso, nos desviamos do caminho acadêmico. Infelizmente, de forma muito triste, atualmente considero a academia um espaço privilegiado, ao menos no cenário brasileiro. Mas isso é uma discussão para outro momento.

Nos últimos anos comecei a acompanhar um pouco mais as inovações científicas (🎈), pois, afinal, a ciência é o cerne de tudo que é novo. Dificilmente o novo vem a partir de demandas das empresas. As descobertas são feitas na academia, e levadas para o campo profissional posteriormente.

Praticamente toda inovação que via no campo de TI, estava relacionada a IAs e novos algoritmos. Acompanhando esse universo, sentia uma estranha angustia, daquelas sem nome, mas que estava sempre comigo. Creio que hoje consigo entendê-la um pouco melhor.

A sensação é de que estava atrás dos demais. Não entendia profundamente algoritmos, não entendia os detalhes das IAs. Não entendia como eu poderia incluir aquilo no meu dia-a-dia de uma forma produtiva - além das ferramentas.

Mesmo com essa sensação, sempre me considerei um entusiasta de inovação, então aí estava a contradição que gerava, posteriormente, frustração.

Como alguém pode se considerar entusiasta de algo que não entende?

No livro “Por que generalistas vencem num mundo de especialistas” por David Epstein, o autor defende dentre diversos assuntos, que os profissionais ditos “generalistas” tem o seu valor, e que várias pessoas que são consideradas “especialistas de sucesso”, tiveram, na verdade, muitas falhas em áreas diferentes até conseguir encontrar algo que realmente triunfassem. Esportistas, empresários, intelectuais, e diversas outras áreas são mencionadas.
-Obrigado ao meu camarada Prof. André Câmara pela indicação. Não tenho palavras pra descrever o quanto foi assertivo quando disse que eu me identificaria com o livro.

Ao mesmo tempo que em que não entendia as tecnologias do "hype", sempre me considerei um ótimo solucionador de problemas. Mas me via limitado a utilizar apenas as tecnologias em que tinha proeficiencia, ou que estava seguro o suficiente para usar a este favor. Lendo o livro, então, finalmente entendi uma questão chave a respeito de onde me encaixo como profissional. Tive pela primeira vez contato com o termo “generalista” e me identifiquei como nunca antes.

Durante a leitura entendi que não preciso ser um especialista de IA e de algoritmos para poder resolver problemas utilizando estas ferramentas.

Inclusive, é até melhor que eu não seja um especialista. Em geral, somos recompensados por resolver problemas. Mas quando nossa carreira se afunila como um especialista, estamos limitados a resolver problemas do nosso nicho específico. Obviamente que isso tem o seu valor, e sempre haverá demanda para tal. Mas aqui estou falando sobre a sensação do nosso escopo estar limitada, e não necessariamente fazendo juízo de valor se algo é melhor ou pior ~~(ok, haters?)~~.

Em cenários ditos exploratórios, não temos problemas bem definidos (que para estes, sim, precisamos de especialistas). Em geral, temos diversos problemas “desconhecidos conhecidos” - desconhecidos para mim, conhecidos para alguém que entende daquele determinado contexto - E que segundo a Matriz de decisão Cynefin, a melhor forma de trata-los, é buscando soluções já existentes no mercado. Seja com um especialista ou seja utilizando alguma ferramenta criada por especialistas, vide LLMs, serviços gerenciados, etc. Portanto, profissionais que conseguem ter visões mais abrangentes do todo, podem ter mais sucesso do que profissionais nichados, neste tipo de cenário.

Ao mesmo tempo que, ao menos na minha bolha, devido ao aumento da utilização de modelos LLMs, está se popularizando a ideia de utilizar “caixas pretas” de processamento sem necessariamente saber como aqueles algoritmos atuam. Afinal, você sabe como, em detalhes, o GPT, ou o Copilot está tratando seu input? Pois bem, eu também não. - E o meu ponto é: e nem precisamos. Vamos deixar isso para os especialistas.

Para deixar claro, meu ponto não é que devemos nos abster de analisar o que estamos utilizando e colocando em produção. Precisamos estar ciente dos riscos e eles precisam ser gerenciados. Meu ponto é que, como um generalista, você pode aplicar ferramentas e algoritmos para resolver problemas do dia-a-dia, sem que necessariamente saiba com profundidade como algo está operando por baixo dos panos. Você só precisa se preocupar em como aplicar aquele determinado processamento, e, confie em mim, temos algoritmos o suficiente provenientes de iniciativas Open Source prontos para serem utilizados.

Imagine o cenário que temos alguma demanda para previsão (forecasting) de algum determinado dado. Você precisa criar um algoritmo de forecasting? - Não. Provavelmente, já existe um algoritmo para isso. Você provavelmente não precisa saber como fazê-lo. Você precisa, sim, entender como aplicá-lo, e isso também tem sua curva, que não deverá ser menosprezada. Mas será menor do que a especialização para criação dessa tecnologia.

Atualmente estou buscando novos problemas que podem ser resolvidos e realizando testes com algoritmos. Sinceramente, está me dando bastante gás para continuar. Esse é o meu objetivo neste singelo texto: Te incentivar a pesquisar, a ficar atento a novas publicações, a ler newsletters, e a não se limitar a testar com tecnologias de ponta.

Espero que isso também te ajude na busca de novos problemas para resolver.

Por que seu time de desenvolvimento não é produtivo?

Victor Nassif — Sun, 06 Aug 2023 16:37:22 +0000

Este artigo é destinado as pessoas que são responsáveis por times de desenvolvimento, que podem ser compostos por uma ou mais pessoas. Seja você líder de si mesmo (eu-quipe), ou de um grupo.

Nele, vou apresentar minhas perspectivas e referências. As quais busco perseguir sempre como fundamentos.
Boa leitura!

Introdução

O que é produtividade? Segundo o dicionário, se define como: “eficiência na produção de algo”.

No contexto de engenharia de software, estamos falando (quase sempre) sobre a criação e manutenção de um produto ou serviço.
Podemos pensar no processo de desenvolvimento de software como uma esteira de produção para estes resultados.

Estamos acostumados a considerar apenas trabalhos físicos como linha de produção, geralmente associamos apenas fábricas ou grandes montadoras a este processo. Mas a verdade é que podemos (e devemos) entender o ciclo de desenvolvimento de software da mesma forma.

Nos outros processos mencionados, a eficiência é um valor enraizado. Agora, será que no desenvolvimento de software, analisamos a eficiência da nossa esteira de produção da melhor forma?

Com isso em mente, trago alguns pontos que, de forma comprovada, aumentam a eficiência de um time de desenvolvimento.

Implementar um padrão de tecnologias a nível organizacional

Isto é, igualar o máximo possível nos diferentes produtos e serviços as linguagens utilizadas, os ambientes de clouds (deploys, pipelines, bancos de dados), arquiteturas e design patterns.
De acordo com a unidade de negócio, podemos (e vamos!) precisar de tecnologias específicas, e não teremos como fugir de processos únicos, mas estes devem ser tratados como exceções.

Vantagens de utilizar os mesmos padrões de tecnologia:

Reuso de códigos

Uma boa prática comumente utilizada em C#, é a criação de pacotes NuGet. São “pacotes” úteis que podem ser utilizados publicamente ou privados. De forma análoga, temos os pacotes NPM em NodeJS, que também podem ser distribuídos de forma privada para uma organização.

Indo além, podemos pensar em módulos que podem ser compartilhados entre aplicações, por exemplo:

API Gateway de pagamentos
Módulo de cadastros
Configuração de embed de dashboards PowerBI

Manobras de alocação de pessoas

De acordo com o objetivo estratégico da empresa, é comum termos que alocar as pessoas em diferentes squads por períodos limitados. A tecnologia, caso destoe demais entre squads, pode ser um limitador para este processo.
Este limite pode ser total ou parcial - no caso parcial, seria a dificuldade de onboarding da pessoa no squad. Desde a configuração inicial do ambiente, do próprio processo de desenvolvimento até o entendimento das regras de negócio. No limite total, impossibilitaria a alocação temporária.

Implementar boas práticas de desenvolvimento

Guia de boas práticas de desenvolvimento organizacional

Além dos padrões de tecnologia, podemos pensar em padrões de boas práticas de construção de código a nível organizacional. Algumas delas:

Proibir mais que 3 níveis de código aninhados

Veja este vídeo BRILHANTE do canal CodeAesthetics no youtube (em inglês): https://www.youtube.com/watch?v=CFRhGnuXG-4
O vídeo entrega exemplos de códigos mal escritos e o processo de refactoring deles. Melhorando sua leitura e manutenibilidade.

Nomes claros em variáveis e funções

Pode parecer irrelevante, mas dar nomes compridos e óbvios as variáveis pode facilitar o processo de entendimento do código.
Este comportamento vem desde quando a programação servia apenas para fórmulas matemáticas, que buscavam reduzir o máximo possível as variáveis até que chegassem em apenas uma letra ou símbolo.
Afinal, x e y não significam nada além de eixos rs.

Incentivo de pair programming

A prática de pair programming, além de contribuir para que os desenvolvedores discutam e cheguem a conclusões juntos, aumentando a estima do time, comprovadamente² também aumenta a eficiência em até 15% do processo de desenvolvimento. Na prática, não temos um volume maior de entregas relevante, mas temos uma diminuição de bugs. Visto que os desenvolvedores vão passar menos tempo construindo código e mais tempo discutindo previamente sobre a determinada tarefa.

Entender quais são seus agressores de produtividade

Entender o cenário que estamos introduzidos pode ser um desafio, principalmente em organizações onde as responsabilidades não estão muito bem definidas. É nosso papel blindar o time de desenvolvimento deste tipo de desalinhamento, e atuar com visão estratégica analisando o contexto.

Existe um princípio que diz que 80% dos problemas vem de 20% das causas, o princípio de Pareto.

Nos outros contextos de processos de produção, a análise através deste princípio é muito comum. Basicamente, devemos focar o esforço nos 20% de causas, e ignorar os 80% restantes.

Parte do nosso papel como gestores, é o entendimento dos nossos agressores de produtividade.

Quais são os processos mais onerosos ao seu processo?

A partir dessa análise de onde o time perde mais tempo, podemos utilizar o princípio para mitigar riscos.

Alguns agressores muito comuns, podem ser:

Processo de Debug
Configuração de ambiente de testes
Conflitos de Merges
Má especificação de requisitos

Para cada agressor, podemos ter diferentes abordagens pensando na sua mitigação.

Por exemplo, para o processo de merge, você sabia que existem abordagens de desenvolvimento que buscam diminuir o máximo possível a quantidade de merges? O trunk based development ou TBD.

Empatia como ferramenta

É importante ressaltar que faz parte do seu papel como líder construir um ambiente de contribuição entre o time.

A empatia é uma ferramenta muito importante, e deve ser ativamente estimulada no time.
Entrevistas, feedbacks 360° e exercitar a escuta ativa, são práticas que podem auxiliar no entendimento das pessoas que compõem o time, e consequentemente, os principais agressores de produtividade que eles sentem.

O problema é eficiência ou visibilidade?

Você está acompanhando o time diariamente, todos entregando. Mesmo assim, seus gestores e diretores continuam com a impressão que seu time é ineficiente e não traz resultados. Os esforços nunca são o suficiente e a conta no fim do mês não fecha. E agora?

Existe um ditado, que infelizmente não consegui encontrar o autor, mas que nos dá uma luz para este cenário:

“- Mais importante que fazer certo o projeto, é fazer o projeto certo”

Entender quais são as entregas estratégicas para a organização é seu papel. A identificação de stakeholders e a gestão das prioridades precisa ser um esforço ativo. Portanto, não basta o time entregar, o time precisa entregar valor. Se o time fizer 10 entregas não prioritárias com qualidade, mas errar na entrega mais importante, qual você acha que será o resultado disso? A percepção de ineficácia, mesmo que pela média o time seja eficiente.

Conclusão

Caro colega gestor, não existe bala de prata. Ferramentas de produtividade ou IAs podem ajudar, mas nos lembremos do princípio de Pareto. O que funciona mesmo é: entender as pessoas e suas necessidades.
Nosso papel é ser o filtro e a direção do time. Nosso resultado não depende apenas de nós, e este é o nosso desafio. Não podemos nos colocar em papel de herói, não vamos conseguir entregar tudo sozinhos. É importante ressaltar que caso você precise ser um, isto não é - e não será - sustentável por muito tempo.

Referências:

Robert C. Martin. 2008. Clean Code: A Handbook of Agile Software Craftsmanship (1st. ed.). Prentice Hall PTR, USA.

Cockburn, A., & Williams, L. (2000). The costs and benefits of pair programming. Extreme programming examined, 8, 223-247.

CodeAesthetics - Why You Shouldn't Nest Your Code

Sommerville, Ian. Engenharia de Software, ED. Pearson, 9a. ed, São Paulo, 2011

https://caetreinamentos.com.br/blog/ferramentas/diagrama-de-pareto-acao-com-maior-beneficio/

https://trunkbaseddevelopment.com/