João Gilberto Saraiva (PT)

The Due Diligence Checklist: a compass for engineering autonomy

2026-01-31T00:00:00+00:00

Over the last few years, I have been synthesizing a personal checklist for software development. It is a fusion of direct feedback from Tech Leads, observations of teams, and operational playbooks — especially from JetRockets — combined with my own background as a professor and academic researcher. This combination of experiences allowed me to solidify a mini framework

Originating in law and business, “Due Diligence” refers to the comprehensive appraisal of a business or situation prior to signing a contract. It is the rigorous investigation required to ensure that all parties know exactly what they are getting into, minimizing risks and surprises. In an era where AI can plan, code, and review faster than ever, our responsibility to verify increases. We must be prepared to take full ownership of the results and evaluate precisely what we are delivering.

In Software Engineering, we can apply this concept to the daily “contracts” we make: the code we ship to production and the questions we ask our colleagues. It is about applying rigor, context, and documentation to the acts of coding and asking.

To ensure that we are not just “task-completers,” but intentional engineers, I propose applying this personal audit before every task.

Phase 1: The Build Checklist (Coding with Context)

Before writing a single line of code, understand exactly what you are getting into.

The “Why”

[ ] Business Goal: Do I truly understand the user problem or business value this task resolves? If I can’t explain why a feature exists, I am not ready to code it.

Software Archaeology

[ ] Pattern Matching: Have I searched for similar features already implemented in the project? Reusing existing patterns ensures consistency.

[ ] External References: If no internal pattern exists, did I research reliable external sources and adapt them to our specific context?

[ ] Architectural Decisions: Have I studied why the current code is written this way? I need to understand the legacy choices before I can introduce new ones.

The Blueprint

[ ] Integration: How will the solution plug into the existing project?

[ ] Harmony: Will the approach clash with the codebase’s style? Most of the time goal is for the code to look like it has always belonged there.

💡 The Innovation Caveat: Sometimes, the goal is to break the pattern. Companies hire engineers to think and act, not merely to reproduce—that is how technical diversity and evolution happen. However, swimming against the current requires stronger muscles. If you deviate from the established architecture, your “Due Diligence” must be doubled. Be prepared to defend why the new approach is necessary and superior.

The Self-Audit

[ ] Goal Check: Does the solution actually solve the initial problem?

[ ] Quality Control: Is the code clean, documented, and compliant with project standards?

[ ] Monitoring & Safety: How will I detect possible problems in production? Do I have a plan to revert changes if necessary?

Phase 2: The “Unstuck” Checklist (Asking with Purpose)

Sometimes, despite our best efforts, we hit a wall. Let’s reflect a little before reaching out for help.

The Solo Mission (Before Asking)

[ ] Consult the Documentation: Have I actually read the manual and READMEs?

[ ] The External Search: Have I checked Stack Overflow or forums for similar errors?

[ ] The Git History: Have I run a git blame to see if a recent change caused the issue?

The Evidence Package (Formulating the Question)

When reaching out to a peer, you shouldn’t just ask for the solution; you must present your findings.

Contextualize: “It’s not working” is not a question. I must explain the specific gap between expectation and reality. Document the Journey:

“I tried X, hoping for Y, but got Z.”
“I looked at the docs for library A, but they seem outdated.”

By documenting the effort, we prove respect for the team’s time. You are not asking them to do the work; you are asking them to unblock the specific obstacle you couldn’t clear yourself.

The Result: A Compass, Not a Cage

In the reality of our daily work—filled with calls, tight deadlines, and urgent bug fixes—I don’t religiously check every box for every single commit. That would be paralyzing.

Instead, I keep this checklist within eyesight. It serves as my anchor.

When everything is flowing, I might skip a step. But when I feel stuck, when the solution isn’t clear, or when I simply run out of ideas, I return to these lists. They force me to pause, breathe, and realign with the process. The idea follows a simple principle: autonomy isn’t about being perfect all the time; it’s about knowing where to look when you get lost.

Image: “Compass” by Johannes Ko. Open Verse, Creative Commons 2.0

Códigos e Aforismos: lições da programação para a escrita nas Ciências Humanas

2025-10-17T00:00:00+00:00

Quem nunca se exasperou diante de um texto, livro ou tese escrito de forma truncada e incompreensível? Ou, o que é pior, se perdeu entre repetições, citações intermináveis e floreios literários que mais obscurece do que facilitam a compreensão efetiva do argumento? Como um professor e desenvolvedor apaixonado por literatura, considero isso um sério incômodo. Em um contexto onde a demanda por conhecimento explorando novos formatos — do YouTube ao Chatgpt, passando por podcasts e games — cresce exponencialmente, a clareza da escrita torna-se uma questão urgente para as ciências no geral e crucial para o ensino.

Um dos aprendizados que o universo da programação oferece para as Ciências Humanas é a prioridade inegociável dada à clareza, concisão e simplicidade. Isso não implica uma linguagem opaca e desprovida de estilo, que imite a frieza de um gerador de texto automático, mas sim uma escrita que se subordina a padrões mínimos de inteligibilidade. Em um contexto em que cada vez mais nos dedicamos a construir ferramentas, bases de dados e narrativas interativas, esse princípio da clareza se torna o elo vital entre a tecnologia e a interpretação humana. Os códigos de programação produzidos em qualquer linguagem, precisam ser suficientemente claros para a compreensão da máquina e de humanos. Devem ser o mais concisos possível para garantir que resolvam problemas de forma eficiente. Uma boa prática de programação, ao se deparar com desafios complexos, é desmembrá-los em partes menores para facilitar tanto o entendimento quanto a manutenção do sistema. Uma das linguagens de programação mais populares, o Python, possui até mesmo uma série de aforismos sobre esse tema, cunhados por um de seus desenvolvedores, Tim Peters. “The Zen of Python” afirma que:

Bonito é melhor que feio. Explícito é melhor que implícito. Simples é melhor que complexo. Complexo é melhor que complicado. … A legibilidade é fundamental.

Ao ler esses aforismos, o amigo historiador Gustavo Mor lembrou das litografias de “Touros” (1945) de Pablo Picasso. Nesse estudo, o artista espanhol produziu a imagem de um touro e a decompôs gradativamente, traço a traço, até encontrar a essência mínima e mais poderosa da figura. Em uma perspectiva visual, Picasso decantou a complexidade até a simplicidade, sem jamais perder a beleza ou a originalidade.

Imagem: “Touros de Pablo Picasso”. Fonte: Art Ref

O paradigma é análogo: o objetivo é manter a linguagem legível e com argumentos às claras, sem abandonar o estilo próprio. O simples é a meta. É evidente que há questões inerentemente complexas que não podem — e nem devem — ser simplificadas sob o risco de tornar uma explicação anacrônica, rasa ou mesmo falsa. No entanto, a complexidade inerente ao tema é sempre preferível à complicação desnecessária e retórica. Paradoxalmente, hoje, nos deparamos em toda parte com textos produzidos por modelos de Inteligência Artificial (IA) que não seguem essa lógica. Muitos deles, mesmo claros, trazem embutidos um entusiasmo excessivo, uma superficialidade mercadológica ou, pior, informações incorretas (as chamadas “alucinações”). Além disso, frequentemente, falta-lhes o essencial que as Ciências Humanas buscam: a nuance, a profundidade contextual e a voz autoral que confere sentido à condição humana — a decomposição do touro de Picasso — é o que nos diferencia.

Esse paradigma ecoa perfeitamente os mandamentos da escrita listados por Robert Darnton — um historiador notório por sua experiência em produzir para os mais diversos formatos:

Não sucumbirás ao monografismo. Escreve monografias, se for o caso, mas escreve para o cidadão comum, de maneira que possam ser compreendidas.

Não esquecerás tua missão. Trata-se de dar sentido à condição humana, explicando as experiências vividas pelos seres humanos – e não marcar pontos entre os colegas acadêmicos.

Certamente Robert Darnton, Pablo Picasso e Tim Peters teriam muito o que conversar!

De todo modo, a questão permanece: vale a pena usar as lições da programação para pensar em uma escrita Zen — clara e concisa — para as Ciências Humanas?

Aposto que sim! A busca pela clareza é a busca pela eficácia na comunicação, e a clareza deve ser um pilar para as Ciências Humanas e especialmente o ensino.

Para saber mais:

Imergindo na IA: notas de um desenvolvedor estudando Aprendizado de Máquina e Ética e Dados

2025-09-22T00:00:00+00:00

