DEV Community: He4rt Developers

Programação Criativa: Vamos desenhar com código?

Sara Aniceto — Sun, 02 Aug 2026 01:36:54 +0000

Quem acha que a discussão entre arte gerada por computadores começou com a popularização das ferramentas de IA provavelmente perdeu boa parte das discussões envolvidas em arte generativa, arte computacional e design paramétrico que surgiram ainda no século passado. A Programação Criativa, que vamos entender melhor nesse artigo, é uma das formas possíveis de gerar arte a partir de algoritmos que vai muito além de mandar um prompt pra IA e esperar sua arte ser gerada. É construção, linha a linha, onde o programador faz da tela do computador e das linhas de código seu papel e pincel. Vem comigo entender melhor como usar suas habilidades de desenvolvimento para se divertir, experimentar e deixar a criatividade rolar solta.

O que é Programação Criativa?

Uma das coisas mais legais que ouvi me adentrando nos estudos de creative coding (termo em inglês para programação criativa) é que existem muitas pessoas que programam, mas que não são necessariamente "programadoras". A programação não precisa estar presa apenas à sua carreira, ela pode ser uma paixão, um hobby ou um playground lúdico.

A Programação Criativa é exatamente isso: usar o código para desenhar, criar animações e "brincar" com o computador. Em vez de focar apenas na criação de sistemas ou análise de dados o objetivo aqui é a exploração visual.

Você consegue acreditar que a imagem acima foi gerada com 0 linhas de um código Java? Em seguida vou te explicar melhor sobre o Processing e outras ferramentas de programação criativa.

Processing e p5.js: Onde o desenho encontra o algoritmo

Processing e o p5.js são duas das ferramentas mais populares criadas para facilitar o contato de artistas, ilustradores, designers e pessoas não programadoras em geral que queiram criar arte usando código.

A lógica entre eles é a mesma, o que muda são especificidades da sintaxe de cada linguagem.

Processing: Criado em 2001, é baseado em Java e é o "pai" de tudo isso. É um software gratuito, no formato de IDE, no qual você consegue escrever, executar e compilar os seus códigos, ou melhor suas obras (aqui chamadas de sketches).
p5.js: É uma versão do Processing baseada em JavaScript, mais popular atualmente e feita para rodar direto na web.

Hoje em dia também é possível usar o modelo do Processing baseado em Python e para a criação de aplicativos Android. O mais importante é entender que, enquanto no Photoshop você usa o mouse para desenhar, aqui você começa a desenhar escrevendo em uma página em branco.

A Anatomia Básica do Código (Para quem já coda entender)

Diferente de um script tradicional, a estrutura básica nessas ferramentas é muito simples e visual:

setup(): É a função que roda uma única vez assim que o programa inicia. É aqui que você define configurações importantes da sua arte, como o tamanho do seu "papel" (canvas).
draw(): Aqui é onde a mágica acontece. Essa função é um loop infinito. Ela é lida ciclicamente enquanto o programa roda. Se você desenhar algo aqui, pode criar animações ou responder a eventos, como o movimento do mouse.

Com essa estrutura pronta, vale acessar a documentação e entender as inúmeras possibilidades de formas, elementos tipográficos, animações, etc que é possível criar com essas ferramentas. Esse pedaço de código abaixo é o que gerou a imagem que eu mostrei no início do artigo.

void draw(){
  background(255);
  fill(0);
  noStroke();

  float tiles = mouseX/10;
  float tileSize = width/tiles;

  translate(tileSize/2,tileSize/2);

  for(int x = 0; x < tiles; x++){
    for(int y = 0; y < tiles; y++){

      //Picks the color based on the pixel, in which the pixel is the size of the tiles
      color c = img.get(int(x*tileSize),int(y*tileSize));
      float size = map(brightness(c),255,0,0,20);

      ellipse(x*tileSize,y*tileSize,size,size);
    };
  };
}

Uma ferramenta visual de aprendizado de programação

É possível que você ainda não tenha sido convencido de explorar o Processing e a programação criativa para despertar o lado artista que mora em você? Se sim, eu te faço uma pergunta: quando é que você parou de desenhar e virou um adulto chato sem criatividade?

Brincadeiras à parte, talvez então você seja convencido de que a programação criativa pode também servir como um facilitador para o aprendizado técnico porque transforma conceitos abstratos (como laços de repetição e condicionais) em resultados visuais e imediatos na sua tela.

É como um "debug visual". Afinal, ver um for loop gerando 100 bolinhas coloridas na sua tela em tempo real é a melhor forma de "debugar" sua lógica mental.

Conclusão: Experimente!

Se você sente que a programação às vezes fica um pouco "rígida" ou mecânica demais, tente criar um sketch no Processing ou p5.js. É uma forma de usar sua lógica para algo puramente estético e divertido.

Abaixo deixo alguns links para encontrar referências de projetos, materiais gratuitos e comunidades pra quem quiser conhecer mais:

OpenProcessing: Plataforma de hospedagem de projetos em Processing, é o GitHub da Programação Criativa
Curso gratuito de Programação Criativa: Repositório no GitHub de curso por Monica Rizzolli e Alexandre Villares
Código Transcendente : Uma introdução prática à programação e arte gerativa: Livro de Mateus Paresqui Berruezo
Compoética - Encontro Brasileiro de Programação Criativa
Comunidade de Programação Criativa no Brasil no Telegram

Pensar demais nem sempre ajuda e o que eu aprendi com isso

Yuri Souza — Sat, 01 Aug 2026 10:57:53 +0000

Às vezes, a maior barreira para começar um projeto não é a complexidade do problema, mas a busca por uma solução perfeita antes mesmo da primeira linha de código.

Na semana passada decidi criar um pacote Laravel para integrar a API do Asaas.

A ideia parecia simples: construir algo reutilizável para projetos futuros e, de quebra, aprender mais sobre desenvolvimento de pacotes.

Foi então que eu:

Abri a IDE e comecei a criar um cliente HTTP simples para a API da Asaas.
15 minutos depois, eu já estava pesquisando sobre arquitetura de pacotes open source.
Pensei em DTOs.
Pensei em interfaces.
Pensei em Services

O que eu entendia por "perfeito"?

Na minha cabeça, um projeto bem feito precisava nascer parecido com os grandes projetos open source que eu admirava.

Antes mesmo de validar a ideia, eu já pensava na arquitetura, na escalabilidade e em como aquele pacote pareceria para quem abrisse o repositório. E em outros cenários como:

pensar na mesma arquitetura que grandes projetos usam antes de ter o primeiro caso de uso funcionando;
tentar abordar todos os pontos da API da Asaas logo no começo, mesmo sem saber quais eu realmente ia usar;
imaginar os atrativos que meu pacote teria para outros quererem usá-lo, antes de ele fazer qualquer coisa útil.

No papel, parecia que eu estava pensando como alguém mais experiente, mas na prática, eu estava:

apenas adiando a parte mais importante que era escrever código que resolvesse um problema real.

O custo disso na prática

O curioso é que eu terminava o dia com a sensação de que tinha trabalhado bastante. Tinha lido sobre arquitetura, desenhado camadas, esboçado interfaces.

Só que, olhando para o projeto, praticamente nada tinha sido construído: nenhuma requisição enviada, nenhum teste rodando, nenhuma prova de que qualquer uma daquelas decisões fazia sentido.

Com o tempo, isso começou a gerar um padrão:

Mais tempo buscando a estrutura "perfeita" do que resolvendo o problema real;
Código difícil de entender por estar "bem arquitetado" demais, cedo demais;
Medo de refatorar algo que ainda nem tinha provado valor;
Uma frustração crescente por sentir que eu não estava evoluindo, só girando em torno da mesma decisão de design.

Não era falta de qualidade. Era complexidade antecipada.

O que eu estava realmente evitando?

Foi só depois que comecei a me perguntar outra coisa: por que eu estava tão preso nisso?

Algumas hipóteses:

Eu estava evitando escrever código que eu soubesse, de antemão, que ia precisar refatorar depois?
Eu tinha medo de escrever algo "ruim" e isso aparecer publicamente num repositório open source?
Eu queria provar, pra mim mesmo, que conseguia arquitetar "como um sênior" antes mesmo de ter o problema resolvido?

A resposta provavelmente era um pouco de cada uma. E nenhuma delas tinha relação com o problema que o pacote deveria resolver.

Só bem depois entendi que, no fundo, eu confundia complexidade com maturidade técnica.

O aprendizado que começou a aparecer

Enquanto refletia sobre isso, lembrei de uma frase que minha mãe repetia desde que eu era pequeno:

"Antes feito do que perfeito."

Sempre achei que essa frase servia para tarefas do dia a dia, como arrumar o quarto, terminar um trabalho da escola. Nunca imaginei que ela fizesse tanto sentido ao escrever software.

Junto com ela, veio outra ideia:

Bons sistemas não nascem perfeitos. Eles evoluem.

Nenhum dos projetos open source que eu admirava nasceu com a arquitetura que tem hoje; todos passaram por versões mais simples, mais cruas, que foram se modificando à medida que o uso real foi aparecendo.

Qualidade não está em prever todos os cenários.

