Agir:
Sigo refatorando e reestruturando os hotspots de forma incremental, adicionando testes e/ou métricas, antes e depois.

Decidir:
Priorizo o "TO DO" baseado em esforço e impacto.

Em geral, os lugares com maior acoplamento são os mais sensíveis, começo por definir as responsabilidades de cada elemento.

Orientar:
Desenhar um "AS IS" (como está), um "TO BE" (como deveria ser pra atender o negócio) e o "TO DO", uma lista de iniciativas ou passos pra ir do "AS IS" pro "TO BE".

Também curto muito, tenho usado desde o começo do ano

Talvez tenha sido o viés do autor e do mentor, talvez pela minha leitura fragmentada, mas sinto que vou ter que reler este livro daqui algum tempo e "tomar outro banho em outro rio"

Nas primeiras páginas o autor declara que "resumiu o quanto pôde" e quando recebi a recomendação do Elemar Júnior, ele comentou que seria um livro para ler e reler cada parágrafo, aprendendo coisas novas a cada vez

Do you think there's enough competition in that capital-intensive market?

At least it's consistent 😅

I used a negative BF as a temporary workaround until the system had the chance to rebuilt a new one

I think that, for most inexperienced devs, blurring the distinction is not reducing cognitive load, but increases it with and constant "is it client or server here?" loop. However, the technology making this possible is amazing ✨

Leading me to review and rewrite everything again.

Maybe it's because I didn't developed the proper process yet, but I feel that disabling the autocomplete and "next edit", while using it like "here's the code and this is the problem, how can we solve this?" is more like my thing.

I've been writing some code on a subject I worked deeply some years ago an since last year again. I'm trying Github Copilot with "Claude Sonnet Thinking" on VSCode and one thing annoys me a lot: the "next edit" consistently introduce more bugs and detours from what I'm intending...

Iria adorar ver isso!

Esse parece ser um limite bobo, mas chuto que isso é alguma limitação interna, talvez os hardwares envolvidos tenham essa restrição e isso só subiu à superfície... 🤔

Me faz pensar pq não contornaram isso com uma tabela de lookup

Yes, you're right. My index was "graphql as BFF of APIs" and "SSR being too much", while "RSC is one layer less than BFF, still leveraging server capacity"...

I guess the best move would be global (competing) leader companies in security to "fork" the program and maintain it. Which companies is the question. I would prefer representatives from different countries and markets.

Salvo engano a próxima é Julho, mas as vezes rola em um "Prime Day" que eles têm feito com mais frequência