Escolhi neste semestre as disciplinas de Aprendizado de Máquina Supervisionado e Ética e Dados como minhas primeiras do curso de Inteligência Artificial (UFRN). A primeira trata de algoritmos que aprendem a partir de exemplos, desde a coleta, sistematização e ajustes de dados até a construção de árvores de decisão e redes neurais artificiais. A proposta é que, ao final do semestre, sejamos capazes de construir modelos preditivos a partir de conjuntos de dados reais. Por exemplo, a máquina receber os dados de exame de um paciente e prever se ele tem ou não predisposição a uma certa doença. Já a segunda trata de dimensões históricas, filosóficas e legais do uso de dados e algoritmos, como vieses, privacidade, transparência e responsabilidade.

Nesses primeiros meses de curso fiz diversas pontes com o trabalho de backend que venho desenvolvendo nos últimos anos, especialmente com projetos de IA que estou trabalhando na JetRockets. Parte dessas pontes diz respeito a questões matemáticas; outras, a modos de ajustar dados enviados e recebidos por modelos de IA; e algumas tratam diretamente de ética e privacidade.

Seguem as principais conexões que tenho observado:

Comunicação com sistemas e modelos externos: um aspecto comum em grandes projetos backend é a integração com diversos sistemas terceiros via filas, APIs e webhooks. Além dos detalhes puramente técnicos, realizar essa comunicação requer desenvolver abstrações que consigam produzir e consumir informações pensadas para outras regras de negócio — por exemplo, meios de pagamento, sistemas de ERP e CRMs. A combinação, suavização e transformação de dados vindos de diferentes fontes é um desafio constante.

No Aprendizado de Máquina, durante o treinamento que dá origem aos modelos, estudamos e praticamos como interpretar e preparar dados vindos de fontes variadas para utilizá-los nos treinamentos e testes. É necessário entender o formato, a estrutura e o significado dos dados, além de identificar e tratar possíveis problemas como valores ausentes, inconsistências e ruídos.

Algo semelhante ocorre na comunicação com modelos de IA via API (como Claude, OpenAI e Gemini): é preciso interpretar e preparar os dados de entrada e saída para garantir que estejam no formato correto e atendam aos requisitos do modelo. Em ambos os casos, é fundamental compreender bem os dados e as necessidades do sistema para garantir uma comunicação eficaz.

Entendendo a vetorização: em projetos de IA, a vetorização é o processo de transformar dados em vetores numéricos para que possam ser processados por algoritmos de aprendizado de máquina. Isso é especialmente importante quando se trabalha com dados não estruturados, como texto e imagens. A vetorização permite que os algoritmos extraiam características relevantes e facilitem a análise e a tomada de decisões.

Em projetos backend, a vetorização também pode otimizar armazenamento e consulta de dados, especialmente quando se trabalha com grandes volumes de informações. Entender seus conceitos e técnicas tem sido fundamental nos projetos em que atuo; estudá-los e praticá-los faz parte importante do meu aprendizado em IA.

Normalizando dados: diversos processos de fusão, comparação e transformação de dados envolvem a normalização — ajustar os valores para uma escala comum sem distorcer diferenças nas faixas de valores. Isso garante que os dados sejam tratados de forma consistente, especialmente em algoritmos sensíveis à escala.

No Aprendizado de Máquina, a normalização é etapa crucial de pré-processamento: melhora performance e convergência dos algoritmos. Em projetos de IA, etapas como a preparação de dados para RAG (Retrieval-Augmented Generation) também envolvem normalização para atender requisitos do modelo. Por isso, tem sido útil revisitar conceitos como média, mediana, moda, variância e desvio padrão, aplicando-os nos projetos da disciplina e nos projetos de IA que venho desenvolvendo.

Entendendo e controlando vieses em dados e algoritmos: os vieses são inclinações políticas, sociais ou de gênero presentes nas fontes de dados. Podem ter raízes históricas e culturais ou ser produto de decisões humanas conscientes ou inconscientes. Eles influenciam desde a seleção inadequada de dados até a representação desigual de diferentes grupos.

No Aprendizado de Máquina, o controle de vieses é preocupação constante, pois podem levar a resultados injustos ou imprecisos, especialmente quando se trabalha com dados sensíveis. O controle de vieses também aparece na preparação de prompts para modelos de IA, onde é preciso garantir que o retorno do modelo seja adequado àquela chamada, muitas vezes mitigando vieses indesejados. Tenho estudado técnicas e estratégias para identificar, mitigar e controlar vieses, garantindo modelos mais justos, transparentes e responsáveis.

Gerindo dados privados: ao lidar com informações pessoais e sensíveis, garantir a privacidade e a segurança dos dados é essencial. Isso envolve adotar práticas e tecnologias para proteger contra acessos não autorizados, vazamentos e usos indevidos.

Na relação com modelos de IA, o gerenciamento de dados privados é uma preocupação constante. Também é fundamental garantir conformidade com leis e regulamentos de privacidade, como a LGPD no Brasil. Tenho estudado legislação e práticas, adotando técnicas e estratégias para proteger a privacidade dos dados com abordagens seguras e responsáveis.

Imagem: “Mergulho” de Anderson Freire. Open Verse, Creative Commons 2.0

Os olhos das pequenas coisas

2025-06-29T00:00:00+00:00

Distraídos sob o amanhecer, alguns acenos e sorrisos desabrocham quando eles passam. Uma bicicleta, uma cadeirinha, um par de luvas e dois capacetes descendo a ladeira às sete horas da manhã. Pai e filha seguem seu caminho matinal de casa até a escola. - Bom dia! Diz a criança com tranças. - Bom dia! Responde o jardineiro com um ciscador em mãos. - Bom dia! Responde a senhora catando recicláveis em frente a um condomínio. A menina de capacete rosa já faz parte do cotidiano dos aposentados na banca do jogo do bicho, dos policiais na padaria em frente e das pessoas que esperam o ônibus para ir trabalhar, mas sua passagem sempre os anima.

Canta Gilberto Gil, com razão, o eterno deus mudança. No momento em que eu mudei de profissão, em que Ada alcançou a idade escolar, a primeira vez que estava livre para trabalhar só depois das oito horas. Foi quando me veio a ideia: pedalar todos os dias juntos. De lá para cá, dois mil e quinhentos quilômetros e três pares de pastilhas de freios. Estimativas apontam 425 quilos de gás carbônico a menos no mundo, mas o peso maior é o da transformação interna, radical e sutil como o olhar de criança.

Pedalando entre Pirangi e Capim Macio, Ada guia nossa atenção para as chananas e outras rosas rebeldes - brancas, roxas e cor de laranja - que nascem no meio-fio. Ela coleta algumas para a professora ou simplesmente para brincar de cozinha mais tarde em casa. Subindo um morro íngreme, ela pergunta como seria uma cidade sem casas, ou se os carros voarem pelo céu ao invés de ocupar as ruas. Ada questiona o que fazem os tratores e outras máquinas que encobrem o som dos pássaros numa determinada rua. Gosta de ver com calma as iguanas saindo da mata, os cachorros e gatos, com e sem dono, que passeiam logo cedo. Seu bom dia surpreende os invisibilizados, os catadores dentro de uma caçamba, os bêbados amanhecidos nas calçadas, um homem sem camisa que por algum motivo faz um buquê improvisado com flores do mato.

Dez anos antes eu estava caminhando pelo centro histórico de uma pequena cidade no norte de Portugal. Naquela manhã cinzenta de inverno, eu parei sozinho em frente a uma fonte seca com uma mureta de pedra, aparentemente abandonada. Passei rapidamente os olhos na mensagem em latim acima dela, pois o que me chamou a atenção foi a combinação de pedra e musgo. Tirei a mão de dentro do casaco para sentir o seu frio refletindo sobre quantas cenas da vida cotidiana aquelas pedras já tinham visto ao longo dos séculos. Por outro lado, me perguntando se as pessoas ainda paravam para ver as pequenas coisas esquecidas nos seus detalhes. Os passos de alguém vindo me tiraram dos meus pensamentos, guardei minha mão no calor do bolso e segui andando sem olhar para trás.

Uma década depois, já sob calor matinal da minha cidade natal, Ada me ensinou que sim. Ainda há quem veja com atenção, que atente para as pessoas e as coisas como quem encontra novidade, mesmo que ela seja banal. Do alto da sua infância, ela incentiva a pintar a realidade com as cores da imaginação, a ver o mundo com os olhos das pequenas coisas.

Imagem: João e Ada a caminho da escola.

Get Certified 2025 - Google Cloud Provider

2025-03-22T00:00:00+00:00

Meses atrás me inscrevi na lista de espera do programa Get Certified 2025 da Google Cloud. O objetivo dele é disponibilizar aulas síncronas, cursos exercícios práticos etc. para se preparar para a prova de certificação de Associate Cloud Engineer.