Qualidade está em escrever código que consiga mudar quando esses cenários realmente aparecerem.

Foi só quando parei de procurar a arquitetura perfeita que finalmente escrevi minha primeira requisição de verdade para a API.

Antes mesmo de escrever a primeira integração, era assim que eu imaginava o pacote:

CustomerService
        ↓
AsaasClient
        ↓
CreateCustomerDTO
        ↓
Response

Mas não comecei com uma arquitetura cheia de camadas. Comecei com algo assim:

$asaas->customers()->create([
    'name' => 'Yuri Souza',
    'cpfCnpj' => '12345678909',
]);

Desde então, passei a repensar algumas atitudes:

resolver o problema atual com clareza antes de pensar no próximo;
manter o código simples, legível e testável;
criar abstrações apenas quando um padrão se repete de fato, não quando eu imagino que ele vai se repetir;
aceitar que refatorar faz parte do processo, não uma falha dele.

Não se trata de abandonar boas práticas, mas de aplicá-las no momento certo.

O equilíbrio que estou buscando hoje

Hoje tento encontrar um equilíbrio entre dois extremos: nem escrever código sem critério, nem criar uma arquitetura complexa antes que ela seja necessária.

No próprio pacote do Asaas isso já mudou a forma como estou trabalhando.

Hoje, a decisão que tomei foi outra: começar pelo caminho mais curto possível.

Primeiro quero que o pacote consiga conversar com a API e validar os casos de uso mais importantes. Só então vou descobrir quais abstrações realmente fazem sentido.

Em vez de tentar prever a arquitetura que o projeto terá daqui a um ano, prefiro deixar que ela se desenvolva à medida que novos problemas surgirem.

Foi aí que entendi uma coisa importante:

Arquitetura não é algo que eu preciso descobrir antes de começar. É algo que o próprio projeto vai mostrando à medida que cresce.

Conclusão

Ainda estou no começo desse pacote, e ainda estou aprendendo isso na prática, errando e ajustando no caminho.

Mas entender que "perfeição antecipada" pode virar um problema já foi um passo importante na minha evolução como desenvolvedor. O projeto do pacote Asaas não precisa da arquitetura perfeita logo de início; precisa apenas da primeira implementação. O resto vai aparecer conforme o uso real for mostrando o caminho.

Hoje prefiro um código simples que aceite mudanças a uma arquitetura impecável que resista a qualquer alteração.

Se você também já caiu nessa armadilha da arquitetura perfeita antes da hora, quero saber: como você percebeu e o que fez para sair dela?

A discussão continua nos comentários. Quero muito conhecer outras experiências e perspectivas sobre esse tema.

Agradecimentos: obrigado a @vitoriazzp pelo feedback sincero e pelas sugestões que ajudaram a tornar este artigo mais claro e útil.

Se eu pudesse recomeçar em TI, evitaria estes erros.

Aline Santana — Wed, 29 Jul 2026 13:39:48 +0000

Prólogo

No início da faculdade, séculos atrás (papo de 2021, foi quando entrei na he4rt developers inclusive) estava extremamente ansiosa e com isso cometi MUITOS ERROS, me levou ao bornout ficando SEM ESTUDAR por meses, até hoje vejo as pessoas cometendo a mesma coisa que eu no passado e isso atrasa MUITO os estudos! Como sempre meus artigos são super rápidos de ler, espero que gostem!

1º Não dê ouvidos as pessoas da área (depende)

Acho que o maior erro na internet, inclusive através de influenciadores, é o alarme negativo pra cima de áreas na tecnologia e até mesmo linguagens de programação, fazendo com que iniciantes tenham incertezas sobre o que está estudando.

Exemplo 1 : "Você estudando frontend? vai passar fome."
Exemplo 2 : "A IA vai roubar teu emprego como desenvolvedor xxx"
Exemplo 3 : "Flutter vai morrer esse ano de xxx"

Sendo bem sincera, nem ligue pra isso, tá? até hoje tem emprego pra COBOL, imagine pra tecnologias super modernas que muitas empresas usam, escolheu frontend (exemplo) ? estude, se esforce, converse com pessoas mais experientes nesse segmento e vai fundo, não desista por terceiros! Escolheu Python? cai dentro, a opinião da galera não pode definir teu futuro não.

2º Não pula de galho em galho

FOCA NO QUE ESCOLHEU E NÃO PULA, pois foi algo que cometi bastante, eu fui de dados até mobile com Flutter (tô escrevendo isso e rindo alto).

Vocês no outro lado da tela : "Aline, o que você faria hoje?"

Simples, como disse no primeiro artigo, autoconhecimento é importante, o que você gosta? isso que você gosta é evidência no mercado? pesquise, sai na busca.

1. Gosta de Matemática? _Ciência de Dados seria uma boa._
2. Gosta de celular? Por que não se envolve com criação de aplicativos?
3. É mais de "arte"? Já ouviu falar de UX/UI?
4. É visual? e desenvolvimento frontend?

Entende isso? é normal se perder com tantas informações e tantas áreas dentro de tecnologia, vai pesquisando com calma e veja qual se identifica.

3º IA é sua amiga, não inimiga, tenha medo não

Não me venha com o argumento : "Aline, não quero ser de TI pois a IA vai roubar meu emprego", vai nada amigo(a), LLMs em geral são feitas dentro de pesquisas e trabalhadas no que chamamos de probabilidade, é mais fácil tu acertar algo do que ela (risos), não vou ser hipócrita em dizer que IA não ajuda em algo, CLARO que ajuda, inclusive quando se trata de automação de tarefas, mas o que quero dizer é que VOCÊ TEM QUE SABER O QUE TÁ FAZENDO E NÃO DEIXAR A BASE DE LADO, ou seja : "Ai, não vou estudar programação, vou pular pro Claudinho", vai nessa, prejuízo é enorme.

"Mas fulano de tal usa", é que o "fulano de tal" já tem uma base muito sólida no conhecimento daquela linguagem, estamos entendidos? quando passei pela stack de Frontend, era um alarme com Inteligência Artificial gigantesco, tive muito medo e troquei de área, me atrasou muito. (na época)

4º Marca Pessoal galera, é importantíssimo!

Depois de um bom período me tratando psicologicamente (depressão), voltarei com o linkedin, mas vejo que muita gente faz descaso com essa rede, principalmente iniciantes! Motivos? talvez timidez (comum), não gosta, preguiça? talvez, eu não sei, só você sabe.

De forma geral, tenha uma marca pessoal trabalhada, isso é importante até mesmo dentro de comunidades, como os recrutadores podem analisar além do seu currículo destacado? acho um cristal quem faz conteúdo de tecnologia nessa rede, lá estão a maioria dos recrutadores e donos de empresas, seja visto!

Dica geral :

Escolha cores que lhe representam ou que você quer transmitir
Traga experiência real nos seus conteúdos
Não seja um personagem

Conclusão

Espero que tenham gostado desse artigo, eu poderia listar TANTAS COISAS que me atrasaram ou podem atrasar vocês, mas listei as mais importantes da minha vivência e que afeta iniciantes como eu.

Agradeço a He4rt Developers por essa iniciativa dentro da comunidade em instigar membros dentro da escrita

2 métodos que usei (E USO) nos estudos de programação.

Aline Santana — Mon, 27 Jul 2026 14:58:19 +0000

Prólogo

Para uma pessoa que tem TDAH (eu), é extremamente difícil e desafiador encontrar uma maneira mais “confortável” de estudar, ainda mais quando tal assunto é de exatas (sou de humanas e tô em TI, pasmem), então resolvi encontrar algumas maneiras e que claro, deu super certo pra mim e espero muitíssimo que dê certo pra vocês.

Observação (dica) : vai testando cada método, não pegue um como verdade absoluta, o que ficar confortável, use <3

Nem todos vão se dar bem com o método X e Y, cada cérebro funciona de uma maneira diferente, alguns de vocês vão se adaptar com vídeos, textos (artigos como esse), presencial ou online, o melhor jeito de encontrar o método “perfeito” é ter autoconhecimento, eu por exemplo : tem que ser mais prática do que teoria, vídeo aula ? tem que ser curto (longo demais me perco), o estudo tem que ser mais ativo do que passivo, revisão ? 0 aplicativo, revisão pra mim é prática.

Vamos ser bem rápidos com os métodos para usar como um mini caderno.

Método Feynman

Criado pelo físico (vencedor do prêmio nobel, tá?) Richard Feynman, seu método é basicamente fazer autoexplicação usando palavras e analogias de forma mais simples, sem esse jargão técnico que pode mais atrapalhar do que ajudar (ainda mais pra nós, meros iniciantes).

1.1 Já pega seu conteúdo que estuda.

O primeiro passo é escolher o que você está estudando, especialmente o que está travando seu cérebro, aquela parte do estudo que mesmo entendendo ainda sente falta de alguma coisa.

1.2 Explique de forma “leiga”.

Imagina que você é uma criança, primo(a), esse momento é importante que tire os conceitos técnicos que possivelmente pode “impedir” de aprender de forma fácil e explique do seu jeitinho, sem conceitos técnicos, sem palavras difíceis. Um prompt que é meme, mas eu uso bastante é : “Explique assunto xxx como se eu fosse uma criança de xxx anos, sem conceitos técnicos para que eu entenda de forma fácil e rápido”, após isso (novamente como disse) explique para si mesmo.

