Forem: Matheus Morett

Você não vai mais entregar código. Você vai entregar times que entregam código.

Matheus Morett — Sun, 22 Feb 2026 21:26:39 +0000

Quando você é dev, você controla a qualidade do que sai das suas mãos. Se algo vai pra produção com seu nome, você garante que tá do jeito que você quer.

Quando você vira Head, isso muda. Você não entrega mais código. Você entrega times que entregam código.

E isso dói.

O desespero de ver "diferente"

No começo, eu olhava as entregas e ficava desesperado. Via um PR e pensava "eu teria feito diferente". Via uma arquitetura e pensava "não era assim que eu faria".

A tentação era meter o dedo em tudo. Microgerenciar cada decisão, cada IF, cada nome de variável.

Cheguei a fazer isso. Não escala. Você vira gargalo, o time para de pensar sozinho, e você não consegue fazer seu trabalho de verdade.

Deixar o time aprender

Teve PR que eu vi débito técnico. Nada crítico, mas débito claro. Deixei. Queria ver se o time ia perceber sozinho.

Percebeu. Corrigiu no sprint seguinte. Sem eu precisar falar nada.

Claro que tem coisa e coisa. Se fosse algo crítico, eu teria intervindo. Mas parte de escalar é saber onde dá pra deixar o time aprender sozinho.

Seu papel é criar o sistema. Não é operar o sistema.

Como a gente fez na Monest 💜

Pra escalar qualidade sem microgerenciar, a gente criou camadas de proteção:

Automação. Lint, tipagem, padrões de código. Se dá pra automatizar, a máquina cobra.

AI como guardiã. Dezenas de guidelines alimentam um agente interno. A mesma AI revisa PRs e O approve dela é obrigatório. Se você programa com AI, ela já faz no padrão Monest.

RFC antes, ADR depois. Feature grande passa por RFC no GitHub, aprovada por Tech Lead. Depois da entrega, ADR documenta as decisões. A AI tem contexto do começo ao fim.

Documentação que respira. Pilares de engenharia no Notion. E um documento que todo mundo conhece: "O que um dev na Monest faz bem?!". Soft-skills, hard-skills, expectativas claras. Dev, Tech Lead, Data Engineer, cada função tem o seu.

Rituais e cultura. Engineering All-Hands, Post-Mortems, Tech Talks internas. Nada disso funciona se o time não compra a ideia. A cultura é a última linha de defesa.

A surpresa

Quando você constrói esse sistema e essa cultura, uma coisa inesperada acontece.

Você para de ver entregas "diferentes". Você começa a ver entregas melhores do que você faria.

Hoje tenho lideranças técnicas e engenheiros entregando muito melhor do que eu faria.

Seu papel é garantir que a barra de qualidade seja alta. O time faz o resto. E te supera.

A lição

Meu papel não é mais entregar código. É construir o sistema que permite 40+ pessoas entregarem no nível que a Monest precisa.

Se eu ainda quisesse controlar cada linha, a gente ainda seria 12.

Esse é o sexto post de uma série sobre lições que aprendi no meu primeiro ano como Head de Tecnologia. Semana que vem tem mais.

Contratando para áreas que você não domina

Matheus Morett — Sun, 08 Feb 2026 14:36:16 +0000

Tenho 10 anos de experiência em tecnologia. Nove deles foram como desenvolvedor ou tech lead. Sempre perto de código.

Quando você vira Head de Tech, isso muda. De repente você precisa gerenciar e guiar áreas que nunca foram suas. E uma das primeiras que me pegou foi segurança da informação.

A Monest 💜 é uma empresa de cobrança com AI. Processamos dados de milhares de devedores todo mês. Ser seguro aqui não é diferencial, é requisito.

Quando entrei, a segurança era terceirizada. Funcionava, mas eu queria alguém interno. Alguém que vivesse o dia a dia da operação, que conhecesse nossos sistemas, que pudesse construir uma cultura de segurança de dentro pra fora.

Eu precisava montar essa área. Contratar a primeira pessoa. Estruturar.

O problema: eu mal sabia a diferença prática entre blue team e red team. Como eu ia julgar se um candidato era bom se eu não entendia o trabalho que ele ia fazer?