Já tinha até me esquecido disso quando recebi um e-mail marcando a primeira aula e liberando os primeiros cursos e exercícios. Para avançar de fase é necessário concluir 4 laboratórios práticos sobre VMs, redes, pods e serviços variados da Google Cloud Platform.

Depois de uma semana mergulhado nisso concluí a primeira fase do programa e achei bem legal a combinação de teoria e prática nas aulas e exercícios dos treinamentos da GCP. Todos utilizando as ferramentas reais em uma conta com os custos cobertos pela própria Google.

Devidamente aprovado, fui chamado agora para as 8 semanas de aula síncrona, exercícios, cursos etc. da segunda fase do programa rumo a prova de certificação de Associate Cloud Engineer.

Mais dois meses de leitura e prática pela frente, hora de estudar mais para fazer a prova de certificação. Como se diz no norte da Alemanha:

Moin! Los geht’s!

Imagem: Cloud Computing - Abstract. Source: OpenVerse - license Creative Commons 2.0

Extraindo palavras com Python

2025-01-25T00:00:00+00:00

Acaba de ser publicado em português pelo Programming Historian um tutorial de extração de palavras-chave de documentos utilizando Python. Muito útil para o trabalho de quem extrai dados de documentações como desenvolvedor, cientista social, historiador, etc.

Nele Adam Crymble ensina desde o passo inicial de criação do script até o tratamento do dataset, um excelente conteúdo. Ele foi traduzido do original em inglês por Daniela Gomes e revisado por mim.

Sou grato por poder continuar contribuindo com o compartilhamento e produção de conhecimento livre a partir do elo entre Programação e Ciências Humanas em um projeto tão legal.

O Programming Historian tem lições gratuitas sobre as mais diversas tecnologias e fins em inglês, espanhol, francês, português. Vale muito a pena conhecer, aprender e contribuir com o projeto!

Link para o tutorial: Utilizar Gazetteers para Extrair Conjuntos de Palavras-chave de Textos Corridos

Image: Mulher usando máquina de cálculo. Fonte: Programming Historian.

19 Meetup do GruPy-RN na Activesoft

2024-12-19T00:00:00+00:00

O último sábado foi um dia de aprendizado, troca de experiências e rever amigos no 19º Meetup do GruPy-RN na Activesoft.

Ao longo da manhã aprender mais sobre Raycasting com Anderson Pereira Torres de Sá Neto. Debater decorators e closures com Pablo Gustavo Fernandes Maia e mergulhar em suítes de testes com o botafoguense Vinicius Mendes.

Na última apresentação do dia, falei sobre estratégias para remoção de código legado a partir da experiência do meu time na Performa_IT. Foi bem legal conversar sobre estrutura de squads, como lidar com implementações antigas, e evoluir fluxos das aplicações. O link para os slides estão logo abaixo

Obrigado a todos pelo acolhimento - incluindo um cafezinho maravilhoso - e por instigar boas discussões e risadas sobre tecnologias, processos e relações de amor e ódio com o código legado.

Vida longa ao GruPy e obrigado a Activesoft por nos receber tão bem em sua casa. Até a próxima!

Slides da apresentação: Removendo código legado: algumas dicas práticas

Imagem: Falando sobre produtos legados, fotografia produzida pelos organizadores do Meetup.

Removendo código legado: algumas dicas práticas

2024-10-15T00:00:00+00:00

Você já deve ter visto por ai a frase: “um homem sem barriga é um homem sem história”. Para além do teor cômico sobre a vida, ela nos lembra uma verdade inegável: as pessoas se transformam ao longo do tempo. Os calendários parecem avançar cada vez mais rápido enquanto mudamos de altura, peso, cabelo, roupas, etc. Transformações que não são apenas externas, envolvem humor, paciência, amor, estado mental e muitos outros aspectos. Nesse sentido, os softwares são parecidos conosco porque não são imutáveis. Um par de anos - as vezes, meses ou semanas - e uma função X ou módulo Y não faz mais tanto sentido. Se o contexto mudou, seja por conta dos usuários, regras de negócio ou desenvolvedores, é fatal que aquela aplicação passará por mudanças. Um processo que se desenrola no cotidiano e resultam na acumulação diária aqui e ali de pequenos pedaços de código que estão sem uso ou subutilizados. Como no dia em que decidimos desbravar o cantinho das coisas esquecidas do guarda-roupa ou quintal, chega o momento de remover isso que não nos serve mais. É certo que quanto maior a casa e a família, maior será o volume de objetos sem uso e o trabalho para removê-los dali. A seguir alguns passos práticos para remover essa “tralha” acumulada ao longo do tempo em grandes projetos.

No último ano atuei em atividades diversas de remoção e refatoração de código legado junto do desenvolvimento de novas funcionalidades. A seguir vão cinco dicas práticas obtidas a partir da minha experiência pessoal junto a um time da Performa IT atuando em grande projeto com dez anos de vida, o equivalente a um senhor octogenário em termos de software.

Não dirija o carro de olhos vendados

Um dos desafios para remoção e refatoração de código em grandes projetos é que não é fácil vislumbrar se um código está afetando ou não o fluxo de ações. Afinal, ele é um emaranhado de dependências e relações que não são facilmente visíveis. Por isso, é importante ter uma visão clara do que está além do para-brisas e certeza se toda a mecânica do carro funciona perfeitamente. Uma forma de fazer isso é através de testes automatizados. Eles são uma ferramenta poderosa para garantir que as mudanças que você está fazendo não estão quebrando nada. Testes em quantidade e qualidade são como pneus e pastilhas de freio novas, que garantem que o carro vai andar e parar quando você precisar. Um projeto bem provido de testes para os seus principais casos de uso é bem útil, mesmo que parte deles esteja desatualiza ou quebrada. Eles são importantes indicativos para garantir que as mudanças que se deseja fazer não esta quebrando nada. Na ausência de testes automatizados, é relevante ter um ambiente de homologação onde você possa testar as mudanças que você está fazendo antes de colocá-las em produção. Preferencialmente, um ambiente que seja o mais próximo possível do ambiente de produção e também um profissional QA para validar as mudanças que você está fazendo. De todo modo, mas é pertinente que o desenvolvedor também faça testes manuais e automatizados para ir norteando o que está sendo feito.

Se uma arma aparece na história, ela precisa ser disparada

Este é um princípio de Anton Tchekhov, um escritor russo do século XIX, que diz que elementos presentes em um enredo precisam ser utilizados. Caso contrário, ele não deveria estar lá. É uma ideia de como contar histórias muito utilizada na literatura, cinema, games e, útil também na programação. Um projeto sem código morto é um projeto mais fácil de entender e de manter. Um dos desafios em grandes projetos é que, muitas vezes, o código que você quer remover está sendo usado de modo explicito ou não por outras partes do sistema. Por isso, é importante ter uma visão clara de como o código está sendo usado e por quem para conseguir extrair o máximo de código sem uso. Uma forma de fazer isso é através de ferramentas de análise estática de código, como o Rubocop, que podem ajudar a identificar onde o código está sendo chamado e se ele está sendo usado ou não. Outra forma de fazer isso é através de logs em ambiente de homologação e produção, que podem ajudar a identificar se o código que você quer remover está sendo chamado ou não. É importante também ter um bom entendimento do negócio e do contexto do projeto, vai facilitar a sua vida. Por fim, na dúvida se o código que você quer remover está sendo usado ou não, é melhor deixar como está. Afinal, é melhor ter um código morto do que uma funcionalidade quebrada.

Brincar de apagar e acender as luzes

Uma estratégia para identificar código não utilizado é comentar o código e ver se o sistema ainda funciona. Se o os testes automatizados e/ou os fluxos em homologação continuarem funcionando, é um bom indicativo de que ele não está em uso e pode ser removido. A seguir, “descomentar” o código e testar se os erros se repetem ou não, e se novas partes param de funcionar. A estratégia de “apagar as luzes” comentando código ajuda a identificar também se outras partes da aplicação sem aparente relação com o que está sendo feito. Por exemplo, um método que subterraneamente depende de outro método que foi removido ou que não faz mais sentido. Ainda que o código esteja funcionando e em uso, ele pode estar escondendo problemas que só serão percebidos no momento da remoção. É uma oportunidade para refletir sobre a estrutura do código, verificar se ele está organizado de forma clara e coesa e refatorar o que for necessário removendo interdependências e melhorando a legibilidade.

De fora para dentro