1.3 Lacunas.

Primo(a), em algum momento da explicação vai perceber que teve algumas lacunas na sua explicação (isso é normal, tá? você tá aprendendo, eu lembro que ficava muito chateada também rs), anote essas lacunas e até mesmo suas dúvidas, vamos para o último passo.

1.4 Refinamento.

Último passo (é bem simples), tudo que encontrou de lacunas e dúvidas você vai achar no material que estudou, anote, identifique e volte novamente ao passo 1.2, onde vai explicar com as lacunas preenchidas. (caso ainda tiver dúvida, repita o mesmo processo até aprender).

2° Active Recall - Meu querido (O que eu faço)

Active recall seria o “método ativo”, iria forçar seu cérebro a relembrar assunto que estudou minutos ou horas atrás, um dos exemplos bem legais é o método feynman que expliquei anteriormente, mas vou explicar a forma que faço.

2.1 - Assista o vídeo até determinado ponto.

Se for uma videoaula (ou qualquer material que esteja usando viu), sempre que o professor concluir a explicação de um tópico e iniciar outro, pause o vídeo e anote apenas os principais tópicos.

Exemplo: o professor começa contando como foi a experiência dele na faculdade de Engenharia de Software. Em seguida, ele passa a explicar por que utilizou determinada linguagem de programação durante o curso. Assim que ele concluir esse assunto e antes de iniciar o próximo, pause o vídeo e anot*e os pontos PRINCIPAIS*, não sua explicação ainda.

Exemplo 2 (anotação) : Aqui ele explicou sobre sua experiência na faculdade. (pronto, escreve mais nada)

2.2 - Torra seu cérebro.

Não volte na sua vídeo aula, documentação e afins, olhe para o tópico anotado e tente lembrar com suas próprias palavras o que ele disse, sim, funciona até com código (é muito bom, mas dá um leve estresse kkk), você escolhe se fará anotação ou explicar com suas próprias palavras (feynman).

Conclusão

Na realidade existem vários métodos de estudos para cada cabeça, como disse no prólogo, autoconhecimento na jornada de programação já é um passo maravilhoso, não se cobre ou até mesmo se estressa demais durante os estudos, é NORMAL não saber de primeira, só não desista.

Agradeço a toda comunidade por sempre instigar a compartilhar nossos conhecimentos.

Como eu venci o medo da transição de carreira

Bárbara Martins da Silveira — Sun, 26 Jul 2026 19:12:49 +0000

Migrar de carreira para a área de tecnologia pode parecer difícil no início. O mercado está cada vez mais concorrido, além de estar passando por muitas transformações. Realizar a transição não é um processo fácil, mas é totalmente possível, mesmo que você esteja em uma área completamente diferente, ou atue há muitos anos em outro setor. Nesse artigo, compartilho como foi o meu processo, além de dar algumas dicas para quem está em transição ou pensando em iniciar a mudança de carreira.

Sumário

O início da jornada
Reconhecendo a insatisfação
Os primeiros medos
Lidando com críticas
A conquista da primeira vaga
Dicas para quem está em transição de carreira:

O início da jornada

Nessa semana completo 1 ano da minha transição de carreira. Sei que, para quem acompanha de fora, pode parecer que foi fácil ou que tive sorte em algum momento. Mas quem está na área de TI sabe o quanto esse processo é complexo. Ao olhar para trás, sinto como se passasse um filme na minha cabeça.

Reconhecendo a insatisfação

Desde o começo, a transição foi difícil: reconhecer que eu não estava satisfeita na carreira atual, lidar com rotina dupla, exaustão, críticas de pessoas próximas e o medo de recomeçar. Antes de iniciar meus estudos em tecnologia, minha rotina era insana e eu dormia poucas horas por noite. Até que percebi que não estava evoluindo e que a carreira para a qual me preparava já não fazia sentido. Foi então que decidi tirar do papel uma vontade que surgiu na pandemia, mas que o medo de começar havia travado: estudar tecnologia.

Os primeiros medos

No início, eu tinha medo de tudo: baixar uma IDE, mexer em código, enviar algo para o git, errar e falhar. Criar um post em rede social como o LinkedIn, então? Parecia absurdo compartilhar que eu estava tentando migrar de área. Mas mesmo com medo, iniciei e não deixei que minhas inseguranças me paralisassem. Consegui começar minha graduação online, muito mais flexível e adaptada aos meus horários, e descobri algo novo: a felicidade em evoluir e aprender sobre um assunto que eu realmente gostava.

Lidando com críticas

As críticas vieram. Algumas pessoas diziam que seria apenas um interesse passageiro, que eu estava desperdiçando meu curso anterior na federal, que era loucura iniciar algo novo nessa altura da carreira. Trabalhei isso em terapia e aprendi a ignorar opiniões que não acrescentavam nada.

A conquista da primeira vaga

Depois de 3 meses estudando, comecei a aplicar para processos seletivos, entender como funcionava o LinkedIn, criar posts, realizar conexões e focar nas áreas que realmente me interessavam. Foi um processo construído aos poucos, mas perdi o medo de escrever e meu perfil deixou de ser invisível. Aos poucos, as oportunidades começaram a aparecer e, em 6 meses de busca, conquistei minha tão sonhada vaga (claro que depois de muitos nãos). Mais do que isso: pude ajudar outras meninas que me procuraram em busca de dicas para ingressar na área, e isso é motivo de muito orgulho para mim.

Dicas para quem está em transição de carreira:

Comece com medo mesmo: no início, o processo é assustador, mas comece com medo mesmo. A primeira vaga é a mais difícil de conseguir.
Aceite que nem todos os dias serão bons: cada dia passado é um passo a menos até conquistar seu espaço.
Mantenha o LinkedIn ativo: mesmo que você não goste da rede, hoje praticamente todas as vagas passam por lá.
Invista em networking: em uma área tão concorrida, relacionamentos são até mais importantes que conhecimento técnico.
Participe de comunidades tech: as comunidades tech como a He4rt são espaços de troca de ideias, colaboração, eventos, engajamento e projetos open source. É o melhor lugar para trocar ideias, conversar com pessoas que estão passando pelo mesmo processo que você, além de participar de projetos reais que podem somar muito ao seu currículo.

Se você pensa em migrar de carreira ou está passando por esse momento agora, lembre-se: essa fase exige paciência e persistência, mas cada projeto, cada conexão e cada tentativa te aproximam do tão sonhado sim. Para quem já passou ou está passando pela transição para TI, quais foram seus maiores desafios e aprendizados? Compartilhe nos comentários! A sua experiência pode inspirar outras pessoas.

Começando com Redes: Camadas de uma conexão TCP/IP

Cristian Magalhães — Fri, 24 Jul 2026 12:37:44 +0000

Eae gente bonita, beleza? Depois de um longo período, resolvi voltar aqui e continuar compartilhando a minha trilha de estudos com vocês. Hoje vou começar (tentar pelo menos) uma série sobre redes.

Por que estudar redes

Começaremos com o porquê de aprofundar os estudos em redes. Conforme a sua senioridade vai aumentando, você vai ganhando novas responsabilidades para si e também dentro do ambiente de trabalho. Levando isso em consideração, ter o conhecimento básico de redes para poder ter mais autonomia e autoridade quando falar de cloud, arquitetura e coisas do tipo realmente não me parece ser uma má ideia. "Ah, mas na minha empresa tem devops que cuida disso", ainda assim, é necessário o mínimo de conhecimento teórico para conversar e até mesmo ajudar a entender o seu problema e criar soluções.

TCP/IP

Explicando a sigla basicamente, o modelo TCP/IP é um conjunto de protocolos de comunicação que permite a conexão e a troca de informações na internet.

O conjunto recebe o nome de seus dois protocolos principais:

IP (Internet Protocol) = Responsável pelo roteamento dos pacotes e endereçamento para que as informações cheguem ao seu destino.
TCP (Transmission Control Protocol) = Está presente na camada de transporte garantindo que nenhum pacote seja perdido ou corrompido.

Como funciona o modelo TCP/IP

Gosto muito de sair do escopo macro para o micro. Basicamente, uma conexão ocorre quando duas máquinas estão trocando informações (pacotes) entre si. E não precisa ser sempre dessa forma; também temos o caso (mais comum) em que uma máquina (cliente) pede informações a outra (servidor).

Ficou simples até demais, né? Para que a troca de informações funcione, existe uma série de passos a serem seguidos. Dentro de uma conexão existem algumas camadas, pelas quais a informação passa antes de chegar ao seu destino.

L7 = É a camada de aplicação, onde a aplicação roda e também onde roda o protocolo HTTP, SMTP.

L4 = Camada de transporte: responsável por garantir a entrega confiável dos dados entre a origem e o destino (é aqui que atua o TCP).

L3 = Camada de rede: responsável pelo roteamento dos pacotes e endereçamento até o destino (é aqui que atua o IP).

L2 = Camada de enlace: responsável por transmitir os quadros de dados entre dispositivos dentro da mesma rede, através do endereço MAC.

