Hey, everyone! 👋🏻

Logged off for the past few days, but thanks to Substack auto-publishing feature, the latest issue of The Engineer Manager newsletter is out!

🧵

This month's issue will talk about the career move from being an individual contributor to the management track, the caveats along the way, and the baseline expectations one should set for themselves when thinking about such a shift.

Link in the tweet below! 👇🏻

So you want to be an Engineering Manager - by Mateus Viegas (substack.com) https://theengineermanager.substack.com/p/so-you-want-to-be-an-engineering-manager

The Engineer Manager Newsletter: Career Move to Management Track

A tip for technical interviews: if it's a greenfield project, the interviewer will probably want to know not only if the code/arch is nice and working, but also the rationale behind the decisions you made along with their trade-offs.

I often see architectures/patterns applied just because, without a backing requirement or proper understanding of their trade-offs.

You might not know an alternative; that's okay. But at least understand the one you choose and ensure you have a clear motivation to go with it.

Code and architecture are both outputs of decisions that should be backed by context and motivations. So, in summary, the most critical questions that need to be answered in such interviews usually start with "why."

Technical Decisions in Interviews

🇧🇷 Bom ponto que o @rponte traz aqui. Existem algumas ferramentas possíveis para resolver isso em arquiteturas distribuídas e orientadas à mensagens. Uma delas é um pattern fundamental nesse tipo de ambiente chamado Transactional Outbox.

https://twitter.com/rponte/status/1505745458878103557

O Transactional Outbox Consiste em:

1) Numa mesma transação na BD salvar um registro na tabela correspondente e a mensagem produzida por essa ação numa segunda tabela chamada Outbox;
2) Ter uma thread em background a fazer polling no Outbox pra publicar a mensagem no broker;

Esse pattern traz a garantia de que mensagens - comumente eventos - são produzidas de maneira consistente à alterações de estados em registros.

Problemas? Esse pattern assume uma garantia de entrega de mensagens chamada de at-least-once. Isso quer dizer que a mensagem produzida, vai ser publicada ao menos uma vez no broker e pode - excepcionalmente - ser publicada mais de uma vez.

Como a mensagem pode ser publicada mais de uma vez? Imagine que o Message Relay leu a mensagem, enviou para o broker mas antes de salvar na Outbox que a mensagem foi publicada, a aplicação falha. No restart da app, o Relay vai ver a mensagem ainda no outbox e republicá-la.

Como prevenir isso? Ao trabalhar com at-least-once, é importante que os seus consumidores de mensagens sem idempotentes: isso é, caso eles recebam a mesma mensagem mais de uma vez, o estado não pode se alterar / o comportamento tem de ser o mesmo.

Por exemplo: uma mensagem de UsuarioCriado é produzida junto com um novo usuário criado, e existe um consumidor pra essa mensagem que dispara um e-mail de boas vindas. Um consumidor idempotente poderia receber a mesma mensagem n vezes, mas não dispararia e-mail mais de uma vez.

Building blocks do outbox:

Na infraestrutura: uma BD com suporte à transações e um message broker.
Nas aplicações produtoras: background thread pra fazer polling, publicar a mensagem e gerenciar o outbox.
Nas aplicações consumidoras: consumidores idempotentes.

Existem várias libs hoje que já facilitam esse trabalho de implementação do outbox nas mais diversas linguagens. No C#, por exemplo, temos o CAP - http://cap.dotnetcore.xyz/ - que é um framework com outbox/inbox já implementado pra produzir/consumir mensagens.

Sistemas distribuídos são lindos - eu acho pelo menos - mas cheios de pequenos detalhes. Não basta adicionar um message broker e achar que todos seus problemas estão resolvidos. Ao mesmo tempo, um mundo incrível de se estudar!

Bom conteúdo sobre Outbox nos links abaixo: 
@crichardson https://microservices.io/patterns/data/transactional-outbox.html

@codeopinion Reliably Save State & Publish Events (Outbox Pattern) - YouTube https://www.youtube.com/watch?v=u8fOnxAxKHk&ab_channel=CodeOpinion

Essa thread virou um "mini-blog" post com o @typefully: https://typefully.com/mateuscviegas/juCOZcd

🇧🇷 Padrões de Sistemas Distribuídos: Outbox Pattern

🇧🇷  Uma thread sobre ser parte da #bolhadev, redes sociais e uma tendência negativa que parece ser a obrigação de aprender e estar sempre atualizado escrita por quem falhou muitas vezes nesse processo.

O twitter se tornou um dos lugares onde gosto de exercitar uma coisa que chamo de "aprendizado passivo", que basicamente é consumir conteúdo que me alcança sem que eu vá de maneira intencional atrás dele - newsletters também cabem aqui, por exemplo.

Esse é um dos jeitos que mais gosto de aprender, porque consigo ir absorvendo sempre pequenas coisas em uma cadência programada - newsletters semanais, por exemplo - enquanto foco meu aprendizado ativo em tempo dedicado para um tema/tópico maior por vez.

Por exemplo, há algum tempo venho exercendo uma função de liderança e gestão e direcionando intencionalmente meu aprendizado "ativo" nisso, enquanto uso o "passivo" para não deixar a parte mais técnica e "mão-na-massa" de lado.

Passei a dividir meu tempo e usar esses métodos depois de sofrer um burnout uns anos atrás por não aprender a controlar minha ansiedade e querer aprender tudo de uma vez, porque parecia que todo mundo ao redor da minha bolha estava sempre anos luz à frente de mim.

Aqui foi onde aprendi a duras penas a primeira grande lição: aprender as coisas leva tempo - de experiência e prática mais que tudo. Por isso penso que, para além de métodos de aprendizado, outra coisa chave é: direcionar sua carreira de forma consciente e intencional.

Por que um direcionamento de carreira consciente e intencional? Porque estar em uma empresa que te exponha à um ambiente de desafios e que, ao mesmo tempo, te proporcione uma liderança que te ajude a focar no que importa para superar esses desafios e aprender vai ser fundamental.

Visão é aonde se quer chegar - daí a importância da intenção na tua carreira. Estratégia é como você vai trilhar o caminho para chegar lá - daí o direcionamento de carreira consciente. Esteja sempre num lugar onde você tenha com o que e também com quem aprender.

Você precisa estar numa carreira internacional para isso? Não. A internacionalidade da empresa vai sim te apresentar muitos desafios, culturais principalmente, mas não necessariamente técnicos. Se conseguir juntar o melhor dos dois mundos, ótimo. Mas não é verdade absoluta.

Trace um plano e respeite teu tempo e não se cobre tanto. A tua única comparação hoje devia ser com como você estava ontem. Não com o amigo da thread ao lado que conseguiu um emprego de uma centena de milhares de reais remoto para fora do país.