Uma vez identificado um código que não condiz mais com as regras de negócio ou contexto do projeto e pode ser removido, uma boa estratégia é corta-lo de fora para dentro. Ou seja, começar removendo o código que está mais distante do núcleo do sistema e que tem menos dependências, como interfaces que lidam com o usuário final. A seguir, partir para estruturas intermediárias, como controladores e serviços que guiam o que acontece no sistema. Por fim, ir para o núcleo, como modelos e repositórios, que concentram funcionalidades e por vezes regras da aplicação. Se ela possuir testes para cada uma dessas camadas, eles podem ser retirados junto da respectiva fatia, fazendo pequenos desvios ou incisões para que outras partes não sejam atingidas indevidamente. A ideia é que, ao remover o código de fora para dentro, você gradualmente perceba e controle as partes afetadas na remoção, garantindo que o sistema continue funcionando conforme o esperado.

A luneta e o microscópio

Uma dica final é atentar para dois pontos de vista ao mesmo tempo: o da luneta e o do microscópio. A luneta representa o ponto de vista macro, que permite ver o sistema como uma galáxia, identificar os movimentos sistemas solares de modelos, os cometas das APIs e as crateras repletas de código parcialmente funcional nos planetas de módulos. Em um plano ainda mais amplo, estar atento as regras de negócio, integrações com outros sistemas e a arquitetura do sistema facilita muito o trabalho de se mover pela “tralha” de projetos legados, excluindo partes e dando novos sentidos a outras. Já o microscópio é o símbolo para o ponto de vista micro, que permite enxergar detalhes e identificar problemas específicos, como bugs e outro microorganismos escondidos entre as células das classes e dos métodos. Uma variável esquecida pode ser o início de um problema maior, que se diagnosticado cedo, pode ser resolvido com mais facilidade. Combinar esses dois pontos de vista permite encontrar mais facilmente padrões e tendências do código no geral e daquilo que pode ser removido em particular. Além disso, facilita pequenas e grandes refatorações, que podem ser feitas de forma mais segura e eficiente no decorrer do tempo.

Imagem: “Bricklayers, Santos Gonçalves”. Open Verse, Creative Commons 2.0

A beleza do erro: primeiros passos em um app Spring Boot

2024-08-25T00:00:00+00:00

Nas últimas semanas venho me dedicando a um projeto de estudo em Spring Boot, um app de gestão de reuniões online para um sistema de balcão de empregos que vem sendo desenvolvido nos últimos 3 anos, o Alljobs. Como um desenvolvedor do universo Ruby e Python, aprender e escrever em Spring Boot tem sido uma boa oportunidade de errar, ou seja, aprender novas formas de pensar e implementar sistemas.

A ideia é dessa aplicação é poder marcar reuniões entre recrutador e candidato a partir de uma chamada de API. Para isso, o Alljobs Meetings deve realizar uma série de operações:

Verificar se o usuário (user) e recrutador (headhunter) existem no banco de dados;
Verificar a disponibilidade de horários registrada pelo recrutador e candidato;
Encontrar o primeiro dia e horário disponível para a reunião na agenda de ambos;
Criar um link para o encontro online.
Enviar um e-mail de confirmação para o recrutador e candidato.
Salvar a reunião no banco de dados.

Essas ações expressam regras de negócio que complementam o sistema original da Alljobs. Ele tem foco no cadastro, currículo e interações entre recrutador e candidato a partir de aplicações em vagas. Já o Meetings é para o momento em que o recrutador já triou candidatos e deseja falar com algum deles numa chamada. As seis ações do app visam que a reunião seja marcada o mais breve possível, dentro das preferências de cada usuário, sem conflitos de horários com outras reuniões e que eles sejam notificados antecipadamente delas.

Para dar conta desses processos, foram rascunhados diversas formas de organização das tabelas no bancos de dados. Depois de algumas conversas com colegas e pesquisas - viva as comunidades! - foram definidas duas tabelas, uma para as próprias reuniões (meetings) e outra para preferências de horários dos usuários (available_times). A tabela de reuniões armazena os dados da reunião, como data, horário, link da chamada e status. A tabela de preferências armazena os horários disponíveis de cada usuário, com o dia da semana, início e fim de uma janela. Desse modo, um mesmo usuário pode ter várias janelas de horários disponíveis ao longo da semana, e um horário pode ser ou não disponível para dois usuários estarem em uma reunião.

Antes da etapa 1, foi necessário revisar o básico de Java e aprender como criar um projeto em Spring Boot. No primeiro passo utilizei o curso Java Essentials da Linuxtips ministrado pela instrutora Kamila Santos. A partir daí, comecei a desenvolver o projeto, seguindo os passos do ebook e curso base de Spring Boot da Michelli Brito.

O objetivo não foi seguir um livro de receitas, mas sim começar a pensar e escrever com a cabeça de um desenvolvedor dessas tecnologias. Entender como são pensados os objetos, as classes e interfaces, e como eles se comunicam entre si. No processo, tive que me questionar diversas vezes: - Como as pessoas fazem isso no Spring Boot? Onde colocam essa checagem? Qual a melhor forma de persistir esses dados no banco? Algo que seria trivial em Ruby ou Python se torna um pequeno desafio na nova linguagem e framework. Ai está a beleza da coisa: a repetição de erros que leva a aprender.

Entre a etapa 1 e 2, chega o momento dos jardins que se bifurcam - como bem previu Borges. Não existe um único modo de implementar checagens de existência de usuários no banco de dados, e não há um modo estritamente melhor ou pior, mas sim o que é mais adequado para o contexto do projeto. É uma oportunidade para “gastar tempo” estudando e implementando diferentes abordagens Clicar para o projeto realizar o build e ver ele quebrar de novo e de novo, cada vez com um erro diferente. Ou então funcionar e nos testes manuais descobrir que o resultado não é o esperado. Foi o momento de explorar as possibilidades do Spring Boot, as anotações, os métodos, os testes, etc.

Para salvar as preferências de horários dos usuários foi necessário de um lado estudar os modos pelos quais é possível gerir datas e horários nos bancos de dados - utilizado no ecossistema Alljobs - e de outro, como é possível manipular esses dados no Spring Boot.

A primeira descoberta interessante foi que o Postgres - utilizado nos demais projetos Alljobs - tem tipos de colunas específicos para salvar intervalos de datas, horários e números, o que permite trabalhar mais facilmente com eles. Utilizar esses “ranges”, nativos do banco de dados a partir da versão 12, foi uma indicação de colega quando expliquei sobre como pretendia salvar os horários disponibilizados pelos usuários. Mais uma vez, viva as comunidades e seu compartilhamento de conhecimento!

Depois disso, foi necessário destrinchar como o Java e o Spring Boot trabalham com datas e horários. Sem surpresa vi que os modos de fazer isso foram evoluindo ao longo do tempo. Aprendi que o Java 8 introduziu uma nova API para manipulação de datas e horários, a java.time, que é mais robusta e segura que a antiga java.util.Date. No Spring Boot, a manipulação de datas e horários é feita através das anotações @LocalDate e @LocalTime que facilitam a conversão de dados entre o banco de dados e a aplicação.

No fim, não consegui ainda conciliar as ranges do Postgres com os horários do Spring e Java no momento de salvar as preferências dos usuários. Tive que dividir inicialmente as colunas de início e fim de uma janela de horários disponíveis em duas colunas timestamp (data e hora). Dias de estudo que resultaram em fracasso? Só se eu não soubesse que a beleza do erro é a felicidade do aprendiz, a junção de saberes e experiências que não seriam possíveis se eu não estivesse errando e aprendendo continuamente. Que venham os próximos erros nas demais etapas do projeto!

Para conhecer o Alljobs Meetings, acesse o repositório no Github: www.github.com/0jonjo/alljobs-meetings

Para saber mais sobre ranges no Postgres e manipulação de datas e horários no Java e Spring Boot:

Ranges no Postgres: https://www.postgresql.org/docs/12/rangetypes.html
LocalTime e LocalDate no Spring Boot: https://www.baeldung.com/spring-boot-date-fields
Manipulando datas e horários no Java: https://www.baeldung.com/java-date-time

Image: “Spring Flowers & Rain Boots, David Kesler”. Open Verse, Creative Commons 2.0

O que fazer? Como evoluir em cada estágio da carreira?

2024-06-19T00:00:00+00:00

O que fazer? Que decisão tomar? Por que estagnei neste estágio? São perguntas que todo desenvolvedor se faz em diversos momentos sobre sua carreira.