Isso é uma regra geral. A camada de cima sempre usa os recursos da camada de baixo para enviar as informações.

Importante lembrar: caso uma camada de baixo não funcione, a camada de cima também não funcionará.

O que é um pacote

Basicamente um pacote é uma carta ou mesmo uma "caixa" por onde as informações são trafegadas na internet. Além das informações requisitadas, nele constam também o remetente e o destinatário, da mesma forma que em uma carta.

Por fim...

Hoje falei um pouco sobre como funciona uma conexão, como é estruturada e como funciona todo o processo de troca de informações. Em breve trarei mais tópicos sobre o que existe dentro de uma mensagem HTTP e coisas do tipo.

Se chegou até aqui, me segue lá nas redes vizinhas.

Contribuir para a comunidade: como destacar isso no seu LinkedIn e currículo

vitoriazzp — Wed, 22 Jul 2026 18:11:09 +0000

Como eu mostro que estou contribuindo?
Posso colocar no meu LinkedIn?
E no meu currículo, como faço?

Foi a partir dessas dúvidas que eu elaborei esse guia pra você que quer contribuir do seu jeito e mostrar às empresas e às pessoas, de forma clara e estratégica, o que você está fazendo.

Vamos lá? 👇

Por que eu deveria mostrar no LinkedIn?

LinkedIn é a porta de entrada para o mundo corporativo no Brasil e no mundo. É por meio dele que você mostra "trabalho". E tem mais: não é só experiência remunerada que conta como evidência de que você tem conhecimento e prática, mas também tudo o que você constrói de forma voluntária, seja tirando dúvida de alguém, participando de um projeto open-source ou escrevendo sobre o que aprendeu. Recrutador não lê currículo pensando só em carteira assinada. Lê pensando em capacidade.

Você contribui com algo para a comunidade e quer colocar isso no seu perfil. Existem 3 formas que você pode usar, e elas podem ser usadas todas juntas ou só uma.

Escolha aquela que fizer mais sentido pro seu perfil ou busque por outras pessoas que você admira dentro da comunidade e veja como elas colocaram no próprio perfil.

1. Seção de Experiência

Use como experiência sempre que estiver contribuindo de forma profissional pra uma área que você busca. Se você participa de contribuições no GitHub, seja através de código, documentação ou outra forma, use como experiência.

Pessoas que também estão ajudando na moderação ou administração (community managers) podem destacar as responsabilidades ou resultados das suas ações por aqui.

Exemplo de como preencher no LinkedIn:

Cargo: [cargo que você faz] Open Source
Empresa: [Nome do projeto/organização]
Tipo de emprego: Meio período (ou Voluntário)
Local: Remoto, Brasil

Descrição:
- Contribuí com [X] pull requests na documentação do projeto [Nome],
  focando em clareza para novos contribuidores.
- Revisei issues abertas e sugeri melhorias de acessibilidade em
  componentes de UI usando [ferramenta/stack].
- Participei de reuniões semanais de planejamento com o time core
  do projeto.

Se estiver em dúvida sobre a sua atuação em algum projeto ou até especificamente sobre como colocar, comenta aqui ou chama a gente no Discord; ficaremos felizes em te ajudar.

2. Seção de voluntariado

Esse espaço é um pouco mais livre. Você pode usar pra mostrar que é membro da comunidade, moderador ou outro cargo que faça sentido e descreva sua participação. Não é necessário listar ou descrever o que você faz, só se quiser 🫣

Exemplo simples:

Organização: He4rt Developers
Função: Devloper Advocated
Causa: Ciência e tecnologia
Período: Março de 2025 - Presente

Descrição (opcional):
- Lidero o programa de advocacia da comunidade, conectando
  membros a oportunidades de conteúdo e mentoria.

Exemplo mínimo, sem descrição:

Organização: Friends of Figma Porto Alegre
Função: Voluntária (fotografia e recepção de convidados)
Período: 2025 - Presente

3. Seção de Projetos

Participa de um projeto específico da comunidade? Essa seção é a mais indicada pra você nesse caso, porque dá visibilidade às suas stacks e skills. Por isso é importante estruturar:

Nome do projeto
Prévia (print ou link do repositório)
Descrição do que é
Stacks que você aplica durante as suas contribuições
(opcional) Marque quem está no projeto com você

Exemplo:

Nome do projeto: Plataforma da He4rt 
Link: github.com/he4rt/heartdevs.com

Descrição:
Landing page da comunidade He4rt Developers,
Construída com identidade visual própria (roxo He4rt, dark mode).

Minha contribuição:
Design e desenvolvimento front-end da página, do wireframe
À implementação em PHP.

Stacks: Figma, React, Tailwind CSS, Claude Design

Depara: quem tem experiência x quem não tem

Um erro comum é achar que sem carteira assinada não tem o que mostrar. Não é bem assim. Muda a forma de descrever, não a legitimidade do que você fez.

Nos dois casos, a régua é a mesma: se você fez, pode mostrar. O que muda é o quanto de contexto você precisa dar pra quem está lendo confiar no que está escrito.

Segunda parada: currículo

É importante manter as mesmas informações que você tem no LinkedIn. Caso não tenha experiência formal, mas contribua pra comunidade, pode colocar diretamente na seção de experiência, com pelo menos 2 bullets do que você fez, como fez e qual foi o resultado.

Exemplo:

He4rt Developers (Tecnologia)
UI/UX Designer | Remoto, Brasil | Março 2026 - Presente

- Desenvolvi microcopy e fluxos de UI para funcionalidades internas
  da comunidade, aplicando princípios de acessibilidade e clareza.
- Colaborei com o time de desenvolvimento na construção da landing
  page de artigos, do wireframe em Figma à entrega final em React.

Exemplo pra quem já tem experiência formal em outra área e quer somar a contribuição:

Friends of Figma Porto Alegre (Comunidade)
Voluntária | Porto Alegre, Brasil | 2025 - Presente

- Apoiei a organização de eventos presenciais, atuando na recepção
  de convidados e registro fotográfico do evento.

Um modelo pra chamar de seu

Pra facilitar essa parte do currículo, criei um modelo que passa tanto pela leitura de um recrutador humano quanto por um ATS (o robô que filtra currículo antes de chegar em alguém). Ele serve tanto pra quem já tem experiência formal e quer só organizar melhor, quanto pra quem está usando a comunidade como primeira experiência pra registrar no papel.

Modelo Currículo (com e sem experiência) - Google Docs

docs.google.com

Contribuir pra comunidade é trabalho, mesmo sem salário no fim do mês. E o trabalho merece estar registrado em algum lugar que outras pessoas possam ver.

Se esse guia te ajudou a organizar como colocar sua contribuição no LinkedIn ou no currículo, conta aqui nos comentários:

Qual a sua maior dor hoje pra mostrar as suas contribuições no LinkedIn ou no currículo?

Produto 4 Devs

Renan Vidal Rodrigues — Thu, 16 Jul 2026 13:43:06 +0000

Todo Dev tem que entender que "ou tu aprende sobre Produto e Regras de Negócio ou tu vai ficar pra trás", o código é só 30% da resolução do problema!

Tabela de Conteúdo

1. Prólogo
2. O que é um Produto? (Sem enrolação)
3. Por que um dev deveria se importar?
4. Diferença entre Projeto e Produto
5. Ciclo de vida do Produto
6. O que importa o Dev entender do ciclo de vida do produto?
7. Conclusão
8. Se interessou?

1. Prólogo

Cada vez mais vejo que é essencial para um Dev ou para um time de desenvolvedores entenderem sobre Produtos e Regras de Negócio, pois é isso que mercado espera.

É como o Daniel (He4rt) Reis sempre fala o mercado espera Devs desenrolados que buscam entender as regras de negocio, do produto em si! Pois código é só 30% do trabalho, os outros 70% são a capacidade de entender o produto e debater sobre o mesmo.

Pensando nisso decidi escrever uma série de artigos focados em Produtos para Devs, buscando preencher uma lacuna comum nas equipes de desenvolvimento, buscando aproximar desenvolvimento e produto sem jargões ou excesso de teoria. Para ajudar aqueles que querem aprender sobre e também uma forma de sintetizar meus conhecimentos.

Mas você deve estar ai pensando:

"Mas Renan esse conteúdo faz sentido pra mim que estou começando a estudar programação agora?

E minha resposta é Sim, esse conhecimento é fundamental para você, seja você uma pessoa que começou a estudar programação agora, um júnior, um pleno, um sênior, ou simplesmente alguém que está pensando em migrar de área. E novamente Sim esse conteúdo é para você ai, que quer se destacar e sair na frente de muita gente que pensa que hoje é só vibecodar e tudo vai dar bom!

Portanto vamos começar abordando o tópico que acredito ser o que é mais sentido para iniciarmos essa jornada que é:

2. O que é um Produto? (Sem enrolação)

Mas e ai o que é um produto de verdade? Um produto não é um software, pois um software pode ser apenas uma ferramenta, um produto é o valor real entregue ao usuário! Um produto é resolver um problema de negocio de forma sustentável!

