Durante muito tempo, estudar uma tecnologia significava assistir a aulas, realizar alguns exercícios e, eventualmente, guardar pequenos exemplos em uma pasta que dificilmente seria consultada novamente.

Esse formato ainda pode ser útil, mas comecei a perceber que ele não era suficiente para os meus objetivos atuais.

Eu não queria apenas concluir cursos ou acumular anotações. Precisava construir evidências concretas da minha evolução técnica, principalmente nas áreas que passaram a fazer parte do meu posicionamento profissional: PostgreSQL, Database Reliability, automação, DevOps, Engenharia de Software e modernização do desenvolvimento no ERP Protheus.

Foi a partir dessa necessidade que comecei a organizar meus estudos na forma de laboratórios técnicos.

O que considero um laboratório técnico

Um laboratório não é apenas um repositório com alguns arquivos de configuração.

Também não é necessariamente um projeto completo ou pronto para uso em produção.

Para mim, um laboratório é um ambiente controlado no qual posso:

  • estudar um conceito;
  • implementar uma solução;
  • observar seu comportamento;
  • provocar erros;
  • testar alternativas;
  • documentar decisões;
  • registrar limitações;
  • produzir um exemplo que outra pessoa consiga reproduzir.

O objetivo não é fingir que o laboratório representa toda a complexidade de um ambiente real. O objetivo é criar uma base concreta para aprender e discutir um determinado assunto.

Aprender a partir de um problema

Sempre que possível, tento começar por um problema, e não por uma ferramenta.

Por exemplo, o PostgreSQL Reliability Lab não surgiu apenas da ideia de criar containers com PostgreSQL.

Ele surgiu de perguntas como:

  • Como preparar um banco de dados para recuperação?
  • Um backup que nunca foi restaurado pode ser considerado confiável?
  • Como demonstrar replicação de maneira reproduzível?
  • Quais métricas ajudam a avaliar a saúde de um banco?
  • Como simular falhas sem depender de um ambiente corporativo?

As ferramentas aparecem como consequência dessas perguntas.

Docker pode ser usado para criar o ambiente. Scripts ajudam na automação. PostgreSQL fornece os recursos estudados. Prometheus e Grafana podem entrar na observabilidade.

Mas o laboratório continua sendo orientado pelo problema.

Dividindo o aprendizado em etapas

Um erro que já cometi foi tentar estudar um assunto muito amplo de uma única vez.

“Aprender alta disponibilidade no PostgreSQL”, por exemplo, é um objetivo grande demais para produzir uma entrega clara.

No PostgreSQL Reliability Lab, dividi a evolução em etapas:

  1. ambiente básico;
  2. inicialização do banco;
  3. backup e recuperação;
  4. replicação;
  5. failover;
  6. observabilidade;
  7. performance;
  8. pipeline de dados.

Cada etapa pode ser implementada, validada e documentada separadamente.

Essa divisão reduz a sensação de que o projeto nunca termina. Também permite que cada etapa produza um resultado útil, mesmo que as seguintes ainda não estejam prontas.

O mesmo princípio pode ser aplicado ao Protheus Docker Lab e ao Media Transcriber .

Checklist para organizar um laboratório técnico

Na prática, procuro seguir esta sequência:

  1. escolher um problema que possa ser investigado;
  2. delimitar uma etapa pequena e reproduzível;
  3. implementar a solução e provocar falhas;
  4. registrar decisões, erros e limitações;
  5. validar se outra pessoa consegue executar o ambiente;
  6. transformar o resultado em documentação;
  7. publicar quando houver aprendizado concreto para compartilhar.

A checklist não precisa ser seguida de forma rígida. Em alguns momentos, será necessário voltar à pesquisa, rever uma decisão ou reduzir o escopo antes de avançar.

O repositório não é apenas para código

Procuro tratar a documentação como parte do laboratório.

Um bom repositório deve responder, pelo menos, às seguintes perguntas:

  • Qual problema está sendo estudado?
  • Quais são os pré-requisitos?
  • Como executar o ambiente?
  • Como verificar se tudo está funcionando?
  • Qual é o resultado esperado?
  • Quais limitações existem?
  • O que será implementado nas próximas etapas?

Isso faz diferença porque, depois de algumas semanas, até o próprio autor pode esquecer por que determinada decisão foi tomada.