Recentemente, alguém do grupo Ruby Brasil indicou o vídeo da Débora Fernandes sobre carreiras na área de tecnologia. Eu salvei para assistir mais tarde e quando finalmente assisti, entendi o motivo da indicação - o vídeo está logo abaixo. Nesta palestra, ela aborda sistematicamente o que esperar, motivos de estagnação e estratégias para evoluir em cada estágio da carreira, desde júnior até engineering manager. É uma fala valiosa, pois aborda desde expectativas até dicas práticas para diversos momentos da carreira. Independente da tecnologia com a qual você trabalhe, é o tipo de material - os slides também estão disponíveis no link do vídeo - que vale a pena revisitar e obter novas ideias a partir das reflexões da Débora.

Ela parte da perspectiva de que a pessoa deve gerir ativamente suas expectativas e abordar lacunas de conhecimento e atitudes que impedem a evolução. Essa abordagem é semelhante à que eu mencionei na seção “Para quem não sabe onde ir, todos os caminhos levam a lugar nenhum”, em um texto sobre onboardings.

Para cada estágio de carreira, há um tópico de oportunidades. Nessa palestra, ela apresenta dicas valiosas, incluindo como e onde encontrar questões pertinentes para evoluir tecnicamente. É uma excelente oportunidade para refletir sobre o que você tem feito e o que pode fazer para evoluir. São reflexões relevantes para desenvolvedores, QAs, líderes técnicos e todos que trabalham no mundo da tecnologia!

PS: Também está disponível no Youtube um material em que a Débora Fernandes conversa com o Roberson Miguel sobre o mesmo tema, você pode conferir aqui.

Imagem: “Coding?” de Rasagy Sharma. Fonte: Open Verse, Creative Commons 2.0

Woche: da necessidade à aplicação

2024-04-27T00:00:00+00:00

Woche em alemão significa “semana”, se trata de um aplicativo minimalista para organização semanal. Ele nasceu da minha busca por uma ferramenta prática e acessível para gerenciar tarefas, compromissos e notas. Por que fazer mais uma agenda ou “to-do list” em um mundo com Evernote, Notion, Google Keep, etc.? A resposta passa pelo propósito da aplicação e pela expriência de usuário. Como estudante da língua, me inspirei na cultura alemã de simplicidade, organização e praticidade. Ao mesmo tempo, adicionei adaptabilidade e portabilidade ao Woche para atender às minhas necessidades como pesquisador, professor e programador.

Concebendo a ideia

Nos últimos dez anos cultivei o hábito de ter agendas, bloquinhos de anotações e afins. Descobri que é mais fácil lembrar, entender e conectar assuntos quando produzo notas e tópicos em papel. Percebi que ter à mão uma agenda de atividades - seja do trabalho ou vida pessoal -facilita meu planejamento e me ajuda ter em mente o que foi feito, o que preciso fazer.

Empiricamente, descobri que ciclos semanais começando nas segundas-feiras me permitem me organizar melhor entre trabalho, atividades físicas, contas a pagar, compromissos etc. Quando o volume de anotações por semana cresceu, passou a não ser tão rápido achar um registro pessoal ou profissional. Neste momento eu já estava usando menos o papel e mais o celular ou computador para as anotações, então decidi separar as agendas. Ao nomear a aplicação, lembrei das conversas com diversos brasileiros na Alemanha sublinhando como seus colegas de trabalho europeus tem um separação firme entre vida profissional e pessoal. Algo não tão comum no Brasil, mas bem importante para a saúde.

Usabilidade e gestão dos dados

Utilizando diariamente apps de agenda e notas, percebi alguns aspectos que me incomodavam. Anotar um comentário sobre uma reunião é algo trivial, mas nem sempre é simples e rápido. Abrir a página ou app, logar, encontrar o lugar de comentar e finalmente por a informação desejada. Há uma quebra no fluxo de trabalho e, se você estiver compartilhando a tela, pode estar exibindo sem querer suas anotações. O ideal seria fazer isso em um comando simples, que retornasse apenas o que foi anotado e onde.

Muitos aplicativos são fechados dentro de um ecossistema, como Google e Microsoft. Quando meu empregador troca de serviço ou eu mudo de trabalho, não é tão simples exportar e consumir minhas anotações por questões técnicas e legais. Há também aplicações open-source em que é possível ter controle sobre onde suas anotações e agenda são salvas. Tomei-as como base para pensar em um app que salva as anotações localmente e, se o usuário quiser, integra a pasta delas em alguma nuvem.

Optei por um tipo de extensão de arquivo leve e fácil de ler/editar em qualquer tipo de dispositivo, o Markdown. Ele é comum da documentação de projetos e produção blogs, como este que você está lendo, e é fácil de usar. Assim fica simples ler, copiar, editar e compartilhar as informações para e-mails, chats, editores de texto, etc.

As escolhas técnicas

No meu dia-a-dia como programador, o terminal está sempre aberto, então optei por disparar dele os comandos de criar arquivo, adicionar atividade, mostrar conteúdo, etc. Diversas linguagens manipulam textos e arquivos, como Python e Ruby, mas optei por utilizar algo nativo do Linux, os shell script. A ideia foi alinhar a simplicidade com meu propósito de fazer uma aplicação ao mesmo tempo em que aprendo novas técnicas e tecnologias.

A produção de Woche é um exercício de desenvolvimento com CI/CD. Desde os primeiros commits o projeto possui testes automatizados das ações disponíveis ao usuário. Esses testes estão integrados em uma pipeline que roda automaticamente a cada pull request ou commit na para a branch de produção.

A aplicação utiliza tags de versão e tem releases. Além disso, possui um README com funções disponíveis e como fazer customizações - trocar a língua, como e onde salvar as anotações, etc. É um projeto de caráter aberto e experimental que se vale amplamente de experiências e ideias da comunidade do software livre, está sob licença GNU 3.

LINK DO PROJETO NO GITHUB: https://github.com/0jonjo/woche

Imagens: Prints de tela utilizando a aplicação para mostrar agenda da semana e adicionar uma task.

A mágica

2024-03-01T00:00:00+00:00

De certa feita, um coelho branco, de olhos vermelhos e orelhas pontudas adornadas com conchas rosas, contou-me que certa vez perguntou a um mágico como ele o retirava da cartola. O homem de fraque titubeou, sem resposta na ponta da língua. Esboçou com as mãos o movimento de quem tira compras de uma sacola, coçou a cabeça e, sem jeito, mostrou as palmas das mãos para confessar que não sabia.

Ora, ora, você deve estar pensando que não existe coelho branco que fale, nem mágico que não saiba como as coisas aparecem em sua cartola antes de virem a público, em um encontro marcado com os aplausos. No entanto, creia, foi mesmo um coelho branco que me contou que o mágico o retira de sua cartola preta, em um misto de fé e surpresa cotidiana, sem saber como. Não há mistério, apenas a mágica de que existir é mesmo o exercício de uma impossibilidade.

Berlim, inverno de 2024.

Imagem: Magic Rabbit de Gwydion M. Williams. Fonte: Open Verse, Creative Commons 2.0

A arte do onboarding

2024-01-17T00:00:00+00:00

Abrir uma porta e sentir que todas as pessoas daquela sala estão te olhando. Há uma sensação estranha quando somos recém-chegamos em um novo lugar, ela só vai sumir inteiramente quando nos sentirmos integrados. Ao entrar em uma empresa ou projeto, há um período de adaptação e absorção de conhecimento mínimo sobre pessoas, processos e produtos. Esse período, comumente chamado de onboarding, é fundamental para que o novo membro da equipe possa se situar e começar a contribuir de forma mais rápida e efetiva

Cada empresa e time tem processos mais ou menos estruturados de onboarding, que variam em período de tempo total e horas semanais dedicadas a isso. Geralmente, é um período de ansiedade do novo membro da equipe e de descobertas mútuas. Um amigo que passou diversas vezes por esse processo nos dois lados da mesa diz que não há como esperar uma atuação a 100% da capacidade de alguém antes de três meses.

Eu particularmente sou bem atuante em onboardings. Aprendi com meu ex-líder técnico, Nilson Júnior, que é essencial dar todo suporte possível aos recém-chegados. Atentar aos acessos, cerimônias, questões técnicas, etc. e também aos aspectos humanos do processo. Além disso, tendo entrado no mercado de tecnologia depois dos 30 anos com ampla experiência em outras áreas, eu trouxe na bagagem algumas estratégias para acelerar meu onboarding e o de outras pessoas.

O objetivo do onboarding é se situar e começar a contribuir mais rápido e melhor com o time. Aqui vão cinco pontos-chave para isso:

As perguntas do detetive