Um Produto sempre, mais sempre mesmo só ira surgir para resolver um problema, uma dor, uma necessidade ou simplesmente satisfazer um desejo de um usuário ou um cliente. Seja esse usuário uma empresa ou um simples cliente.

Mas vale ressaltar que nem todo produto resolve uma dor intensa, muitas vezes alguns apenas amenizam essa necessidade, alguns ganham tempo, outros geram status ou entretenimento. Mas o mais importante é que sempre um produto entregam algum valor ao usuário.

Mas e o produto digital?
Agora que já entendemos o conceito básico de produto, podemos dizer que um Produto digital é qualquer software que tenha usuários e entregam algum tipo de valor a esse.

3. Por que um dev deveria se importar?

Essa é a pergunta de milhões que faz toda diferença e sua resposta é bem simples quando paramos para pensar que decisões técnicas que são tomadas pelo time tech impactam no negócio, que toda divida técnica também é uma decisão de de produto e que a performance, segurança e escalabilidade também são uma entrega de valor.

Tendo isso em vista podemos entender que um dev que se importa em entender as Regras do Negocio e entender o Valor que o Produto busca entregar, consegue enxergar qual caminho deve seguir, quais decisões devem ser levadas em consideração na construção da arquitetura de um produto, quais funcionalidades agregaram mais valor a experiencia do usuário, como um banco de dados deve ser modelado para poder atender a necessidade deste produto.

Além disso essa compreensão permite o dev questionar, debater e a elaborar planos de ação muito mais eficientes e que muitas vezes evitam muito retrabalho e refatoração de código, que muitas vezes aparecem pelo fato de você ter simplesmente ter "codado" uma funcionalidade sem entender todo o escopo do que o produto se propõem através da mesma.

Então jovens lembrem-se, entender o Produto evita retrabalho, e evitar retrabalho significa menos esforço e mais tempo para outras coisas que realmente valem a pena!

4. Diferença entre Projeto e Produto:

Agora que acredito que já desenvolvemos uma visão legal do que é Produto, podemos debater um pouco sobre a diferença entre um Projeto e um Produto. Claro que neste momento você deve estar se questionando: "Mais não é tudo a mesma coisa no final?" e foi esse mesmo pensamento que tive até entender que:

Projeto:

Tem seu escopo é fechado, muito bem delimitado e definido no planejamento, tendo um começo, meio e fim claramente definidos e desenhados, tem um foco na entrega com um caminho bem documentado e claro pode funcionar em cenários previsíveis.

Produto:

Já um produto tem um escopo mais aberto pois seu foco inicial é resolver uma problema e não o como, geralmente ele tem um começo e meio que podem ser identificáveis, mas seu fim não. Seu foco esta no resultado, tendo um objetivo bem definido, e para isso faz uso de experimentação, testes e validação de ideias (Discovery), que servem de guia para o caminho a ser seguido. E é indicado para cenários e contextos voláteis.

Então "não", uma nova funcionalidade não é um novo produto e sim um projeto, um produto é algo maior que vai possuir durante seu Ciclo de Vida alguns projetos (novas funcionalidades).

5. Ciclo de vida de Produto:

Por fim quero aborda um ponto que acho relevante de se ter pelo menos o conhecimento básico sobre. O Ciclo de vida do produto este descreve todas as etapas pelas quais um produto passa dentro do mercado, desde seu lançamento até o seu fim por assim dizer.

Basicamente temos a fase Inovação que engloba desde o desenvolvimento do produto até sua entrada no mercado, onde seu foco inicial no mercado é buscar o Product Market Fit (Bem resumidamente são os clientes que se identificam com o produto), nessa etapa o perfil de usuário é composto por aqueles que são do grupo dos Inovadores (Pessoas que estão usando o produto apenas por ele ser novo ou por apenas querer somente testa-lo) e os do grupo de Primeiros Adeptos (São aqueles que realmente se identificam com o problema que o produto resolve logo de cara e servem muitas vezes como propagadores).

Temos também a fase Crescimento onde o foco é o Growth (Processo contínuo de crescimento do produto no mercado por meio de melhorias no produto, novas funcionalidades e otimização da experiência do usuário). Aqui temos dois grupos de usuários o que chamamos de Maioria Inicial que são aqueles que vem junto logo quando o produto começa a se popularizar no mercado e temos também a Maioria Tardia que são aqueles que chegam depois que o produto já se estabilizou e começou a se consolidar.

E por fim temos a fase de Maturidade aqui nosso produto já se consolidou, mantem uma boa base de clientes fieis e continua entregando valor, deste ponto ou o produto se mantem no mercado ou entra em Declínio.

No processo inicial de um produto logo após a chegada dos Primeiros Adeptos antes da Maioria Inicial, temos um Abismo onde muitos produtos morrem, por não conseguirem cruzar esse abismo. E temos também um abismo após a maturidade uma quarta fase que é quando o produto não consegue seguir inovando e não consegue mais agregar*"valor", que é a fase de *Descontinuar um produto ou Morrer, matar o produto, ou sunset.

6. Mas o que importa o Dev entender do ciclo de vida do produto?

Saber o ciclo de vida do produto pode te ajudar a entender em que fase o produto em que você vai estar trabalhando pode estar e o quanto de esforço e investimento será empregado em cada fase. O quanto o processo de Discovery será necessário para mapear novas funcionalidades e melhorias de fluxos. E o que pra mim faz bastante sentido que é saber quando você pode propor alguma melhoria, nova funcionalidade ou até mesmo a ideia de um novo produto!

Pois um Dev que tem capacidade de ajudar um produto crescer ou até mesmo a capacidade de propor um novo produto, sempre será um Dev diferenciado no mercado! (Claro quando esse tipo de atitude é valorizada)!!!

7. Conclusão:

Nesse artigo entendemos um pouco mais sobre produtos, o que impacta na vida do Dev entender sobre o assunto, a diferença entre um projeto e um produto e compreendemos um pouco sobre o ciclo de vida do produto.

Tudo isso para tentar ajudar você a ser um pouco mais um Dev Desenrolado, que tem uma visão mais macro do processo, que vai muito além do Código.

8. Se interessou?

Eu sou o Renan Vidal, trabalho como Product Owner já a algum tempo e agora estou estudando para migrar mais ainda para a área de produto, e com tudo que venho estudando e com toda experiencia que já tenho de mercado, e posso te dizer com alguma certeza que um Dev que se preocupa entender sobre Produtos e Regras de Negocio está na frente de muita, mas muita gente mesmo.

Espero que tudo que escrevi aqui tenha algum sentido para pelo menos uma pessoa, e no caso de duvidas ou se deseja que eu aborde algum tópico de produto mais aprofundada é só deixar seu comentário!

Métricas de qualidade de software na era da IA

Alicia Marianne Gonçalves — Thu, 16 Jul 2026 00:12:21 +0000

Não é novidade para ninguém que estamos passando por uma transformação na área de desenvolvimento de software, em que a IA está assumindo diversas atividades. E isso me faz pensar: o que vamos medir, ou o que teremos como parâmetro para qualidade de software daqui pra frente? É sobre isso que vou falar neste texto.

Antes das métricas: entenda o momento do seu time

Antes de entrarmos nas métricas em si, precisamos entender o momento em que o nosso time está. É muito fácil eu simplesmente jogar métricas aqui e você aplicá-las ao seu time de maneira automática — mas será que elas fazem sentido para o seu contexto?

Uma coisa que eu falo bastante aos meus alunos da mentoria que dou na He4rt Developers é: pra que eu quero isso? Softwares representam necessidades do mundo real, logo, medir o sucesso e a qualidade deles vai depender muito das necessidades que eles buscam suprir.

Partindo agora para as métricas, eu gosto de dividi-las em dois grupos:

Métricas para stakeholders
Métricas para o time

Qualidade de software não se resume a número de bugs — ela se aplica tanto em como o software é recebido pelo cliente final, quanto em como ele é desenvolvido.

Métricas para stakeholders

Uma coisa que eu aprendi neste tempo na empresa em que tenho atuado, principalmente com a transformação digital, é que mostrar número de bugs abertos ou resolvidos não mostra para o público o que realmente importa: como está a qualidade do produto. E, para me ajudar nisso, eu sempre tento me colocar no lugar de um cliente que não tem conhecimento profundo sobre o ciclo de desenvolvimento de software.

A primeira coisa que eu gostaria de ver quando um QA, ou o time, vier me mostrar os resultados de uma sprint ou de um quarter é: quantos problemas eu tenho em produção — mas não só isso, quanto tempo tenho levado para resolvê-los.

Mean Time to Resolve/Repair (MTTR)

Essa é a famosa métrica que vai mostrar o tempo que leva desde que o problema é identificado até ele ser resolvido em produção. Dependendo de como é o seu processo de desenvolvimento, isso pode ser medido de formas diferentes. Se você tem um processo em que o cliente primeiro reporta para o suporte, o suporte faz uma pré-avaliação e só depois disso o problema vai para o time resolver, você pode medir em dois momentos: o tempo que o suporte leva para avaliar o problema e dar um primeiro parecer, e o tempo em que esse ticket de suporte de fato se torna um bug e entra na esteira de resolução.

Cobertura de testes automatizados