A documentação não serve apenas para outras pessoas. Ela também preserva o raciocínio do projeto.

Do laboratório para o artigo

Depois que uma etapa está implementada, começo a estruturar o artigo.

O fluxo que venho adotando é semelhante a este:

Problema
   ↓
Pesquisa
   ↓
Implementação
   ↓
Testes
   ↓
Documentação
   ↓
Artigo
   ↓
Divulgação

Esse processo evita que o artigo seja apenas uma compilação teórica.

Quando escrevo depois de implementar, surgem detalhes que dificilmente apareceriam apenas com pesquisa:

  • comandos que não funcionaram como esperado;
  • diferenças entre documentação e prática;
  • escolhas de configuração;
  • erros de permissão;
  • dependências ocultas;
  • limitações do ambiente;
  • decisões que precisaram ser revistas.

Esses pontos costumam ser justamente a parte mais útil do conteúdo.

Um projeto pode gerar mais de um conteúdo

Cada laboratório também pode produzir diferentes tipos de publicação.

Uma implementação maior pode gerar:

  • um artigo principal;
  • uma publicação curta sobre uma decisão;
  • um SQL da Semana;
  • uma atualização no README;
  • um post no LinkedIn;
  • uma comparação entre ferramentas;
  • um registro de erro e solução.

Por exemplo, um laboratório de backup e recuperação pode gerar um artigo principal sobre restauração e recuperação para um ponto específico no tempo (PITR), mas também conteúdos menores sobre pg_dump, registros de alterações do PostgreSQL usados na recuperação (WAL), volumes, permissões ou testes automatizados.

Isso permite reaproveitar o trabalho sem repetir o mesmo conteúdo.

Os laboratórios que mantenho atualmente

Hoje meus principais projetos de estudo e portfólio são:

PostgreSQL Reliability Lab

Laboratório dedicado a confiabilidade, recuperação, replicação, disponibilidade, observabilidade e performance no PostgreSQL.

Protheus Docker Lab

Projeto voltado à criação de ambientes Protheus mais reproduzíveis e automatizados com containers, arquivos de configuração e práticas de DevOps.

Media Transcriber

Um projeto em Python usado para estudar organização de código, testes, integração contínua, interfaces de linha de comando e evolução arquitetural.

Apesar de possuírem tecnologias diferentes, os três projetos seguem a mesma lógica: aprender por meio da implementação e transformar o resultado em documentação pública.

O cuidado para não transformar tudo em conteúdo

Existe também um risco nesse processo: começar a pensar em cada estudo apenas como material para publicação.

Nem tudo precisa virar artigo.

Alguns testes são descartáveis. Algumas anotações servem apenas para esclarecer uma dúvida. Algumas implementações ainda não têm maturidade suficiente para serem apresentadas.

Por isso, procuro manter uma regra:

O aprendizado vem primeiro. O conteúdo é uma consequência.

Quando essa ordem é invertida, existe o risco de produzir textos superficiais ou criar projetos artificiais apenas para cumprir um calendário.

Um portfólio baseado em processo

Um portfólio tradicional costuma mostrar apenas resultados concluídos.

Os laboratórios permitem mostrar também o processo:

  • como o problema foi dividido;
  • quais alternativas foram consideradas;
  • o que não funcionou;
  • quais decisões foram tomadas;
  • como a solução evoluiu.

Essa abordagem representa melhor o trabalho de Engenharia de Software, no qual a capacidade de investigar, decidir e evoluir é tão importante quanto o código final.

Conclusão

Organizar meus estudos como laboratórios técnicos mudou a forma como aprendo.

Em vez de acumular cursos isolados, procuro construir projetos incrementais. Em vez de guardar exemplos desconectados, tento produzir ambientes reproduzíveis. Em vez de escrever apenas sobre conceitos, documento o que realmente implementei.

O resultado é um ciclo em que estudo, prática, documentação, portfólio e produção de conteúdo fortalecem uns aos outros.

Os laboratórios não substituem cursos, livros ou documentação oficial. Eles criam o espaço em que esse conhecimento pode ser colocado à prova.

E é justamente nesse momento — quando a teoria encontra os erros, as limitações e as decisões da implementação — que boa parte do aprendizado realmente acontece.

Laboratórios mencionados