Ao chegar em um novo ambiente com pessoas que também não conhecemos, geralmente há uma série de dúvidas. Historiadores, médicos, investigadores criminais e pesquisadores das mais diversas áreas compartilham uma estratégia relacionada ao método científico, um conjunto base de perguntas que cabem nos dedos de uma mão. São elas: O quê? Quando? Onde? Como? Por quê?. Elas são um norte para abordar o que vamos conhecendo e também facilitam a reflexão sobre as lacunas de conhecimento que precisamos sobre o novo trabalho. A estratégia é ir anotando, seja no computador ou mesmo em um caderninho, as informações mais relevantes do que vai sendo obtido em chamadas, chats, boards, documentação, etc. e também as novas dúvidas. Por que anotar? Por em palavras ajuda a definir melhor nossas respostas e perguntas, delimitando o escopo e fazendo conexões com outros saberes que já dominamos.

As regras do jogo

As cinco perguntas do detetive são um excelente ponto de partida para a integração de um novo membro em um time. Elas ajudam a entender a empresa, a estrutura e os processos. Mas, para atuar de forma eficaz, é preciso também entender o negócio. Todo software está inserido numa conjuntura própria atendendo demandas específicas. Vale se perguntar: quem é o cliente final da aplicação? Qual o valor que ela entrega para a o cliente? Quais as iniciativas em desenvolvimento e seus principais desafios? Por que elas foram escolhidas? Como esse app se diferencia dos seus concorrentes? Como está o mercado global e nacional desse negócio? Quais os jargões da área? Em uma outra direção você pode lançar perguntas semelhantes sobre tecnologias e ferramentas. Quais você tem domínio? Quais não? Estão atualizadas? Questões como essas nos contextualizam melhor para atuar e nos colocam mais rápido no mesmo nível de conhecimento dos colegas e dos clientes.

É provável que você descubra que parte do time técnico conheça pouco do negócio, pois cada um se foca na sua tecnologia e papel específico. No entanto, isso pode facilitar também a sua atuação técnica, o entendimento das demandas que chegam para o seu time e a qualificação do que você desenvolve no dia a dia.

As expectativas e as pessoas

A entrada de um novo membro em um time é acompanhada de uma série de expectativas. Além da ansiedade e das primeiras impressões do recém-chegado, existem as projeções de lideranças, colegas e clientes sobre ele. É fato, a relação primordial do ambiente de trabalho, antes de qualquer tecnologia, ferramenta ou regra de negócio, é com as pessoas. Uma empresa é um microcosmo da sociedade, com pessoas mais e menos falantes, abertas a ajudar, proativas, introspectivas, etc. É com elas que você lidará 40 horas por semana via chamada de vídeo, chat, e-mail, etc. Entender qual a responsabilidade de cada pessoa é relevante, mas mais ainda o que cada uma faz e como elas são no dia a dia, para além do cargo que ocupam.

Em outra direção, vale entender o que esperam de você. Você veio para substituir alguém que tinha um papel relevante A? Para suprir a falta de pessoal na tecnologia B? Para ajudar a gerir o time? Para ser a liderança técnica? Ter isso claro ajuda a gerir mais rapidamente o que se espera de você e evita embarcar em projeções irreais sobre si mesmo. Tendo ideia do que se espera, é mais fácil abrir sua caixa de ferramentas técnica e pessoal e contrastar suas habilidades com as projeções.

Em um bom processo seletivo, os profissionais já fizeram entrevistas e outras etapas que mapeiam minimamente sua “caixinha de ferramentas” e comparam com as necessidades da vaga. É claro que os recrutadores reúnem indícios, mas é possível haver surpresas positivas e negativas.Para quem mudou de área, trazer habilidades úteis de outras profissões e contextos é muito produtivo. Independente da empresa e do cargo, a habilidade de lidar com pessoas será essencial. No entanto, você pode estar coçando a cabeça e pensando: “Mas eu não sei lidar bem com pessoas”. Bem, é hora de começar a aprender.

Para quem não sabe onde ir, todos os caminhos levam a lugar nenhum

Uma vez que você tem um entendimento mínimo das regras de negócio e tecnologias, das pessoas e expectativas é hora de traçar caminhos. Digamos que você constatou que conhece pouco do negócio W ou da forma como a tecnologia X é utilizada no projeto, ou então que há uma necessidade Y para a qual você pode contribuir usando sua “caixinha de ferramentas” e novas habilidades. Este é o momento de procurar um modo de suprir as lacunas e oportunidades, seja a partir de um livro, curso, projeto de estudo, entre outras opções. Pode ser algo atingível em uma semana ou em meses, o importante aqui é identificar um norte, uma direção a seguir. Não precisa ser um grande plano, delineado nos mínimos detalhes, mas sim ter em mente linhas gerais do que é necessário melhorar e do que você pode contribuir.

É comum empresas terem avaliações semestrais de desempenho e planos de desenvolvimento individual acompanhados pelos gestores. Colocar os pontos que você deseja evoluir dentro desse planejamento é uma boa estratégia. Isso ajuda a estruturar objetivos e as formas pelas quais você pretende alcançá-los. O diálogo com chefia e colegas ajuda a produzir planos realistas, considerando o tempo e recursos disponíveis, bem como seu nível de conhecimento sobre a questão escolhida.

Ação individual, processo coletivo

A figura central do onboarding é quem está chegando. Os holofotes estão sobre ele, o que pode gerar uma ansiedade e medo consideráveis. Se bater um desconforto maior, vale procurar o apoio daquelas pessoas mais receptivas no novo trabalho, dos amigos e das comunidades de que você participa. Você não está só! Eu recomendei ao longo desse texto um papel ativo e interesse genuíno em aprender os processos e se aproximar das pessoas. Essa é a chave para torná-lo mais rápido e efetivo. Só que, é claro, o onboarding é um processo coletivo, envolve gerência, liderança técnica e o time como um todo. Quanto mais as pessoas forem receptivas e existirem ações estruturadas para a chegada de novos membros, mais rápido e menos “sofrido” será o processo.

Se você já esteve em outro time ou empresa, avalie sua própria experiência de como foi sua chegada. O que foi bom? O que faltou? O que você poderia ter feito para torná-lo mais fácil? Essa reflexão vai ajudá-lo em um novo onboarding. Mesmo que você não tenha uma experiência anterior, vale conversar com outras pessoas sobre seus onboardings. Elas trarão perspectivas de outras empresas/times e avaliarão o que deu certo ou não dos dois lados da mesa.

Em resumo, o onboarding é um processo de descoberta que pode gerar ansiedade, estresse, reflexão e até diversão. É uma oportunidade de conhecer uma nova área e modos de fazer distintos do que você está acostumado. É também um momento de apreciar novos caminhos, pois geralmente há menos carga de responsabilidades, uma vez que ainda estão sendo criados os acessos e outras formalidades. Aproveite!

Imagem: Apollo 11 momentos antes de pousar na Lua. Fonte: OpenVerse - licença Creative Commons 2.0.

Encontrar, conhecer e celebrar: dois dedos de café e prosa

2023-12-18T00:00:00+00:00

Transformar café em código é um mote estampado em canecas e camisetas que vemos por aí sobre a vida de quem trabalha com TI. Eu faço parte desse grande grupo de programadores amantes da cafeína, mas a frase também remete à rotina. Quando perguntamos a um programador como é seu dia a dia, geralmente escutamos sobre muitas horas de reuniões, leitura e revisão de código, pesquisa por respostas nem sempre claras e úteis. Há relatos sobre estresse, dor nas costas, noites mal dormidas, insônia, síndrome de impostor - por vezes, depressão e burnout também - além de xícaras e mais xícaras de café. É claro que isso é apenas uma parte do todo, que também envolve aspectos positivos, como salários mais altos que a média, possibilidade de trabalho remoto e benefícios variados. Seja como for, a rotina é uma repetição de ações na frente de telas, com uma xícara na mão. No caso do trabalho remoto, esse é praticamente o único meio de interação com os colegas.

Na prática, a relação laboral também se torna pessoal. De colega de trabalho a amigo? Nem sempre, mas são oito horas por dia de contato. Você conhece o outro e demonstra - mesmo que inconscientemente - seu jeito de falar e pensar, gostos, humor, qualidades e defeitos, alegrias e tristezas de esferas para além daquela pela qual te pagam um salário. Nesse sentido, eu nunca tive a oportunidade de agradecer pessoalmente a diversas pessoas que me ensinaram muito e me apoiaram, nem reconfortar - para além do contato via apps - os infortúnios da vida profissional e pessoal de outras. Há também quem diga que não é possível conhecer de verdade alguém por meio de uma máquina conectada a Internet. Eu particularmente sou desses, gosto de olhar com atenção, em algum lugar atrás das retinas onde mora o pequeno universo de cada um. Dizer que os olhos são janelas para a alma é uma expressão já antiga e bem gasta, mas verdadeira.