Pedindo ajuda

Fui conversar com o Alexandre Neto, CTO renomado e um dos investidores da Monest. Expliquei minha dor: precisava acertar nessa contratação, mas não tinha base técnica pra avaliar.

Ele me deu um panorama do que buscar na posição. E fez algo ainda mais valioso: me conectou com o Ricardo Barbosa, Coordenador de Segurança do Bradesco, com quem ele já tinha trabalhado.

O Ricardo me ensinou o que esperar de um profissional de segurança. E participou da entrevista comigo.

Um mês depois, contratamos o Paulo Roberto. Ele se candidatou pra vaga e foi o selecionado.

Hoje, quase um ano depois, o Paulo estruturou a área de segurança internamente. Junto com a Gabriela Lemes, responsável pela LGPD, passamos por 22 due diligences de segurança de clientes em 2025. Estamos caminhando cada vez mais perto da ISO 27001.

O modelo que funcionou

Esse não foi um caso isolado. Usei o mesmo modelo pra estruturar a área de Dados. Busquei mentores externos que conheciam o que eu não conhecia.

O padrão é simples:

Reconhecer que você não sabe. Parece óbvio, mas o ego atrapalha. A tentação é fingir que dá conta sozinho.

Buscar quem sabe. Não precisa ser um consultor pago. Pode ser um investidor, um contato de rede, alguém que você admira. A maioria das pessoas topa ajudar se você pedir direito.

Trazer pra dentro do processo. Não é só pedir conselho. É pedir pra participar da entrevista, validar o perfil, revisar o escopo da vaga.

A lição

Virar Head de Tech não significa que você precisa dominar tudo. Significa que você precisa garantir que as áreas estejam bem estruturadas, mesmo as que você não entende.

E a melhor forma de fazer isso é se cercar de gente que sabe mais que você.

Pedir ajuda não é fraqueza. É estratégia.

Esse é o quinto post de uma série sobre lições que aprendi no meu primeiro ano como Head de Tecnologia. Semana que vem tem mais.

As melhores pessoas precisam saber que você existe

Matheus Morett — Sun, 01 Feb 2026 22:39:47 +0000

Muita gente acha que líder técnico não tem que ficar postando em rede social. Que isso é coisa de influencer, de quem quer vender curso.

Eu pensava parecido. Até perceber uma coisa:

Se a empresa tem a visão correta, a cultura correta, e você fornece meios pros seus desenvolvedores performarem, o que muda o jogo é a qualidade do seu time.

Ferramentas, processos e metodologias importam. Mas quem faz tudo isso funcionar são as pessoas

E o melhor jeito de ter as melhores pessoas é fazendo com que elas queiram trabalhar com você.

A pergunta é: como essas pessoas vão saber que você existe?

Como eu contratei um Tech Lead pelo Twitter

Durante o ano de 2025, eu postei no meu Twitter sobre desafios técnicos que a gente passava na Monest 💜. Coisas reais. Problemas de escala, decisões de arquitetura, erros que a gente cometeu.

Nada polido. Nada pensado pra viralizar. Só o dia a dia de quem tá construindo produto.

Um desses posts chegou no Samuel. Ele tem 10k+ seguidores no Twitter, é referência técnica na bolha dele. Viu o que a gente tava fazendo e pensou: "esses caras devem estar fazendo uma coisa legal."

Ele veio falar comigo.

Hoje o Samuel é Tech Lead na Monest 💜, liderando nossa frente de canais (Voz e WhatsApp).

Não teve recruiter. Não teve vaga publicada no LinkedIn. Conteúdo real atraiu talento real.

E o Samuel não é o único. Tem outras pessoas que trabalham hoje na Monest 💜, ajudando a gente a revolucionar o mercado de cobrança todo dia, que vieram de relacionamentos feitos na internet.

Por que isso funciona

Os melhores profissionais que eu conheço não ficam procurando vaga. Eles estão trabalhando, aprendendo, e observando.

Observando quem tá resolvendo problemas interessantes. Quem pensa de um jeito que faz sentido pra eles. Quem trata o time de um jeito que eles gostariam de ser tratados.

