Seus dispositivos Bluetooth estão contando sua rotina inteira pra qualquer pessoa com um Raspberry Pi.
Um desenvolvedor criou o Bluehood, um scanner passivo de Bluetooth. Sem conectar em nada. Só escutando. Do home office dele, ele conseguiu detectar quando o entregador chegava, se era o mesmo motorista, os horários exatos dos vizinhos saindo e voltando pra casa, e quais dispositivos andavam juntos (celular + smartwatch = mesma pessoa).
Isso sem equipamento especial. Um laptop comum resolve. E a maioria de nós mantém Bluetooth ligado 24/7 sem pensar duas vezes. Pior: a vulnerabilidade WhisperPair (CVE-2025-36911) afeta centenas de milhões de dispositivos de áudio Bluetooth, permitindo sequestro remoto de fones e rastreamento via rede Find Hub do Google.
A gente normaliza "Bluetooth sempre ligado" como algo inofensivo. Não é. Você está transmitindo sua presença, seus padrões, sua rotina. Em broadcast. Pra quem quiser ouvir.
Quando foi a última vez que você desligou o Bluetooth do seu celular?
🔗 https://blog.dmcc.io/journal/2026-bluetooth-privacy-bluehood/
809 pontos no Hacker News. O post sobre GrapheneOS viralizou. E o motivo é simples: as pessoas estão cansadas de escolher entre Google e Apple.
O GrapheneOS é um Android focado em segurança e privacidade, sem Google Services. Roda em Pixels. O autor do post migrou do ecossistema Apple completo (iPhone, iPad, Watch, iCloud, tudo) e conseguiu rodar a maioria dos apps que usava. Incluindo apps bancários, de transporte e streaming.
O que mais me chamou atenção: o sistema permite controle granular de permissões que nem o Android stock oferece. Sensores, rede, clipboard, tudo pode ser restrito por app. E você pode criar perfis de usuário separados no mesmo dispositivo, isolando completamente os dados.
A pergunta real não é "GrapheneOS é prático?" É "quanto da sua vida digital você entrega voluntariamente em troca de conveniência?"
🔗 https://blog.tomaszdunia.pl/grapheneos-eng/
A maioria dos times que adota microsserviços resolve um problema de organização, não de escala.
Já vi isso acontecer várias vezes. O monolito fica difícil de manter. Deploys demoram. Testes quebram. A resposta automática: "vamos quebrar em microsserviços." Só que o problema real era falta de modularização no código, CI/CD mal configurado, e ownership confusa.
Microsserviços não resolvem problemas de processo. Eles multiplicam. Agora você tem os mesmos problemas, mais rede, mais latência, mais complexidade operacional, mais pontos de falha. E precisa de uma plataforma inteira pra gerenciar tudo isso.
Se o seu monolito está difícil de manter, a primeira pergunta deveria ser: "o que impede a gente de modularizar dentro do monolito?" Na maioria dos casos, a resposta é mais barata e mais rápida do que uma migração.
Qual foi o último projeto que você viu migrar pra microsserviços por necessidade real de escala, e não por hype?
🔗 https://www.cosmicpython.com/book/preface.html
Um CTF de prompt injection acabou de sair: HackMyClaw. O objetivo é fazer um assistente de IA vazar suas credenciais por email.
Isso é exatamente o tipo de problema que a maioria dos times de produto ignora quando integra LLMs. A galera foca em "como o modelo responde" e esquece de "o que acontece quando alguém manda um input malicioso por um canal indireto." Email, webhook, formulário, qualquer coisa que o modelo processa pode ser vetor de ataque.
O conceito chave aqui é indirect prompt injection. O atacante não fala direto com o modelo. Ele coloca instruções maliciosas em conteúdo que o modelo vai processar. E os guardrails atuais são frágeis. Muito frágeis.
Se você está colocando LLM em produção com acesso a dados sensíveis, trate prompt injection como você trata SQL injection. Com o mesmo rigor. Ou pague o preço.
PostgreSQL vai lançar uma release fora do ciclo normal em 26 de fevereiro. Isso significa que algo sério o suficiente apareceu pra justificar um patch emergencial.
A maioria dos times trata atualização de banco como "a gente faz quando der." Essa mentalidade funciona até o dia que não funciona. Vulnerabilidades em banco de dados são especialmente perigosas porque o blast radius é total. Não é um endpoint comprometido. São todos os dados.
O PostgreSQL é provavelmente o software mais confiável que a maioria de nós usa. Mas confiável não significa "pode ignorar atualizações." O contrário: quanto mais crítico o software, mais urgente é manter ele atualizado.
Você sabe qual versão do PostgreSQL está rodando em produção agora? Se precisou pensar pra responder, esse é o problema.
Rails 8.1.2 saiu. Query cache desabilitado no console por padrão. String#squish duas vezes mais rápido. Melhorias incrementais, sólidas, sem drama.
Enquanto o ecossistema JavaScript reinventa o framework todo semestre, o Rails continua fazendo o que faz de melhor: melhorar devagar e de forma consistente. Não tem rewrite completo. Não tem breaking change gratuito. Cada release é compatível, estável, e resolve problemas reais que desenvolvedores encontram no dia a dia.
Isso não é sexy. Não gera hype no Twitter. Mas é exatamente o tipo de engenharia que permite que times pequenos construam produtos grandes sem gastar metade do tempo atualizando dependências.
Mesmo não trabalhando com Rails diariamente hoje, continuo sendo um apaixonado pelo framework. A filosofia do Rails moldou como eu penso sobre software: convention over configuration, menos decisões triviais, mais foco no que importa. Poucos frameworks envelhecem tão bem.
A melhor tecnologia nem sempre é a mais nova. Às vezes é a que te deixa focar no produto.
🔗 https://rubyonrails.org/2026/1/22/rails-version-8-1-2-has-been-released
O Go lançou o "go fix" pra modernizar código automaticamente. Em vez de deprecar e quebrar, a linguagem migra seu código pra você.
Isso é o oposto do que a maioria dos ecossistemas faz. Python 2 pra 3 levou uma década. Angular 1 pra 2 matou projetos. React muda padrões a cada dois anos e deixa a comunidade se virar.
O Go tomou uma decisão de design desde o início: compatibilidade importa. E "go fix" é a extensão natural disso. A ferramenta reescreve código usando as novas APIs automaticamente. Sem breaking changes. Sem migração manual.
Escolhas de design de linguagem importam mais do que features. Compatibilidade é uma feature. E é a mais difícil de implementar.
A União Europeia proibiu a destruição de roupas e calçados não vendidos. Isso afeta diretamente o modelo de negócio da fast fashion.
Parece regulação distante da tech. Não é. Toda empresa que opera com modelos de produção sob demanda, supply chain digital, e predição de demanda vai sentir o impacto. A pressão por sustentabilidade está criando oportunidades enormes pra startups de otimização de inventário, marketplace de excedentes, e rastreabilidade de cadeia de suprimentos.
Regulação não mata inovação. Ela redireciona. As empresas que já investiram em tech pra minimizar desperdício estão em vantagem competitiva agora. As que não investiram vão precisar correr.
Onde você vê a maior oportunidade de tech nessa mudança regulatória?
Async/await na GPU. Parece nicho. Mas é sintoma de algo maior: estamos chegando nos limites do que dá pra abstrair em programação paralela.
A Vectorware publicou um post sobre rodar padrões de async/await diretamente na GPU. O conceito é interessante porque tenta trazer modelos de programação familiares (que todo mundo entende) pra hardware que historicamente exige pensamento completamente diferente.
Isso importa porque o gargalo de adoção de computação GPU não é hardware. É programabilidade. Quanto mais fácil for programar GPUs usando abstrações que devs já conhecem, mais rápido a gente vai ver aplicações que hoje só existem em labs de pesquisa.
O futuro da performance não é hardware mais rápido. É software que sabe usar o hardware que já existe.
🔗 https://www.vectorware.com/blog/async-await-on-gpu/
A Sony pode adiar o próximo PlayStation pra 2029. O motivo? Memória pra IA.
Lê de novo. Uma empresa de games está atrasando hardware por causa de demanda de memória para modelos de IA. Isso mostra como IA está redefindo prioridades em indústrias que parecem não ter nada a ver com machine learning.
O impacto prático: consoles vão precisar competir não só em gráficos, mas em capacidade de rodar modelos locais. NPCs com comportamento gerado por IA. Mundos procedurais mais ricos. Interação por voz natural. Tudo isso consome memória que antes ia pra texturas e shaders.
A pergunta que fica: se até console de game precisa de IA on-device, quanto tempo até seu produto também precisar?
🔗 https://www.theverge.com/tech
O caminho de Staff Engineer é o mais mal explicado da indústria de software.
A maioria das empresas promove pra Staff quem é o melhor engenheiro individual do time. Isso é um erro. Staff Engineer não é "senior com mais senioridade." É um papel fundamentalmente diferente. Você deixa de ser avaliado pelo código que escreve e passa a ser avaliado pelo impacto que gera através de outros.
Na prática, isso significa: definir direção técnica, alinhar times em decisões de arquitetura, identificar riscos que ninguém está olhando, e ser a ponte entre engenharia e negócio. Se você é Staff e passa 80% do tempo codando, algo está errado.
O pior cenário: alguém que era um IC excepcional vira um Staff frustrado porque a empresa nunca explicou que o trabalho mudou completamente.
Você já viu alguém ser promovido pra Staff e perder o brilho? Provavelmente era isso.
🔗 https://staffeng.com/guides/what-do-staff-engineers-actually-do/
Event-driven architecture é o novo microsserviços. Todo mundo quer. Poucos entendem o custo.
A promessa é linda: sistemas desacoplados, escaláveis, resilientes. A realidade: eventual consistency que ninguém sabe debugar, eventos duplicados que corrompem estado, e uma complexidade operacional que faz Kubernetes parecer simples.
O problema fundamental: a maioria dos times não tem maturidade de observabilidade pra operar sistemas event-driven. Quando algo dá errado (e vai dar errado), você precisa rastrear um evento através de N serviços, cada um com sua fila, seu retry, seu dead letter queue. Sem tracing distribuído excelente, você está cego.
Antes de adotar event-driven, invista em observabilidade. Tracing, métricas de latência por evento, alertas de consumer lag. Se você não consegue responder "onde esse evento está agora?" em menos de 30 segundos, você não está pronto.
🔗 https://martinfowler.com/articles/201701-event-driven.html
90% dos projetos de LLM em produção falham por causa de avaliação, não por causa do modelo.
O modelo é a parte fácil. Chama a API, monta o prompt, pega a resposta. O difícil é saber se a resposta está boa. E "boa" muda dependendo do contexto, do usuário, e do caso de uso.
Já vi times gastarem meses otimizando prompts baseados em vibes. "Parece melhor agora." Isso não é engenharia. Engenharia exige métricas. Precisão, recall, consistência, latência, custo por request. Se você não tem um pipeline de avaliação automatizado, você está chutando.
O investimento número um pra qualquer time que coloca LLM em produção deveria ser: construir um framework de eval antes de escrever uma linha de prompt. Parece chato. É o que separa projetos que duram de projetos que morrem em 3 meses.
🔗 https://hamel.dev/blog/posts/evals/
Bitcoin continua sendo o ativo mais incompreendido da década. Não porque é complicado. Porque as pessoas insistem em analisá-lo com frameworks errados.
Quem analisa Bitcoin como ação tech acha caro. Quem analisa como moeda acha volátil. Quem analisa como reserva de valor compara com ouro e reclama da volatilidade de curto prazo. Nenhum desses frameworks funciona sozinho.
Bitcoin é uma rede monetária digital, nativa da internet, com política monetária fixa. Não existe outro ativo com essas propriedades. Tentar encaixar numa categoria existente é como avaliar email usando métricas de correio postal.
O exercício mais útil: esqueça o preço por um minuto. Pense no que significa ter um ativo global, sem permissão, sem intermediário, com supply fixo de 21 milhões. Depois pergunte: isso tem valor num mundo onde governos imprimem dinheiro sem limite?
Na dúvida, releia o paper original do Satoshi. Leia "Softwar" do Jason Lowery, publicado pelo MIT. Leia os últimos artigos do Ray Dalio sobre soberania dos países e o ciclo de mudança da ordem mundial. O jogo vai mudar na nossa geração. Quem não estiver preparado será obliterado financeiramente.
🔗 https://bitcoin.org/bitcoin.pdf
A maioria dos code reviews é perda de tempo. E todo mundo sabe, mas ninguém fala.
O review vira um checklist mecânico. "Aprovado", sem comentário substancial. Ou vira nitpicking sobre estilo que um linter resolvia. Ou, pior, vira o gargalo do time porque uma pessoa centraliza todas as aprovações.
Code review deveria servir pra três coisas: encontrar bugs que testes não pegam, compartilhar conhecimento sobre o sistema, e alinhar decisões de design. Se o seu review não faz nenhuma dessas três coisas, ele é teatro.
Duas mudanças que funcionam: primeiro, defina claramente o que é blocker e o que é sugestão. Segundo, revise a intenção antes do código. Entender o "por quê" antes do "como" melhora dramaticamente a qualidade do feedback.
Como funciona o code review no seu time hoje? Agrega valor ou é ritual?
🔗 https://google.github.io/eng-practices/review/reviewer/
O monolito modular é provavelmente a arquitetura mais subutilizada da indústria.
Você pega as vantagens do monolito (deploy simples, latência zero entre módulos, transações ACID) e combina com a organização de microsserviços (boundaries claros, ownership definida, contratos entre módulos). Sem a complexidade de rede. Sem service mesh. Sem orquestração de containers.
Na prática: cada módulo tem sua interface pública, seus testes, e não acessa internals de outros módulos. O banco pode ser compartilhado, mas com schemas separados. Se um dia você precisar extrair um serviço, o boundary já está definido.
Shopify roda assim. Basecamp roda assim. São empresas com escala real. A diferença: elas escolheram complexidade onde importa, e simplicidade em todo o resto.
Antes de adotar microsserviços, pergunte: "a gente já tentou monolito modular?"
A pergunta mais reveladora numa entrevista técnica não é sobre código. É: "me conta sobre um projeto que deu errado e o que você fez."
Algoritmos e system design medem capacidade técnica. Mas o que diferencia engenheiros seniores é como eles lidam com ambiguidade, falha, e pressão. E isso só aparece quando você pede pra pessoa falar sobre situações reais, não hipotéticas.
Já entrevistei centenas de candidatos. Os melhores não são os que nunca erraram. São os que explicam o erro com clareza, descrevem o que aprenderam, e mostram como mudaram sua abordagem. Isso demonstra ownership, capacidade de reflexão, e maturidade profissional.
Se a sua entrevista é 100% técnica, você está contratando habilidade sem caráter. E caráter é o que importa quando o deploy dá errado às 3 da manhã.
Qual pergunta você acha mais reveladora em entrevistas?
🔗 https://jacobian.org/series/work-sample-tests/
Domain-Driven Design é um livro de 500 páginas que 90% das pessoas resumem em "bounded context" e "aggregate."
O resultado: times implementam DDD sem entender o ponto central do livro, que é sobre linguagem. Ubiquitous language. O vocabulário que desenvolvedores e especialistas do domínio compartilham. Sem isso, bounded contexts viram pastas no código e aggregates viram classes com nomes bonitos.
Na prática, DDD funciona quando o time conversa com o negócio usando os mesmos termos. Quando o código reflete a linguagem que o especialista usa. Quando uma mudança no domínio resulta numa mudança no código que faz sentido pra quem não é dev.
Se no seu time o dev fala "entity" e o PO fala "cliente" pra mesma coisa, vocês não estão fazendo DDD. Estão fazendo CRUD com nomes diferentes.
🔗 https://martinfowler.com/bliki/DomainDrivenDesign.html
O debate "remote vs presencial" acabou. O que ficou é mais interessante: remote funciona, mas exige habilidades que a maioria dos gestores não tem.
Gestão remota é fundamentalmente sobre comunicação escrita, confiança, e outcomes. Se você gerencia por presença (a pessoa está na mesa = está trabalhando), remote vai parecer um desastre. Porque você perdeu seu indicador favorito, que já não media nada de útil.
Os times remotos que funcionam bem têm três coisas: documentação como default (não reunião), comunicação assíncrona como padrão (não Slack em tempo real), e métricas de resultado, não de atividade. Isso exige mais do gestor, não menos.
Se o seu time remoto não funciona, o problema provavelmente não é o remote. É a gestão.
🔗 https://basecamp.com/books/remote
O SQLite processa 4 bilhões de dispositivos ativos. Roda em cada iPhone, cada Android, cada browser Chrome e Firefox. É o banco de dados mais deployado da história. E mesmo assim, a maioria dos devs trata como "banco de brinquedo."
Os números desmentem isso. Em benchmarks de read, SQLite faz 2.4 milhões de queries por segundo em hardware commodity. Latência de leitura abaixo de 10 microsegundos (sem round trip de rede). WAL mode suporta readers concorrentes ilimitados com um writer. O arquivo inteiro é uma transação ACID com fsync. Zero configuração, zero daemon, zero porta de rede exposta.
O ecossistema mudou completamente nos últimos dois anos. Litestream replica WAL frames pra S3 em tempo real (RPO de segundos). LiteFS da Fly.io distribui SQLite pra edge com replicação transparente via FUSE. Turso (libSQL) adicionou replicação nativa, vector search, e ALTER TABLE sem rewrite. O Cloudflare D1 roda SQLite distribuído em 300+ data centers.
Rails 8 escolheu SQLite como default de produção para apps de servidor único. DHH não fez isso por acidente. Fez porque pra 90% dos projetos, a complexidade de um PostgreSQL separado não se justifica. Sem connection pool, sem pg_dump agendado, sem tuning de shared_buffers. Um arquivo. Um processo. Funciona.
Não substitui PostgreSQL quando você precisa de replicação lógica, extensões como PostGIS, ou write-heavy com centenas de writers concorrentes. Mas se seu app faz mais reads que writes (a maioria faz), SQLite merece ser sua primeira opção, não a última.
🔗 https://www.sqlite.org/whentouse.html
On-call que funciona é invisível. On-call que não funciona destrói times.
O erro mais comum: tratar on-call como punição. O engenheiro que ficou de plantão dormiu mal, resolveu incidentes sozinho, e na segunda-feira ninguém perguntou o que aconteceu. Isso não é sustainable. É burnout programado.
On-call saudável tem três pilares: runbooks atualizados (ninguém deveria precisar adivinhar o que fazer às 3h), postmortems sem culpa (o sistema falhou, não a pessoa), e compensação justa (se o time é interrompido fora do horário, isso tem valor).
O teste real: se alguém do seu time teme a semana de on-call, o problema não é a pessoa. É o sistema. Alertas demais, documentação de menos, e falta de investimento em reliability.
Como é o on-call no seu time? As pessoas temem ou é tranquilo?
🔗 https://increment.com/on-call/
A IA não vai substituir programadores. Vai substituir programadores que não sabem usar IA.
Essa frase já virou clichê. Mas o que pouca gente discute é o mecanismo específico. O que muda não é "IA escreve código." O que muda é: o custo marginal de produzir código caiu drasticamente. E quando o custo de produção cai, o valor migra pra quem sabe o que produzir.
Na prática: engenheiros que entendem o problema do negócio, sabem fazer perguntas certas, e conseguem avaliar criticamente o output de um LLM vão ser mais produtivos. Engenheiros que só sabem implementar spec vão competir com ferramentas que fazem isso mais rápido.
O investimento de carreira mais inteligente agora não é aprender o framework novo. É desenvolver julgamento. Saber quando o código gerado está errado. Saber quando a arquitetura proposta não escala. Saber dizer "isso não resolve o problema real."
🔗 https://www.oreilly.com/radar/what-we-learned-from-a-year-of-building-with-llms/
O ecossistema de startups brasileiro tem um problema que ninguém quer admitir: excesso de founders resolvendo problemas de San Francisco.
Clona o modelo americano, traduz o pitch, levanta rodada seed. Seis meses depois, descobre que o mercado brasileiro é fundamentalmente diferente. Regulação, sistema bancário, logística, comportamento do consumidor. Nada se encaixa.
As startups brasileiras que deram certo (Nubank, iFood, VTEX) resolveram problemas específicos do Brasil. Banco digital que funciona com CPF. Delivery que opera com motoboy. E-commerce que integra com Correios e boleto. Isso exige conhecimento local profundo.
Se você está fundando uma startup no Brasil, a vantagem competitiva não é copiar. É entender as dores locais melhor que qualquer gringo conseguiria. Esse é o moat real.
🔗 https://braziljournal.com/startups/
Open source tem um problema de sustentabilidade que o modelo de sponsorship não resolve.
Um desenvolvedor mantém um projeto usado por milhares de empresas. Ganha $200/mês no GitHub Sponsors. Se ele para de manter, a cadeia de dependências de metade da internet quebra. Já vimos isso com left-pad, com colors.js, com xz-utils.
O modelo atual é: voluntários mantêm infraestrutura crítica de graça, e empresas bilionárias usam sem contribuir. Sponsorship é caridade, não modelo de negócio. E caridade não escala.
Alternativas existem: dual licensing (como o Redis), open core (como o GitLab), e cloud licensing (como o Elastic). Nenhuma é perfeita. Mas todas são mais sustentáveis que depender da boa vontade de mantenedores solo trabalhando no tempo livre.
Se a sua empresa depende de open source (e depende), quanto vocês contribuíram financeiramente no último ano?
🔗 https://openpath.chadwhitacre.com/
O tech lead mais competente que já trabalhei comigo não era o melhor programador do time. Era o que sabia dizer "não" pro VP de produto sem criar uma guerra política.
Gestão de stakeholders é o que separa tech leads que sobrevivem de tech leads que prosperam. Você pode ser brilhante em system design. Se não souber traduzir tradeoffs técnicos pra linguagem de negócio, suas decisões de arquitetura vão ser revertidas por alguém que não entende o custo real.
Na prática, isso significa três coisas. Primeiro, antecipar impacto antes de ser perguntado. "Essa mudança de escopo adiciona 3 semanas e introduz risco em pagamentos" é infinitamente mais útil que "a gente vê quando chegar lá." Segundo, negociar escopo com dados. Não é "não dá pra fazer." É "podemos entregar X no prazo ou X+Y com mais 2 sprints, qual prioridade?" Terceiro, proteger o time sem criar atrito. O tech lead absorve pressão política pra que o time foque em entregar.
Já vi projetos de 6 meses serem cancelados porque ninguém alinhou expectativas no mês 2. Já vi reescritas de arquitetura serem aprovadas porque o tech lead soube montar o business case. A diferença nunca foi técnica.
Se você é tech lead e passa 100% do tempo em código, está fazendo metade do trabalho. A outra metade é garantir que o trabalho técnico sobreviva ao contato com o resto da organização.
🔗 https://lethain.com/staff-engineer/
Pare de escrever CSS como se fosse 2015. O CSS de 2026 é uma linguagem diferente.
Container queries, :has() selector, cascade layers, subgrid, nesting nativo. Essas features mudaram fundamentalmente o que dá pra fazer sem JavaScript e sem pré-processador. Um post que viralizou no Hacker News essa semana (694 pontos) mostra snippets modernos que substituem centenas de linhas de CSS legado.
O problema: a maioria dos devs aprendeu CSS há anos e não atualizou. Continua usando hacks de float, media queries pra tudo, e !important como solução universal. O resultado é CSS frágil, difícil de manter, e desnecessariamente complexo.
Investir duas horas aprendendo CSS moderno economiza semanas de manutenção. E não, Tailwind não é desculpa pra não entender o que está por baixo.
A narrativa de Bitcoin como "ouro digital" está evoluindo. O novo frame é "rede de liquidação global."
Enquanto o varejo discute preço, instituições estão usando a rede do Bitcoin pra liquidação de transações internacionais. Sem SWIFT. Sem intermediário. Sem esperar 3 dias úteis. A Lightning Network processou mais transações em 2025 do que em todos os anos anteriores combinados.
Isso muda o jogo porque não depende de adoção de varejo. Depende de infraestrutura. E infraestrutura é construída silenciosamente, sem manchete, sem hype. Quando a maioria perceber, já vai estar rodando por baixo de sistemas que elas usam todo dia.
O erro mais comum em análise de Bitcoin é focar no preço e ignorar a rede. Preço é consequência. Rede é causa.
Uma introdução visual ao PyTorch viralizou no Hacker News com 372 pontos. E isso diz muito sobre o estado da educação em IA.
O material é bom porque faz o que a maioria dos cursos de ML não faz: mostra visualmente o que está acontecendo. Tensores, backpropagation, gradient descent. Não como fórmulas num paper, mas como visualizações interativas que um dev sem background em matemática consegue acompanhar.
O gap real de adoção de ML não é talento. É didática. Existem milhares de engenheiros competentes que poderiam trabalhar com ML, mas desistem porque o material disponível assume PhD em estatística. Cada recurso que baixa a barreira de entrada aumenta o pool de pessoas que podem contribuir.
A fundamentação teórica e estatística é importante. Ninguém sério em ML escapa de entender distribuições, gradientes, e funções de perda. Mas essa parte fica muito mais fácil quando você primeiro entende como os modelos funcionam na prática. Ver um tensor mudar de shape, acompanhar o backpropagation visualmente, treinar um modelo pequeno e observar a loss caindo. Isso cria intuição que torna a teoria acessível em vez de abstrata.
Se você quer começar com ML, comece pelo prático. A teoria vai fazer sentido quando você já tiver visto a máquina funcionando.
🔗 https://0byte.io/articles/pytorch_introduction.html
O pior engineering manager é o que tenta ser amigo de todo mundo.
Feedback honesto dói. Dizer "esse código não está no nível que a gente precisa" é desconfortável. Comunicar que alguém não está performando é péssimo. Mas é literalmente o trabalho.
O EM que evita conflito pra manter a paz está priorizando o próprio conforto acima do crescimento do time. A pessoa que não recebe feedback honesto não melhora. O time que carrega underperformers se ressente. E a confiança erode silenciosamente.
Liderança não é popularidade. É responsabilidade. O melhor feedback que já recebi foi o mais direto. Doeu na hora. Mudou minha carreira.
Qual foi o feedback mais difícil que você já deu ou recebeu?
🔗 https://randsinrepose.com/archives/the-update-the-vent-and-the-disaster/
Conheço um engenheiro que era o melhor arquiteto do time. Entendia o sistema inteiro, resolvia os problemas mais difíceis, era referência pra todo mundo. Aí promoveram ele pra engineering manager. Em 6 meses, o time perdeu seu melhor técnico e ganhou um gestor infeliz.
Essa história se repete toda semana em empresas de tecnologia. A causa é simples: o único caminho de crescimento visível é gestão. Quer ganhar mais? Vire líder. Quer título melhor? Gerencie pessoas. O resultado é previsível. ICs excepcionais viram gestores que não querem estar ali.
O caminho de IC até Principal ou Distinguished Engineer exige habilidades diferentes de gestão, não menores. Definir visão técnica de longo prazo. Resolver ambiguidade em problemas que cruzam múltiplos times. Influenciar decisões de arquitetura sem autoridade hierárquica. Mentorar seniors pra virarem staffs. Isso não é "codar sem ter reuniões." É um trabalho de impacto organizacional que acontece através de excelência técnica.
Google leva IC até L11 (Senior Fellow, equivalente a SVP). Stripe tem tracks paralelas com compensação equiparada. Essas empresas entenderam algo fundamental: o valor de quem resolve os problemas mais difíceis não diminui porque a pessoa não quer gerenciar 1:1s.
Se na sua empresa a única forma de crescer é virar gestor, você não tem um plano de carreira. Tem um funil de conversão que desperdiça talento técnico.