Outra métrica interessante de se mostrar para um time de stakeholders é a quantidade de testes automatizados — porém, não isolada. Acho que você já deve estar cansado de ouvir que ter 99% de cobertura de testes não significa qualidade, mas como posso apresentar essa métrica ao stakeholder de forma que ele veja o valor do investimento em automação que o seu time está fazendo?

Uma coisa importante a analisar nesse contexto é se a cobertura de testes está realmente pegando os cenários importantes do sistema. Exemplo: se, no seu contexto, o seu MTTR está alto mas a sua cobertura de testes está alta, isso significa que a sua cobertura não está cobrindo o que realmente precisa ser coberto.

DORA Metrics

Além dessas, as DORA Metrics são grandes aliadas para auxiliar nesse diagnóstico.

As DORA Metrics (DevOps Research and Assessment, hoje parte do Google Cloud) nasceram para medir a performance de entrega de software, mas, na prática, funcionam como um termômetro da qualidade do processo como um todo — porque times que entregam rápido e com poucos incidentes são times com um pipeline de qualidade (testes, revisão, observabilidade) bem construído.

Fonte oficial: dora.dev — pesquisa contínua do DORA (Google Cloud) sobre as métricas e capacidades que diferenciam times de alta performance. Vale a leitura direta da fonte para acompanhar atualizações do modelo, como a inclusão de Reliability como quinta métrica.

Deployment Frequency (Frequência de Deploy)
Com que frequência o time coloca código em produção. Deploys menores e mais frequentes são mais fáceis de testar e, se algo der errado, mais fáceis de isolar a causa — menos mudanças acumuladas por deploy significa menos variáveis para investigar. Uma frequência de deploy caindo pode ser sintoma de um time com medo de quebrar produção, geralmente por falta de confiança nos testes.

Lead Time for Changes (Tempo entre o commit e a produção)
Tempo desde que uma mudança é commitada até ela estar rodando em produção. Um lead time alto muitas vezes esconde um gargalo em etapas de validação manual demoradas, ou retrabalho por bugs encontrados tarde no ciclo. É uma métrica que expõe se o teste está acontecendo cedo (shift-left) ou só no fim, represando a entrega.

Change Failure Rate (Taxa de Falha em Mudanças)
Percentual de deploys que causam falha em produção (incidente, rollback, hotfix). É, de longe, a métrica DORA mais diretamente ligada à qualidade do processo de teste. Está diretamente relacionada à cobertura de testes: se essa métrica está alta, significa que a sua cobertura de testes está baixa ou, como dito anteriormente, não está cobrindo o que realmente precisa ser coberto.

Time to Restore Service (Tempo de Restauração)
Tempo médio para restaurar o serviço depois de um incidente em produção (rollback, hotfix, correção de configuração). Mede a capacidade do time de reagir quando — não se — algo dá errado. QA pode influenciar diretamente essa métrica ajudando a desenhar testes de rollback, feature flags e smoke tests pós-deploy que aceleram a detecção e a decisão de reverter.

Reliability (Confiabilidade — métrica mais recente do modelo DORA)
O quanto o sistema atende às expectativas de disponibilidade e performance do usuário no dia a dia, não só durante incidentes. Conecta a qualidade percebida pelo usuário com o trabalho de teste não funcional (performance, disponibilidade) — é o lembrete de que qualidade não é só "não ter bug", é o sistema se comportar bem sob uso real.

Métricas para o time

As métricas para stakeholders ajudam bastante o time a ver o estado daquilo que estão produzindo, mas, às vezes, você quer enxergar a qualidade no próprio processo de desenvolvimento do software. Aqui podemos ter métricas mais pontuais.

Root Cause Analysis

São métricas que ajudam a ver os padrões dos problemas que acontecem no software ou durante o desenvolvimento e, a partir delas, pensar em planos de ação. Exemplo: se eu tenho muitos problemas relacionados a falta de requisitos, posso deixar os requisitos mais explícitos nas tarefas e, daqui a 2 ou 3 sprints, validar se esse tipo de root cause se tornou menos frequente ou não.

Bugs identificados antes do lançamento

Existem algumas métricas que você também pode extrair relacionadas a bugs, como: quantos bugs foram identificados antes mesmo de lançarmos a feature em produção? Isso pode ser alimentado tanto pela execução de testes manuais quanto por testes automatizados que falharam ao adicionar uma nova feature.

Retrabalho

É possível também calcular o retrabalho, uma métrica que vai te ajudar tanto a ver se o número de bugs está aumentando ou não quanto no planejamento. Quando o seu time costuma ter uma taxa de retrabalho de 10%, é possível alinhar com os Product Owners 10% de margem dentro de uma sprint para possíveis bugs. Assim, o planejamento se torna mais realista, as expectativas ficam alinhadas, e o cliente e o time ficam mais felizes.

Conclusão

Com essa transformação digital, é importante entendermos que temos métricas que podem nos auxiliar a medir o ciclo de desenvolvimento e a qualidade do produto — e o principal é que nenhuma delas, isoladamente, traz valor. Elas precisam ser lidas em conjunto, cruzadas entre si, e sempre voltando para aquela pergunta inicial: pra que eu quero isso?

Com a IA aumentando a produção de código, a tendência é termos mais código sendo escrito, mais features sendo entregues e mais decisões sendo tomadas em menos tempo. E é justamente por isso que medir vai se tornar ainda mais importante do que já é hoje: se antes um time levava dias para gerar uma quantidade de código que hoje pode ser gerada em horas, os erros também podem se multiplicar na mesma velocidade — só que muitas vezes invisíveis até chegarem em produção.

Por isso, acho que o papel do QA nesse novo cenário não é só testar mais rápido para acompanhar o ritmo da IA, mas também ser a pessoa que garante que estamos olhando para os números certos. Não adianta ganhar velocidade e perder visibilidade sobre o que está sendo entregue. Então, o convite que eu deixo é: olhe para essas métricas não como números para preencher um dashboard, mas como perguntas que elas estão te fazendo sobre o seu processo. E use a IA para te ajudar a responder essas perguntas mais rápido — não para substituir o hábito de perguntar.

Como escolher eventos de tecnologia para participar

vitoriazzp — Mon, 13 Jul 2026 17:45:47 +0000

Quando comecei a ir a eventos de tecnologia, estava na faculdade e ia a todos os gratuitos ou que custavam, no máximo, 100 reais. Porém, eu estava começando em TI e sabia tão pouco sobre a área em que eu queria atuar, logo qualquer evento despertava minha curiosidade.

Os anos passaram e eu me tornei frontend e passei a participar de eventos como front in (sampa, floripa, poa), TDCs, Roadsec (the mind sec) entre outros aí.

Por que ir a esses eventos?

Desde que comecei a fazer freelance e me formei, percebo que é onde eu descubro as tecnologias e os problemas que as pessoas têm percebido. Também é uma forma prática de eu sair da minha zona de conforto e conhecer pessoas, visões de mundo diferentes e voltar com ideias pros meus serviços.

Quando eu estava na faculdade, era muito mais simples ter essas duas "pontes" de comunicação e também de venda de solução. Após me formar e começar a trabalhar, percebi que a prospecção de clientes seria muito mais difícil se eu não estivesse nesses eventos.

Mas Vih, eu estou estudando, não estou mirando em freelance, do que me adianta ir?

Adianta que você conhece pessoas, faz amigos ou pessoas que vão te contratar ou indicar em trabalhos futuros. Além das palestras que podem te mostrar uma área dentro de TI que você ainda não conhecia e pode acabar gostando.

Como eu escolhia os eventos que iam fazer diferença pra mim?

1) Eu tinha uma lista de assuntos e áreas de que eu gostava ou que acompanhava já nas redes sociais, exemplo:

- frontend: flutter, react, html/css, boas práticas, realidade aumentada
- segurança da informação: hacks, boas práticas, curiosidades etc
- backend: qualquer stack pra se atualizar
- design ihc, ux, produto, estratégia, marketing

2) Seguia no Instagram as pessoas dessas áreas, que às vezes eram as mesmas que participavam dos eventos, por exemplo:

@juliallabs
@stherzada
@danielhe4rt
@spacecoding
@nataliafdev
@omarcusdev
@dessadev

Esses são alguns dos exemplos que eu mais acompanhava no Instagram, algumas pessoas também têm perfil nesta plataforma, mas o conteúdo sobre eventos está no Insta!

3) Tinha uma noção do custo de alguns eventos, e quais eu podia arcar, quais eu precisava pra me atualizar ou fazer networking específico:

Conferências até R$ 1.500;
Eventos/meetups de R$ 0 a 600; > Ter a meia-entrada ou o ingresso solidário ajudava a pagar menos; às vezes, a faculdade ou o emprego pagava a entrada em troca de trazer o conteúdo aplicado. Vale consultar a disponibilidade pra economizar.

Mas qual a diferença entre conferência, eventos, meetups?

Conferência costuma ser um evento amplo; faz-se pra apresentar conteúdos específicos, e o público costuma ser de empresas que levam o funcionário ou de pessoas que já estão no mercado e conseguem arcar com o custo do ingresso.
Eventos podem ser pagos ou gratuitos; costumam ser organizados por empresas, mas às vezes comunidades também.
Meetups são frequentemente organizados por comunidades e podem ou não ter custo; depende do lugar em que acontecem.