Quando você posta sobre como resolve problemas, como pensa sobre arquitetura, como lida com erro, você tá mostrando quem você é como líder. Sem filtro de processo seletivo, sem discurso de página de carreiras.

E isso atrai gente que se identifica com o jeito que você trabalha. Gente que já chega alinhada.

Não é sobre viralizar

Não precisa ter milhões de seguidores. Não precisa fazer post todo dia. Não precisa virar influencer.

É sobre ser visível na sua comunidade técnica.

Postar aquele problema que você resolveu. Compartilhar uma decisão que deu certo ou errado. Contar o que você tá aprendendo.

Isso já é suficiente pra que as pessoas certas te encontrem.

O livro que me fez levar isso a sério

Li no "The Engineering Executive's Primer" do Will Larson que como líder, sua rede é seu ativo mais importante. Não só pra trocar ideias com outros líderes, mas pra construir o time que você precisa.

Eu sempre soube disso intuitivamente. Mas ver escrito me fez parar de tratar rede social como opcional.

A lição

Você pode ter a melhor visão, a melhor cultura, o melhor produto. Mas quem constrói tudo isso são as pessoas.

E as melhores pessoas precisam saber que você existe antes de querer trabalhar com você.

Isso não é vaidade. Isso é estratégia.

Esse é o quarto post de uma série sobre lições que aprendi no meu primeiro ano como Head de Tecnologia. Semana que vem tem mais.

O medo de ficar pra trás

Matheus Morett — Sun, 25 Jan 2026 14:10:46 +0000

Você também sente que está ficando pra trás porque todo mês surge uma tecnologia nova?

Em janeiro de 2025, eu tinha acabado de assumir como Head de Tecnologia da Monest 💜. Tinha budget pra dobrar o time, um esboço de planejamento, e uma pergunta na cabeça: onde alocar essa galera nova?

1 mês antes, a Anthropic havia lançado o MCP.

Meu LinkedIn explodiu. "O futuro da integração de AI." Todo mundo falando. Todo mundo implementando. Todo mundo menos a gente.

A Monest é uma empresa de AI. E a gente não tinha MCP.

Bateu a ansiedade. Será que eu deveria parar tudo e colocar o time pra explorar isso?

A pergunta que me acalmou

Me forcei a pensar: o MCP invalida nossa estratégia, ou é algo que dá pra incorporar depois?

Era a segunda opção.

Seis meses depois, implementamos MCP. Mas não como produto principal.

Nossos Biz Devs usam pra consultar insights da operação de cobrança.

Inovamos onde fazia sentido, e o resto da energia foi pra escalar nossa AI de cobrança, onde crescemos 4x a quantidade de conversas por Voz e WhatsApp em 2025.

Se eu tivesse parado tudo em janeiro, nada disso teria acontecido.

Nenhuma tecnologia se consolida do dia pra noite

React foi lançado em 2013. Só em 2015 que Netflix e Airbnb adotaram. Virou mainstream em 2016. Três anos.

Docker foi lançado em 2013. Em 2017, adoção em empresas era 20%. Só em 2021 passou de 90%. Oito anos.

Tecnologia muda as coisas. Mas no ritmo dela, não no ritmo do hype.

Não é pra ignorar o novo

Não tô dizendo pra fingir que tecnologia nova não existe. Tô dizendo pra dosar.

O que funciona pra mim:

Separar sinal de ruído. Se pessoas que eu respeito estão falando de algo, presto atenção. Se só tem post patrocinado e tutorial raso, ignoro.

Estudar antes de implementar. Fiz POCs de MCP internamente antes de decidir onde usar.

Perguntar: isso resolve um problema real nosso agora? MCP não resolvia nosso problema de janeiro. Ia criar trabalho novo sem entregar valor imediato.

A lição

A ansiedade de ficar pra trás é real. Mas a maioria das tecnologias leva anos pra se consolidar.

Você tem tempo.

Inovar não é adotar tudo primeiro. É saber onde colocar energia pra gerar resultado de verdade.

Esse é o terceiro post de uma série sobre lições que aprendi no meu primeiro ano como Head de Tecnologia. Semana que vem tem mais.