É curioso o encontro entre a imagem que fazemos de alguém que conhecemos apenas online e a realidade. Pode haver um instante de dúvida entre um aperto de mão ou abraço, se a conversa será levada com mais ou menos intimidade, se a pessoa é mais tagarela ou tímida do que imaginávamos. Há um encontro entre a imagem que fazemos da pessoa - altura, peso, roupas, jeito de ser e sotaque - e a que está ali, provavelmente também processando esse desencontro entre algum nível de idealização e a realidade.

Semana passada tive a rara oportunidade de conhecer pessoalmente a sede e o time da Performa IT, dos colegas mais próximos até as lideranças. Achei bem legal, claro, a viagem, trabalhar nas bancadas coletivas, o cantinho do café e a gaveta de guloseimas, tratar pessoalmente algo que seriam mensagens no chat, etc. O que achei incrível mesmo foi poder de conhecer as pessoas, apertar a mão, jogar conversa fora, almoçar e pegar um transporte falando da vida e do trabalho. É muito bom ter a chance de contrastar as imagens que tinha na cabeça com as pessoas de carne e osso, com suas características e manias. No mesmo passo, sair das questões cotidianas e celebrar nossas conquistas do ano. Se reunir e poder brindar o que fizemos é dar mais sentido às quarenta horas semanais de código e reuniões regadas às incontáveis xícaras de café na frente do computador. É a oportunidade de conversar, rir, escutar música, dançar, enfim, vivenciar algo juntos. Nem todos são tocados por essas experiências da mesma forma, mas é certo que as percepções de si e dos outros se alteram, pelo menos um pouco, depois delas. Sou grato pela experiência e que tenhamos muitas oportunidades de nos encontrar, conhecer e celebrar!

Imagem: Working hard for a cup of coffee de R. Halfpaap. Fonte: OpenVerse - licença Creative Commons 2.0.

Diplomado 3 anos depois do primeiro if-else

2023-11-20T00:00:00+00:00

Três anos depois do meu primeiro certificado como desenvolvedor, o de Programador Web pelo Metrópole Digital - IMD/UFRN, recebo minha certificação como Especialista em Engenharia de Software na Anhanguera Educacional.

Uma jornada de 10 meses pela arquitetura, metodologias ágeis, modelagem de sistemas, banco de dados e testes.

Obrigado a todos familiares, professores, amigos, colegas de trabalho e membros de comunidades diversas pelo apoio e aprendizados impagáveis ao longo da especialização e nos últimos três anos e meio. Vocês fizeram toda a diferença!

Aprendi a programar com minha filha crescendo na barriga da mãe. Não por acaso ela recebeu o nome de Ada, a primeira programadora da História. Do computador do quarto, acompanhei minha primeira linha de código entrar em produção ao mesmo tempo em que ela se preparava para começar a andar. Recebo este diploma enquanto ela vai terminando seu primeiro ano escolar.

Imagem: Ada Lovelace, 1838, aquarela de Edward Chalon. Fonte: Wikipédia - domínio público.

Crescimento e diversidade nas comunidades de tecnologia

2023-11-11T00:00:00+00:00

Seja nos pequenos ou grandes eventos, é muito bom ver as comunidades de tecnologia a todo vapor. Encontrar pessoas que conheço palestrando, assistindo e debatendo é bem legal, mas é melhor ainda ver novas pessoas - estudantes, profissionais migrando de área, ativistas e curiosos - participando. É certo que sem o fator N, uma quantidade mínima de pessoas interessadas em um tema específico, os grupos desaparecem. Só que o ponto aqui é outro, com novos atores as comunidades crescem não apenas em número, como também em vivacidade.

Nos eventos é perceptível que cada vez menos as comunidades de tecnologia como pequenos mundos à parte, e mais organismos dentro de um ecossistema. Um exemplo é a simbiose, cada vez mais comum, com empresas e instituições de ensino na realização de encontros, meetups, coding dojos, etc. Gurus do mundo digital já afirmaram que, em um futuro próximo, todas as empresas, independentemente do setor, serão empresas de tecnologia. Não sei se é para tanto, mas é certo que eventos como a pandemia de coronavírus aceleraram a transformação digital das sociedades e que a participação da área no PIB global é cada vez maior. Há um fluxo considerável de trabalhadores - a minha história pessoal é um exemplo - que estão migrando para o campo da tecnologia.

Essa injeção de dinheiro e exposição na mídia foi acompanhada também - nem sempre no mesmo passo - pelo interesse dos governos. A expansão do número de vagas e da interiorização de cursos técnicos e superiores na área é um exemplo de política pública que se reflete no crescimento das comunidades de tecnologia. E quando digo expansão, não estou falando apenas do aumento do número de pessoas que participam das comunidades. São novos temas e nichos, como games, participação feminina, tecnologias de assistência e outros. O caldeirão das ideias é enriquecido com a diversidade de pontos de vista e experiências. Essa diversidade proporciona novas aplicações, novos olhares para velhos paradigmas e conexões surpreendentes entre saberes e campos distintos.

Já tive a oportunidade de participar de comitês e grupos de institutos e órgãos públicos que trabalham com temas relacionados a tecnologia e inclusão. Um diagnóstico claro nesses espaços é visível a olhos nu em eventos: as comunidades de tecnologia são bem mais brancas, masculinas e elitizadas que a sociedade como um todo. E quando você observa o quadro funcional das empresas - em que o corte social e de idade se eleva - a discrepância é ainda mais aguda. As razões dessa desigualdade são complexas e há iniciativas variadas para mudar essa situação, como a criação de vagas afirmativas e o surgimento de comunidades voltadas para grupos específicos, abaixo listo algumas delas. É certo que, à medida que as comunidades de tecnologia se expandem, elas também se tornam mais diversas. Uma transformação que deve ser celebrada, incentivada e defendida por todos que acreditam em um mundo mais inclusivo e não segregado por barreiras como raça, etnia, deficiência e gênero.

Para que a inclusão não seja apenas um discurso vazio, precisamos agir para melhorar a qualidade das comunidades de tecnologia que participamos. Não basta as pessoas serem bem-vindas, precisamos construir um ambiente acolhedor para todos, inclusive iniciantes. Um espaço acolhedor e aberto ao debate e aprendizado é essencial para a saúde da comunidade. Tomo como exemplo, o incentivo a participação e a atenção dada a quem está começando no chat e eventos do GRUPY-RN.

No livro “O universo da programação”, o William Oliveira dedica um capítulo específico às comunidades de programação, explicando o que são, como aproveitá-las e como construir um ambiente acolhedor e respeitoso. Destaco dois textos pequenos do William sobre o tema, que dão o tom do que ele aborda no livro: “Não desanime das comunidades de programação” e Não seja um(a) babaca de comunidade. Além dos fatores comportamentais, como a construção de um diálogo aberto e receptivo, é importante também tomar ações práticas para promover a inclusão nas comunidades de tecnologia. Por exemplo, nos eventos do próprio GRUPY-RN, há atenção para o cardápio e o barulho das palmas para atender participantes com necessidades específicas.

Algumas iniciativas legais relacionadas a diversidade no mundo da tecnologia:

Imagem: Communication - ArtPrize 2010. Fonte: Open Verse, Creative Commons 2.0

Associações polimórficas no Ruby on Rails

2023-10-29T00:00:00+00:00

Você já ouviu falar de polimorfia? Segundo o dicionário, é “a particularidade daquilo que pode tomar formas muito diversas”. Em poucas palavras, o poder de se transformar e assumir outra figura. Das histórias da mitologia grega até a Bela e Fera, por exemplo, há inúmeros casos de deuses, titãs e animais polimorfos. Tá, mas o que isso tem haver com programação?

O polimorfismo é um dos pilares da programação orientada à objetos. É algo basilar para quem programa, mas eu nunca tinha acompanhado a implementação de associações polimórficas para resolver algo em um grande projeto Ruby on Rails. Fui pesquisar mais a fundo quando um colega de trabalho propôs utilizar isso numa feature nova de um produto com milhares de usuários. Entre os materiais encontrados, me deparei com um excelente texto introdutório da Campus Code.

Além de explicar em português a base do tema, lista uma série de links em inglês que aprofundam os conceitos, incluindo um ótimo post na página da Thoughtbot sobre polimorfismo.

Com essa bagagem na bolsa, ficou mais fácil realizar testes práticos em um projeto pessoal de estudo - o Alljobs - e utilizar no trabalho.

Para quem quiser saber mais sobre associações polimórficas no Ruby on Rails, esse é o link do texto.

Campus Code - Associação Polimórfica

Imagens: “Vladimir Kush - Metamorphosis”. Fonte: Open Verse, Creative Commons 2.0