Onde eu posso achar eventos de tecnologia?

Existem os sites de venda de ingresso como

Summits são mais voltados para empresas ou empreendedores; os valores são bem altos, mas consegue desconto dependendo da tua empresa ou faculdade. Vale a pena se pretende atuar em algum setor muito específico.

E você? Como costuma escolher quais eventos de tecnologia ir?

Ownership: do "temos um rojão na mão" até "não precisa mais pensar nisso"

Daniel Reis — Wed, 08 Jul 2026 17:25:50 +0000

É aquele famoso "ou faz direito ou não faz" que todo dev deveria respeitar desde o inicio dos seus estudos.

Tabela de Conteúdo

1. Prólogo
2. Entenda o problema real
3. Projete antes de codar
4. Execute
5. Verifique (em produção)
6. Comunique
7. Acompanhe
É muita coisa. E olha que ainda tem mais.

1. Prólogo

Acho que toda vez que eu vejo um dev iniciante, meu primeiro pensamento é: a hora de "criar" responsabilidade é literalmente agora, no inicio da carreira. Por exemplo: quando eu era junior eu pegava task, escrevia o código, mandava o Pull Request, que era mergeado e ia dormir feliz. Três dias depois o problema voltava, do mesmo jeito, e adivinha quem teve que mexer de novo? Eu. Por anos eu continuei fazendo aquilo, esquecendo daquela frase clichê de que: "30% do trabalho é de fato código". Mas ai de fato, quais são os outros 70%?

Quando comecei a me perguntar isso, simplesmente entendi que: eu tinha entregado um código, por anos não tinha resolvido um problema. E é sobre isso que a gente vai falar hoje.

Eu uso muito a palavra ownership. Vivo falando "você pode assumir isso?", "consegue cuidar disso?", "tá com você?" e faz um tempão que eu não paro pra explicar o que ownership significa pra mim. Então bora lá, que hoje o assunto é esse.

Quando eu te pergunto "você pode assumir isso?", presta atenção: eu não tô te pedindo pra escrever um código e mandar um PR. Eu tô te pedindo pra ser dono da solução de um problema, de ponta a ponta. Do "temos um problema" até o "não precisa mais pensar nisso".

E cara, isso muda TUDO. Assumir uma tarefa é entregar um código. Assumir um problema é garantir que ele deixou de existir, e que ninguém, você inclusive, vai precisar voltar a pensar nele nunca mais. Quando você fala que tá resolvendo alguma coisa, a expectativa é que você faça essa porra toda que vem abaixo. E ó, não é papo de gestão não: dominar isso é o que faz o time te dar problema cada vez maior sem medo. É basicamente o cheat code pra virar sênior de verdade, não sênior de tempo de casa.

2. Entenda o problema real

Antes de qualquer linha de código, tenha CERTEZA de que você sabe o que tá resolvendo.

O erro mais comum do mundo é começar pela solução. Você provavelmente já tem uma na cabeça sem ter parado 5 minutos pra pensar no que a gente tá de fato tentando resolver. Se você acha que "o problema é que precisamos migrar de X pra Y", pera aí mano, isso não é um problema, isso é uma solução. O problema de verdade é algo tipo "a performance tá uma merda", "não é estável", "quebra pro cliente X".

"Migrar do MySQL pro Postgres" é solução.
"A busca de membros da comunidade demora 8 segundos" é problema.

Sacou a diferença? Beleza. Uma vez que você tem o problema real na mão, a próxima pergunta é: será que existem outras soluções possíveis? Pensa nelas. Um índice resolve? Um cache resolve? Reescrever aquela query zoada resolve, antes de trocar o banco INTEIRO? Cada caminho tem seus tradeoffs. Qual é o melhor levando isso em conta?

Se você pular essa fase, você corre o risco de passar duas semanas construindo a solução perfeita pro problema errado. E aí não tem PLAU que salve.

Nosso caso (a busca de 8s): o problema não é "migrar pro Postgres". É "a busca de membros demora 8 segundos". Antes de trocar de banco, será que um índice não mata isso?

3. Projete antes de codar

É aqui que a maioria dos problemas de produção nasce: nas perguntas que ninguém fez antes de começar. Então vamo fazer elas agora.

Pensa nos edge cases. Quais são? Quais são importantes? Quais dá pra ignorar de propósito (e deixar registrado que você ignorou)? Membro sem avatar, nome com emoji, lista vazia, fuso horário diferente do servidor. Escolher o que ignorar é uma decisão consciente; ignorar sem perceber é um bug esperando a hora de estourar na sua cara.

Pensa nas falhas. Falha de rede, por exemplo, é GARANTIDA. Como a gente lida com ela? Retry? Tá, mas com que frequência? Por quanto tempo? O webhook caiu: retry com backoff? três tentativas? e depois, descarta ou joga numa fila de reprocesso?

Pensa no fluxo de dados. Quanto dado tá envolvido? Precisa migrar algo? Limpar algo? Como você consegue dado de verdade pra testar direito? Quais invariantes existem nos dados? E principalmente: quais premissas sobre o formato dos dados você tem e ainda não confirmou? "Todo membro tem e-mail"... você checou isso na base ou só assumiu e foi feliz?

Pensa em como você vai testar. Como você vai saber se o que construiu tá certo? Testes automatizados bastam? Precisa cutucar na mão? A diferença aparece num screenshot ou num vídeo? Um bug de dark mode não aparece em teste unitário, meu amigo. Aparece num print.

Pensa em como isso vai ser anunciado. Como a gente comunicaria? Você consegue visualizar o anúncio? Como isso se encaixa no quadro maior do roadmap? Dúvida ou preocupação nessa área? Questiona, pergunta, dá um push back. Se você não consegue escrever o anúncio em duas frases, o escopo provavelmente ainda tá bagunçado.

Nosso caso: e se o membro não tiver avatar? E se a busca vier vazia? E se caírem 50 mil membros de uma vez? Anota tudo isso ANTES de codar.

4. Execute

A fase mais curta de descrever e a mais longa de viver. O padrão é um só, e é simples.

Faça o trabalho com precisão, com cuidado, com senso de urgência e com calma. Não faça nada pela metade. E ó, urgência aqui não é pressa afobada não: é não deixar o problema esperando por você, sem sacrificar o cuidado no caminho.

E tem um teste antes de dar merge, o meu favorito:

Eu tenho orgulho disso?
Eu mostraria isso pro John Carmack (o lendário programador do Doom e Quake) e falaria: "foi isso que eu construí, com essas restrições, com esses tradeoffs"?

Se a resposta for não, sinto muito, mas ainda não terminou.

Nosso caso: boto o índice, reescrevo a query zoada, testo local. Caiu de 8s pra 120ms. Tenho orgulho disso? Tenho.

5. Verifique (em produção)

Terminar de codar NÃO é terminar. Terminar é o problema resolvido, rodando, no ar. Anota isso.

Testa na mão. Sim, existem testes automatizados. Mas Daniel, se eu tenho teste automatizado, pra quê testar na mão? Porque teste passa e feature quebra, meu amigo. São coisas diferentes. Em 99% dos casos você consegue confirmar na unha que o que construiu funciona: rodando você mesmo, pedindo pra um agente percorrer os cenários, cutucando os dados antes e depois, tirando screenshots, gravando uma demo. Você tem certeza que resolveu o problema? Roda o fluxo inteiro como se fosse o usuário: cria a conta, dispara a ação, confere o resultado no banco.

Garanta que chegou em produção e funciona lá. Tá deployado? O deploy quebrou? Precisa ativar alguma feature flag? A flag funciona mesmo? Dá pra usar em produção? Você consegue confirmar que tá de fato no ar? "Mergeou" não é "shipou", tá ligado? Abre a produção e usa a feature você mesmo.

Nosso caso: subo pra produção, abro EU MESMO e busco "daniel". Os 8s viraram instantâneo de verdade, com dado real, não só no meu localhost feliz.

6. Comunique

Código que ninguém sabe que existe gera bug que ninguém sabe explicar. Comunicação é parte do trabalho, não é um extra que você faz se sobrar tempo.

Seus colegas precisam saber? É uma feature nova que todo mundo deveria testar? Uma convenção nova no código? Uma coisa traiçoeira que todos precisam conhecer? Avisa. Não subestima a visão periférica do time: saber que a pessoa X mudou ontem o comportamento de como Z funciona pode economizar TRÊS HORAS de debug da pessoa Y amanhã. Mudou como o cache de sessão funciona? Uma mensagenzinha no canal do time hoje vale três horas de debug de outra pessoa amanhã. É de graça, faz.

Os clientes precisam saber? Quem reportou o bug? Quem tá bloqueado esperando isso? Avisa essas pessoas. Responde a thread de quem abriu a issue: "saiu na versão de hoje, pode testar aí".

O mundo precisa saber? Anuncia que saiu. Changelog, post no canal de announcements, tweet, o formato que fizer sentido pro tamanho da mudança.

Nosso caso: mando no canal do time: "a busca de membros tava 8s, agora tá instantânea, quem reclamou pode testar". E respondo a thread de quem abriu a issue.