O delay entre esforço e recompensa

Matheus Morett — Sun, 18 Jan 2026 15:20:07 +0000

Na vida real, você não faz uma quest e já ganha a recompensa.

Em jogos, você mata o monstro e o loot cai na hora. No TikTok, você scrolla e a dopamina vem em segundos. Mas quando você tenta mudar cultura ou processo numa empresa, o ciclo é outro: meses entre o esforço e o resultado.

O alerta que salvou o dia

Em fevereiro, o time começou a implementar alertas customizados de monitoramento no New Relic. Não foi glamouroso. Foi trabalho chato de configurar thresholds, pensar em cenários de falha, escrever mensagens de alerta que fizessem sentido.

Dois meses depois, em abril, um desses alertas disparou no final da manhã. Nossas recebimento de mensagens tinha ficado fora do ar.

Detectamos na hora. Corrigimos em 15 minutos.

Sem aquele alerta, só descobriríamos horas depois. Milhares de negociações perdidas. Clientes frustrados tentando fazer acordos e não conseguindo.

O trabalho de fevereiro só mostrou valor em abril. E se nada tivesse quebrado, talvez o time nunca percebesse o quanto aquele esforço valeu.

Os números que demoraram pra aparecer

Entre janeiro e fevereiro, implementamos processos de post-mortem, melhoramos code review e introduzimos testes automatizados.

Sabe quando vimos o impacto real? Em agosto.

Tickets de bugs caíram de 20% para 10% do esforço de desenvolvimento. Metade.

Seis meses entre plantar e colher.

O dev que foi entendendo aos poucos

No começo do ano, comecei a insistir com o time sobre a importância de logs bem feitos. Como usar o New Relic direito. Como pensar em observabilidade desde o início.

Tinha um dev que ouvia, fazia o básico, mas não tinha clicado ainda.

Com o tempo, ele foi percebendo que a vida ficava mais fácil quando os logs estavam lá. Que debugar produção virava minutos em vez de horas. Que ele dormia mais tranquilo.

Não teve um momento de virada. Foi aos poucos. Meses até virar natural.

Isso é o oposto de dopamina rápida. É investimento de longo prazo em alguém.

Por que isso é difícil

Esse delay causa ansiedade em todo mundo.

O CEO pergunta "cadê o resultado daquele processo novo?". O time questiona "pra que perder tempo com isso?". E você mesmo fica se perguntando se tá no caminho certo.

A tentação é abandonar o processo antes de validar. Ou mudar tudo porque não viu resultado em duas semanas.

O que funcionou pra mim

Três coisas:

Clareza de propósito. Se você não sabe por que tá fazendo algo, não vai aguentar esperar o resultado. Antes de implementar qualquer mudança, eu preciso conseguir explicar em uma frase por que aquilo importa.

Medir os pequenos ganhos. O resultado final demora, mas sinais aparecem no caminho. Um deploy que não quebrou. Um bug que foi pego antes de ir pra produção. Um dev que fez a pergunta certa. Esses sinais mantêm o time engajado.

Paciência. Não tem atalho. Às vezes você só precisa esperar.

A lição

Mudança de cultura não funciona no ritmo de TikTok. Funciona no ritmo de plantação: você planta, cuida, espera, e torce pra chover na hora certa.

Os frutos chegam. Mas não no tempo que a ansiedade quer.

Esse é o segundo post de uma série sobre lições que aprendi no meu primeiro ano como Head de Tecnologia. Semana que vem tem mais.

Como tirar o mindset de early-stage sem criar burocracia

Matheus Morett — Sun, 11 Jan 2026 05:04:06 +0000

Como tirar o mindset de early-stage sem criar burocracia

Quando entrei na Monest como Head de Tecnologia, o time de tech tinha 12 pessoas. Um ano depois, somos 35.

Esse crescimento muda tudo. Processos que funcionavam com 12 pessoas simplesmente quebram com 35. O problema é que ninguém percebe na hora. O time continua operando do mesmo jeito, até que algo estoura.

E quando você tenta mudar, ouve a frase que todo líder de tech conhece: "mas sempre foi assim".

O desafio real

