Code review, payment flow, and TypeScript fundamentals
A day of practicing technical review, mapping product flows, and turning TypeScript study into clearer exercises.
The day was split between review, study, and technical prep. It was not only about writing code. It was mostly about training judgment: understanding a change, separating real risk from preference, and turning loose questions into reusable material.
Review with context
I used training repos to simulate PR reviews with more discipline. The focus was to avoid starting with syntax and first look at the intent of the change: architecture, feature contract, project conventions, rollout risk, and the questions that still need answers.
That kind of practice makes review fairer. Not every point is a bug. Some things are acceptable debt, some are style choices, and some should block because they affect flow, state, or maintenance.
Product and payments
In itop.com.br, the work was about understanding and explaining a ticket sales flow end to end: ticket choice, dynamic form, data validation, coupon, order, payment, and visual state updates.
One reliability point also came up: idempotency in payment operations. The practical question was how to prevent duplicate charges when the user clicks more than once or when the same request arrives again. The answer needs to live in the backend, not only in a disabled frontend button.
TypeScript as practice
In typescript-playground, I organized the study path into levels: fundamentals, intermediate, advanced, and design patterns. The goal was to make the repo more useful for learning, with exercises that show real techniques instead of loose examples.
The day covered emitDeclarationOnly, nullish coalescing, the difference between ?? and ||, and assertNever for proving exhaustive switch statements. I also used real projects as references to identify TypeScript fundamentals applied in SDKs and indexers.
Technical prep
Part of the day went into turning interview material and lessons into notes, flashcards, and shorter answers. The details stay out of the public journal, but the technical work was the same: reduce noise, make evidence clearer, and practice explaining decisions without losing context.
It was a day of calibrating technical reading. The better I can explain what is happening in a diff, the less I depend on improvisation when reviewing, building, or defending a decision.