7. Acompanhe

Ownership não termina no deploy. Termina quando NINGUÉM mais precisa pensar naquilo, você incluso.

Tem follow-ups? Você precisa dar uma olhada nos logs pra ver como tá aquilo que shipou? Uma semana depois, quem sabe? Agenda um lembrete: "conferir a taxa de erro do endpoint novo na sexta". O ciclo só fecha de verdade quando você tem certeza que o problema ficou resolvido e continuou resolvido.

Nosso caso: sexta que vem eu volto no log pra confirmar que a busca continuou rápida mesmo com a base crescendo. Aí sim o ciclo fechou.

É muita coisa. E olha que ainda tem mais.

Sim, é muita coisa, eu sei. E na real ainda tem mais, porque com certeza a gente esqueceu algum item aqui no meio.

Mas mano, é assim que se constrói produto em time pequeno. A gente não tem PM, não tem departamento de QA pra passar a bola. Somos pequenos, mas somos bons, e a gente dá conta dessa porra toda.

E ó, é SEMPRE ok pedir ajuda. É ok fazer pergunta. É ok refazer e conferir três vezes. O que não é ok é assumir, lá no fundo sem falar pra ninguém, que outra pessoa vai fazer as coisas que você não pensou.

Da comunidade para a comunidade.

Bebe água, me segue nas redes sociais e a gente se vê no próximo artigo!

De 6 horas para 40 segundos: como um índice de banco de dados salvou um job crítico de produção

Fernando Andrade — Sat, 06 Jun 2026 20:19:13 +0000

De 6 horas para 40 segundos: como um índice de banco de dados salvou um job crítico de produção

"Às vezes, a solução mais elegante não está no código está em ensinar o banco de dados a encontrar o que ele já tem."

Índice

O cenário: um job noturno que virou um problema diurno
O problema cresceu junto com a tabela
O diagnóstico: o Azure Application Insights apontou o caminho
A solução: um índice bem posicionado
O impacto real: economia de tempo total por dia
Mas afinal: o que é um índice de banco de dados?
Como identificar quando você precisa de um índice
Anatomia do índice que resolveu o problema
Conclusão

O cenário: um job noturno que virou um problema diurno

Todo sistema que lida com monitoramento contínuo eventualmente enfrenta o mesmo desafio: quanto mais dados acumulam, mais lenta fica a análise. Foi exatamente isso que aconteceu em um projeto no qual trabalhei.

A arquitetura era simples na teoria: um job agendado rodava durante a madrugada, disparando N processos paralelos cada um cadastrado individualmente pelo cliente. A lógica de cada processo era fazer uma comparação entre o resultado do dia atual (D+0) com o resultado do dia anterior (D-1), algo como:

"O que mudou desde ontem?"

Para isso, cada processo precisava buscar seu último resultado registrado, usando uma query com ORDER BY last_execution DESC filtrada pelo identificador do processo. Parece trivial. E durante um bom tempo, foi.

O problema cresceu junto com a tabela

Com o tempo, a tabela de resultados foi crescendo naturalmente, afinal, cada processo registra um novo resultado a cada execução. O que antes demorava milissegundos começou a demorar segundos. Depois, dezenas de segundos. Até que um dia percebemos:

A janela de execução do job, que deveria ser de até 4 horas, estava chegando a 12 horas.

Isso significava que um job que deveria terminar antes do horário comercial estava ainda em execução quando os usuários começavam a trabalhar de manhã, gerando inconsistências, bloqueios e reclamações.

A pergunta era: onde estava o gargalo?

O diagnóstico: o Azure Application Insights apontou o caminho

Ao analisar as métricas de performance no Azure Application Insights, ficou evidente que o problema estava concentrado em uma única operação: a query que buscava o último resultado de cada processo.

Internamente, a tabela de resultados tinha crescido o suficiente para que um ORDER BY last_execution DESC sem suporte de índice forçasse o banco a fazer um full scan, ou seja, varrer linha por linha até encontrar o registro mais recente. Multiplique isso por dezenas (ou centenas) de processos rodando em paralelo e você tem uma receita para o caos.

Antes da correção

1 linha(s) recuperada(s) — 1.754s, em 2025-08-11 às 09:19:01

Quase 2 segundos por consulta. Para um único processo, tolerável. Para N processos simultâneos, catastrófico.

A solução: um índice bem posicionado

A correção foi aplicar um índice composto na tabela de resultados, cobrindo exatamente os campos usados na query crítica:

CREATE INDEX idx_job_result_process_date
  ON app_schema.job_results (fk_process_id, date_created DESC)
  INCLUDE (id, final_result, report_id, result_payload);

Esse índice foi criado diretamente no ambiente de produção (pode ser gerado localmente também, dependendo da política da equipe) e o resultado foi imediato.

Depois da correção

1 linha(s) recuperada(s) — 0.003s, em 2025-08-11 às 09:32:00

De 1,754 segundos para 0,003 segundos por consulta. Uma redução de 99,8% no tempo de resposta.

O impacto real: economia de tempo total por dia

Cenário	Tempo acumulado de processamento/dia
❌ Antes do índice	~6 horas e 18 minutos
✅ Depois do índice	~40 segundos

O job voltou a terminar bem antes do horário comercial. Os processos diurnos pararam de ser impactados. E tudo isso sem reescrever uma linha de código de negócio.

Mas afinal: o que é um índice de banco de dados?

Se você chegou até aqui e nunca parou para entender o que um índice faz de verdade, esse é o momento.

A analogia do livro

Imagine que você tem um livro enciclopédico com 10.000 páginas e precisa encontrar tudo que fala sobre "fotossíntese". Você tem duas opções:

Sem índice: Ler página por página do início ao fim. Funciona, mas demora.
Com índice: Ir até o índice remissivo no final do livro, localizar "fotossíntese" em segundos e ir direto às páginas certas. Um índice de banco de dados funciona exatamente assim. Ele é uma estrutura de dados separada (geralmente uma B-Tree) que mantém uma cópia ordenada de uma ou mais colunas, com ponteiros para as linhas reais da tabela.

O que um índice resolve?

Buscas por igualdade: WHERE id = 42 o índice encontra o valor direto, sem varrer a tabela
Buscas por intervalo: WHERE date_created BETWEEN '2025-01-01' AND '2025-12-31'
Ordenação: ORDER BY last_execution DESC se o índice já estiver ordenado nessa direção, o banco nem precisa ordenar
Queries cobertas (covering index): Com a cláusula INCLUDE, o banco pode responder à query inteira só pelo índice, sem nem tocar na tabela original ### O que um índice não é (e quando ele atrapalha)

Índice não é gratuito. Ele tem custos:

Espaço em disco: o índice ocupa armazenamento adicional
Custo de escrita: toda vez que um INSERT, UPDATE ou DELETE acontece, os índices afetados também precisam ser atualizados
Manutenção: índices fragmentados precisam ser reorganizados periodicamente Por isso, criar índices sem critério pode ser tão prejudicial quanto não tê-los. A regra de ouro é:

Crie índices nas colunas que aparecem frequentemente em cláusulas WHERE, JOIN, ORDER BY e GROUP BY de queries lentas, especialmente em tabelas grandes.

Como identificar quando você precisa de um índice

Alguns sinais de alerta:

Queries que demoram mais conforme a tabela cresce (como o nosso caso)
Full table scans aparecendo nos planos de execução (EXPLAIN / Query Execution Plan)
Timeouts em operações que antes eram rápidas
CPU do banco de dados consistentemente alta durante períodos de consulta Ferramentas como o Azure Application Insights, pg_stat_statements (PostgreSQL), slow query log (MySQL) e o Query Store (SQL Server) são aliadas valiosas nesse diagnóstico.

Anatomia do índice que resolveu o problema

Voltando ao índice criado:

CREATE INDEX idx_job_result_process_date
  ON app_schema.job_results (fk_process_id, date_created DESC)
  INCLUDE (id, final_result, report_id, result_payload);

Por que esse design?

Componente	Motivo
`fk_process_id`	Filtro principal da query (cada processo tem seu identificador)
`date_created DESC`	A query precisa do resultado mais recente primeiro
`INCLUDE (...)`	Colunas retornadas pela query, incluí-las evita um segundo acesso à tabela

O resultado é um covering index: o banco responde à query inteira consultando apenas o índice, sem precisar buscar dados na tabela principal. É a forma mais eficiente de otimização de leitura possível.

Conclusão

Performance não é só sobre algoritmos ou arquitetura de microsserviços. Às vezes, o gargalo está numa operação aparentemente simples que o banco de dados precisa executar milhares de vezes por dia, e que ninguém percebe até que o custo acumulado se torne um problema real.

Nesse caso, um único índice bem pensado transformou 6 horas de processamento em 40 segundos. Sem refatoração. Sem mudança de arquitetura. Sem downtime.

Se você ainda não tem o hábito de revisar os planos de execução das suas queries críticas, comece agora. O banco de dados tem muito a te contar, basta saber ouvir.

Sugestões de leitura para se aprofundar: B-Tree indexes, covering indexes, query execution plans, índices compostos e ferramentas de profiling como EXPLAIN ANALYZE.