O difícil não é identificar o que precisa mudar. O difícil é mudar sem transformar a empresa numa máquina burocrática que demora 3 semanas pra fazer um deploy.

Startup vive de velocidade. Se você cria processo demais, mata o que fez a empresa chegar até ali.

O que mudamos

Vou dar quatro exemplos concretos de coisas que implementamos e que geraram atrito inicial:

Testes e2e obrigatórios. Antes não tinha. O time testava na mão, ou não testava. Com 12 pessoas, todo mundo conhecia o sistema inteiro e sabia o que podia quebrar. Com 35, ninguém tem essa visão completa. Testes e2e viraram obrigatórios.

Tipagem real no TypeScript. Nosso "TypeScript" era JavaScript com extensão .ts. Qualquer coisa era any. Isso funcionava quando todo mundo sabia o que cada função esperava. Não funciona mais. Escrevi sobre como eliminamos 4.041 erros de TypeScript em 6 meses nesse artigo.

Observabilidade como regra. Implementamos New Relic em tudo. Antes, quando algo dava problema em produção, era um detetive tentando reproduzir o erro localmente. Agora a gente sabe exatamente o que aconteceu, onde, e por quê. Com 12 pessoas, dava pra perguntar "quem mexeu nisso?". Com 35, você precisa de dados, não de memória.

RFC pra features novas. Antes, alguém tinha uma ideia e começava a codar. Agora, se é algo que muda o rumo do produto, precisa de um documento mínimo explicando o que, por que, e como. Não precisa ser longo. Mas precisa existir.

Nos quatro casos, a reação inicial foi a mesma: "mas antes não precisava".

Como convencer sem impor

A resposta pra "antes não precisava" não pode ser "agora precisa porque eu mandei". Isso não funciona e cria ressentimento.

O que funcionou pra mim foi mostrar dados. Não opinião, não "melhores práticas", não "em empresa séria é assim". Dados.

Depois de um ano com essas mudanças, nossos números mostram:

50% menos tickets de suporte
36% menos post-mortems no Q4 comparado ao Q1, mesmo com o time quase 3x maior e fazendo 80+ deploys por semana

Quando você mostra que a "chatice" gerou resultado concreto, a conversa muda.

Onde não exagerar

Tão importante quanto saber o que implementar é saber onde parar.

Exigimos testes e2e, mas não exigimos 100% de coverage.
RFC pra feature nova, mas não pra bugfix.
Tipagem correta, mas com migração gradual.

A pergunta que me faço antes de criar qualquer processo novo: "isso vai ajudar o time a entregar melhor, ou só vai dar mais trabalho?"

Se a resposta for só mais trabalho, não implemento.

A lição

Crescer dói. O jeito que funcionava antes vai parar de funcionar, e você vai precisar convencer pessoas a mudar algo que elas não veem como problema.

O equilíbrio é: criar processos que protegem a empresa sem criar burocracia que trava a empresa.

Não existe fórmula. É tentativa, erro, e prestar atenção nos resultados.

[Boost]

Matheus Morett — Fri, 05 Dec 2025 21:31:39 +0000

Sam

Dec 5 '25

How I made BeeThreads and what doest it solve

#showdev #ai #node #performance

Comments

3 min read

Como Eliminamos 4.041 Erros de TypeScript em 6 Meses

Matheus Morett — Mon, 10 Nov 2025 20:38:44 +0000

Quando assumi como Head de Tecnologia da Monest em janeiro de 2025, me deparei com um cenário que muitos times de engenharia conhecem bem: TypeScript configurado com strict: false. Na prática, isso significava que nosso "TypeScript" era apenas JavaScript com extensão .ts — sem as verdadeiras garantias de tipo que tornam o TypeScript valioso.

O problema era simples de identificar: código como object.value onde object poderia ser undefined passava tranquilamente no build, só para explodir em runtime. Mas a solução? Essa era outra história.

O Desafio: 4.041 Erros de Uma Vez

Quando finalmente ativamos strict: true para avaliar a situação, fomos recebidos por uma parede vermelha no VSCode: 4.041 erros de TypeScript.