Da Alice ao Lego: aprendendo para além da superfície

2023-10-01T00:00:00+00:00

Ao longo das primeiras semanas do curso CS50, uma expressão repetida diversas vezes pelo professor David Malan chamou minha atenção: “see under the hood”. A tradução literal - “ver debaixo do capô” - não nos dá pistas seguras sobre o que Malan quer dizer. Ele está falando em aprender investigando como as coisas funcionam. Parece um conselho óbvio, ir além da superfície para compreender melhor algo. No entanto, é quase um crime - em um mundo cada vez mais acelerado - aconselhar alguém a imitar Alice e descer em um buraco perseguindo o Coelho Branco.

A proposta é justamente essa, levantar as cortinas e entender o que está por trás dos panos. Não se contentar com a informação pronta - x é x, y é y - e fazer a pergunta mais desafiadora das crianças: por quê? A natureza investigadora dos pequenos pode nos servir de inspiração. Por vezes, os adultos se chateiam quando encontram um brinquedo novo sem uma ou duas peças. Mas a criança tem uma dúvida urgente a ser respondida: como é que aquilo funciona? A ideia do professor Malan é responder isso partindo para os conceitos fundamentais do que ele está ensinando e ir combinando-os de modos variados. É claro que este caminho não é útil somente para a Ciência da Computação, mas em qualquer situação que envolva aprendizado.

A curiosidade move o mundo e Alice surpreende-se a cada página de sua jornada. Ela reflete se deve tomar o líquido da garrafa com rótulo “beba-me” e do bolo no qual está escrito “coma-me”. Sua perspectiva é a da dúvida e da experimentação, algo que lhe rende muitas aventuras e saberes. Esse ponto de partida é profícuo para quem quer aprender, pois permite produzir um alicerce firme para o conhecimento.

No início do ano passado, comecei a aprender uma língua nova. Minha irmã, que já domina o idioma, comentou algo que seus professores lhe disseram: o alemão é como Lego, as palavras são formadas pelo encaixe de outras. O que é mágico nesse e em outros brinquedos do gênero é justamente essa capacidade de combinação quase infinita de possibilidades, que permite que cada um possa criar suas próprias formas e sentidos. Meses depois, eu estava vendo algo no mapa da Europa no celular quando fui atingido como um raio pela compreensão de porque a Áustria se denomina “Österreich”. “Ost” significa Leste e “Reich” é Reino. Ou seja, a terra dos austríacos é o reino a leste da Alemanha.

Felizmente, não apenas as palavras e as peças de Lego - que nasceram ali perto, numa carpintaria na Dinamarca - têm a característica de produzir novas formas a partir da junção de outras. O modo como entendemos o que nos rodeia é pessoal e apenas parcialmente transferível para outras pessoas. Não é um método eficiente de aprendizado simplesmente copiar o modo como outra pessoa aprende. É interessante, justamente, formar seus próprios blocos de conhecimento com peças que recolhemos em lugares e tempos diferentes. Encaixá-las de vários modos até chegar numa estrutura firme, mas ao mesmo tempo capaz de ser reformulada com novos saberes que vamos adquirindo ao longo do caminho ou reaproveitadas em situações diversas. Quanto mais fizermos isso, melhores seremos nessa reconfiguração de saberes. Quanto mais olharmos por trás dos panos, mais capazes seremos de entender os conceitos-chave e modelá-los de modo criativo. Não sei se David Malan já brincou um dia com peças de Lego ou leu Alice no País das Maravilhas, mas ele tem toda razão em insistir no “see under the hood”.

Imagens: Alice in Wonderland e Unemployment was high in lego land. Fonte: Open Verse, Creative Commons 2.0

Cinco atitudes para o aprendiz

2023-08-13T00:00:00+00:00

Não é incomum que certo dia, admirando distraidamente o nada com uma xícara de café na mão, nos encontremos refletindo sobre uma ideia, atitude ou informação que teria feito toda a diferença se soubéssemos daquilo antes. Como seria bom entender disso naquela época… Se eu fosse assim há dez anos… Os infinitos “se” que nos assombram de vez em quando ou sempre. Examinar isso através do microscópio da razão evidencia que o que somos e sabemos hoje é resultado justamente dos percalços que passamos, não havia como ter esses saberes e perspetivas sem as vivências que os proporcionaram. É até reconfortante pensar assim, mas não há colete a prova de balas para a vontade repentina de voltar no tempo com aquela atitude ou resposta na ponta da língua. O passado é coisa viva, não dá para simplesmente arquivá-lo numa pasta esquecida do disco de memória. Nenhuma inteligência artificial ou orgânica existe sem processar continuamente seu próprio repositório de informações.

Eu me peguei pensando nisso quando, numa mesma semana, dois jovens me perguntaram sobre habilidades e saberes necessários para começar uma jornada de conhecimento e trabalho. O primeiro, ex-aluno meu do Ensino Fundamental, vai iniciar o curso de História, o segundo é um estudante de programação querendo dar o primeiros passos no mercado de trabalho. Eu me perguntei o que poderia dizer de útil ao adolescente João Gilberto aprendendo a tocar instrumentos musicais e ao mesmo indivíduo quando ele estava prestes a entrar na universidade e primeiro emprego. Também ao professor pós-graduado fazendo suas primeiras linhas de código. Juntei isso a experiência de ter aprendido e ensinado sobre os mais variados temas e sintetizei alguns pontos:

Ter curiosidade genuína: aprender é um verdadeiro martírio se não nos interessamos pelo tema ou não vemos sequer sentido em estar estudando aquilo. É claro que nem todo assunto é a grande paixão que nos entusiasma profundamente, mas os tijolos do desinteresse e o cimento da preguiça formam, na maior parte das vezes, um muro intransponível.
Ser mentorável: estar aberto a aprender com diversas pessoas e em diversos contextos. Muito além da situação formal de sala de aula, a existência é rica em situações em que podemos aprender algo. Estar aberto a isso, ouvidos e ego preparados, é um pequeno preço para o ganho que se pode obter assim.
Saber perguntar: as perguntas movem a humanidade. É uma frase gasta e verdadeira, como mostra o sucesso dos buscadores da internet - o maior deles processa cerca de 3.5 bilhões de perguntas diariamente. Saber perguntar é contextualizar a questão, delimitar o escopo do que se quer saber e considerar efetivamente as respostas obtidas antes de lançar uma nova pergunta. Algo que serve para questionar um colega de turma, um fórum ou mesmo uma inteligência artificial gerativa.
Aprender a aprender: não há uma fórmula pronta através da qual todas as pessoas aprendem efetivamente um determinado assunto. O que existem são estratégias diversas para o aprendizado, mais ou menos efetivas para determinado contexto. Em outro post explorei justamente esse aspecto, desde a escolha do material mais adequado a entender o melhor modo como aprendemos. Vale pensar nas experiências anteriores, quando foi que você conseguiu aprender com sucesso e quando deu errado? E o mais importante, por quê?
Praticar: esses dias conversando sobre a importância da prática para se aprender, eu lembrei uma frase que acredito ser de origem holandesa: “nunca existiu, nem nunca existirá um bom livro sobre como aprender a andar de bicicleta”. A perspectiva não é desmerecer os livros - quem me conhece sabe do meu amor por eles -, e sim sublinhar a importância de se praticar constantemente. A teoria é letra morta se não fundamenta a ação, e bons músicos me fizeram perceber que para se aprender, o melhor modo é começar calmamente com exercícios simples e ir aumentando a velocidade e complexidade gradualmente. Há um ciclo virtuoso entre se deparar com um conhecimento (seja lendo, assistindo, ouvindo, etc.), tentar fazer (exercício, projeto pessoal, conversa e afins) e repetir esse processo mudando as estratégias de cada passo. Já escrevi um pouco mais sobre esse elo entre aprendizado e prática no texto Oleiros do deconhecido.

Imagem: “High five” de Martin Fisch. Fonte: Open Verse, Creative Commons 2.0

Concluindo a jornada do CS50

2023-07-29T00:00:00+00:00

Dando forma ao último exercício da disciplina CS50, a famosa disciplina Ciência da Computação da universidade de Harvard. Ele é disponibilizado gratuitamente pela instituição com todos os vídeos, exercícios, etc. a partir de uma didática primorosa e conteúdos excelentes.

Na imagem uma o print da tela aplicação web em Flask (nada como o bom e velho Python) de compra e venda de ações nas bolsas de valores dos Estados Unidos como cotações, carteira de ações, histórico de transações e outras funcionalidades. Dinheiro fictício, claro, mas dados reais.

Mais para frente quero escrever uma resenha aqui no blog sobre ele, vale muito a pena fazer o curso!