Ninguém consegue resolver 4.041 erros do dia para a noite. E mesmo que conseguisse, o risco de quebrar funcionalidades críticas em produção — especialmente em uma startup de cobrança por IA como a Monest — era inaceitável.

Precisávamos de uma estratégia diferente.

Nossa Abordagem: Migração Gradual e Sustentável

1. Strict em Dev, Permissivo em Prod

A primeira decisão foi aparentemente contraditória, mas fundamental:

✅ strict: true em desenvolvimento — para que os erros aparecessem na nossa cara enquanto editávamos arquivos
⚠️ strict: false em deploy — para que a build funcionasse mesmo com erros pendentes

Isso nos deu visibilidade do problema sem bloquear o time ou comprometer entregas.

2. Uma GitHub Action para Criar Accountability

Criamos uma GitHub Action que contava os erros de TypeScript a cada PR. A regra era simples: cada PR precisava reduzir pelo menos 1 erro.

Não importava se você estava trabalhando em uma nova feature ou em um bugfix — você tinha que resolver ao menos um débito técnico de TypeScript. Sem exceções.

3. A Regra de Ouro: Produção em Primeiro Lugar

Estabelecemos uma regra de ouro para guiar decisões difíceis:

"O sistema funciona em produção. Na dúvida entre alterar o código ou o tipo, altere o tipo."

Essa diretriz foi crucial. Em vez de tentar "corrigir" código que funcionava (e potencialmente introduzir bugs), priorizamos ajustar as definições de tipo para refletir a realidade do código existente. Refatorações podiam vir depois, quando entendêssemos melhor cada parte do sistema.

Nem tudo foi perfeito nessa jornada. Tivemos um deploy que acabou quebrando produção — ironicamente, o erro foi justamente fazer o oposto da nossa regra de ouro: confiamos no tipo (que estava errado) em vez do código (que funcionava). Foi um lembrete valioso de que tipos são ferramentas para nos ajudar a entender o código, não verdades absolutas sobre ele.

Esse incidente reforçou ainda mais a importância da nossa abordagem cautelosa e incremental.

4. Visibilidade e Celebração do Progresso

Incorporamos na nossa reunião de engineering all-hands o ritual de ver quantos erros tínhamos eliminado no mês. Transformamos o que poderia ser uma tarefa chata em um indicador de progresso coletivo.

Ver aquele número caindo mês a mês criou um senso de conquista compartilhada.

5. Atenção Especial para Código Crítico

Para arquivos sensíveis — como nossa lógica de geração de acordos, o coração da nossa plataforma — criamos tickets específicos. Essas partes do código mereciam atenção focada e revisão cuidadosa, não podiam ser tratadas como "apenas mais um erro para resolver".

Os Resultados

Mantivemos uma média de 800 erros removidos por mês.

Em 6 meses, chegamos a zero erros de TypeScript.

Hoje, em novembro de 2025, arquivos vermelhos com erros de TypeScript são coisa do passado na Monest. Mais importante: ganhamos:

✅ Confiança — refatorações são menos arriscadas
✅ Produtividade — o autocomplete realmente funciona
✅ Qualidade — pegamos erros em tempo de desenvolvimento, não em produção
✅ Onboarding — novos engenheiros entendem o código mais rapidamente

Lições Aprendidas

1. Débito técnico não se resolve em um sprint heroico

Tentativas de "resolver tudo de uma vez" geralmente falham. Progresso consistente e incremental vence.

2. Automação cria disciplina

A GitHub Action transformou a resolução de débito técnico de "quando der tempo" para "sempre, um pouco por vez".

3. Visibilidade gera engajamento

Compartilhar o progresso publicamente nas all-hands criou senso de propriedade coletiva.

4. Produção não pode esperar perfeição

A configuração híbrida (strict em dev, permissivo em prod) nos deu o melhor dos dois mundos: visibilidade sem bloqueio.

5. Tipos servem o código, não o contrário

Nosso único incidente em produção nos ensinou: quando os tipos contradizem código que funciona, questione os tipos primeiro.

Why You Shouldn't Use `as` in TypeScript 🚫

Matheus Morett — Sun, 03 Nov 2024 14:36:39 +0000

Introduction

TypeScript, since its inception, has aimed to provide static typing for JavaScript, helping developers write safer and more reliable code. The as operator was introduced to allow type assertions, a powerful feature but one with great potential for misuse. In this article, we'll explore the creation and purpose of as, common mistakes associated with its use, and how alternatives like zod can offer a more robust solution.

The Creation of `as` in TypeScript

The as keyword in TypeScript is used to inform the compiler that a value should be treated as a specific type, regardless of its original inference. It's useful in situations where the developer is certain about the correct type of a variable, but the compiler cannot infer it.

For example:

const value: unknown = getValueFromSomewhere();
const valueAsString = value as string; // I know `value` is a string!

In this case, as tells the compiler that value is a string, even though it was initially inferred as unknown.

Common Mistake: Using `as` with Fetch and JSON.parse

While as is useful, it can easily be misused, especially in scenarios where data comes from external sources, such as APIs.

With Fetch

When using fetch to get data from an API, it's tempting to use as to tell TypeScript what type of data to expect:

async function fetchData() {
    const response = await fetch('https://api.example.com/data');
    const data = await response.json() as MyDataType; // Beware!
    return data;
}

Here, we're telling TypeScript: "Trust me, data is of type MyDataType." The problem is that fetch doesn't guarantee the format of the returned data. This can lead to runtime errors that TypeScript cannot predict or prevent.

With JSON.parse

The same issue arises when using JSON.parse():

const jsonString = '{"name": "John", "age": 30}';
const parsedData = JSON.parse(jsonString) as MyDataType; // Risky!

Although jsonString seems to contain an object of type MyDataType, there are no guarantees. If the JSON structure changes or is incorrect, the code will fail silently, leading to hard-to-track bugs.

The Solution: Using `zod` for Safe Type Validation

To avoid these issues, it's better to validate external data before trusting it. zod is a TypeScript schema validation library that can be used for this purpose.

Example with `fetch` and `zod`

import { z } from 'zod';

const MyDataType = z.object({
    name: z.string(),
    age: z.number(),
});

async function fetchData() {
    const response = await fetch('https://api.example.com/data');
    const json = await response.json();

    const result = MyDataType.safeParse(json);
    if (!result.success) {
        throw new Error('Invalid data');
    }

    return result.data; // Now we are sure that `result.data` is of the correct type!
}

Example with `JSON.parse` and `zod`

const jsonString = '{"name": "John", "age": 30}';
const json = JSON.parse(jsonString);

const result = MyDataType.safeParse(json);
if (!result.success) {
    console.error(result.error);
} else {
    console.log('Valid data:', result.data);
}

When It’s Safe to Use `as`

Although we’ve discussed the dangers of misusing as, there is one specific scenario where I personally find it acceptable to use: Gradual Migration to TypeScript.

Gradual Migration to TypeScript

During the migration of a large JavaScript codebase to TypeScript, it might be necessary to use as temporarily to maintain compatibility while you gradually add more specific and safe types to your code.

function processData(data: any) {
    const typedData = data as MyDataType; // Temporary use
    // Processing logic here
}

This is an acceptable use of as during the transition but should be replaced by more precise types or validations as soon as possible.

Conclusion

While as can be a handy tool, its misuse, especially when dealing with dynamic or external data, can lead to silent and hard-to-debug runtime errors. Instead, adopting validation tools like zod provides a more robust and secure approach, ensuring that data matches the expected types before trusting it in your TypeScript code. Personally, I would only use as in the context of gradual migration to TypeScript, where its temporary nature is understood, and plans are in place to phase it out.

🔍 "Overlooked Use Cases in Your Tasks?"

Matheus Morett — Mon, 04 Sep 2023 22:32:32 +0000

Throughout my 8️⃣ years in software development, I've faced a recurring challenge: poorly specified tasks. 😰

How many times were use cases overlooked by the PO? And what if, during development, I forgot a crucial detail? 🤔 These oversights often only emerged during testing or, even worse, once users began interacting with the application. 😓

This scenario began to shift for the better when I was fortunate enough to work with a PO who employed Gherkin for specifications. 🌟 From that point on, the responsibility to define use cases was shared between the PO and myself. This change not only made it easier to introduce automated testing but also helped me deliver more bug-free software. 🛠️💡

Let's dive into a practical example. 🧐

Imagine you were given this User Story:

As a user, I should be able to redeem a discount coupon at checkout. 🛍️

Translating this User Story to automated tests in Jest:

describe('Coupon Redemption based on User Story', () => {
  it('should allow users to redeem a discount coupon', () => {
    // Mock checkout process
    // Insert coupon code
    expect(finalPrice).toBeDiscounted();
  });
});

However, this test seems quite general and lacks detail.

Now, let's see how Gherkin can refine this: 👇

Scenario: Redeeming a valid coupon
Given the user is finalizing a purchase
When they enter a valid coupon code
Then the appropriate discount should be applied to the total 🟢

Scenario Redeeming an expired coupon
Given the user is finalizing a purchase
When they enter an expired coupon code
Then no discount should be applied
And a message stating the coupon has expired should be displayed. 🔴

Translating the refined Gherkin scenarios to Jest tests:

describe('Coupon Redemption based on Gherkin', () => {
  it('should apply discount for valid coupon', () => {
    // Mock checkout process
    // Input valid coupon code
    expect(finalPrice).toBeDiscounted();
  });

  it('should show error for expired coupon', () => {
    // Mock checkout process
    // Input expired coupon code
    expect(finalPrice).not.toBeDiscounted();
    expect(displayErrorMessage).toBeCalledWith('Coupon expired');
  });
});

The Gherkin specifications not only address the scenario of a valid coupon but also consider the situation of an expired coupon, which could easily be overlooked with a vaguer User Story.

Forem: Matheus Morett

Você não vai mais entregar código. Você vai entregar times que entregam código.

O desespero de ver "diferente"

Deixar o time aprender

Como a gente fez na Monest 💜

A surpresa

A lição

Contratando para áreas que você não domina

Pedindo ajuda

O modelo que funcionou

A lição

As melhores pessoas precisam saber que você existe

Como eu contratei um Tech Lead pelo Twitter

Por que isso funciona

Não é sobre viralizar

O livro que me fez levar isso a sério

A lição

O medo de ficar pra trás

A pergunta que me acalmou

Nenhuma tecnologia se consolida do dia pra noite

Não é pra ignorar o novo

A lição

O delay entre esforço e recompensa

O alerta que salvou o dia

Os números que demoraram pra aparecer

O dev que foi entendendo aos poucos

Por que isso é difícil

O que funcionou pra mim

A lição

Como tirar o mindset de early-stage sem criar burocracia

Como tirar o mindset de early-stage sem criar burocracia

O desafio real

O que mudamos

Como convencer sem impor

Onde não exagerar

A lição

[Boost]

How I made BeeThreads and what doest it solve

Como Eliminamos 4.041 Erros de TypeScript em 6 Meses

O Desafio: 4.041 Erros de Uma Vez

Nossa Abordagem: Migração Gradual e Sustentável

1. Strict em Dev, Permissivo em Prod

2. Uma GitHub Action para Criar Accountability

3. A Regra de Ouro: Produção em Primeiro Lugar

4. Visibilidade e Celebração do Progresso

5. Atenção Especial para Código Crítico

Os Resultados

Lições Aprendidas

1. Débito técnico não se resolve em um sprint heroico

2. Automação cria disciplina

3. Visibilidade gera engajamento

4. Produção não pode esperar perfeição

5. Tipos servem o código, não o contrário

Why You Shouldn't Use `as` in TypeScript 🚫

Introduction

The Creation of as in TypeScript

Common Mistake: Using as with Fetch and JSON.parse

With Fetch

With JSON.parse

The Solution: Using zod for Safe Type Validation

Example with fetch and zod

Example with JSON.parse and zod

When It’s Safe to Use as

Gradual Migration to TypeScript

Conclusion

🔍 "Overlooked Use Cases in Your Tasks?"

The Creation of `as` in TypeScript

Common Mistake: Using `as` with Fetch and JSON.parse

The Solution: Using `zod` for Safe Type Validation

Example with `fetch` and `zod`

Example with `JSON.parse` and `zod`

When It’s Safe to Use `as`