ELT > ETL

Pipelines are necessary and transformation is where data becomes useful. The debate is not whether those steps matter, but when they should happen.

Extract. Transform. Load.

That middle step is where the crime happens. You pull data from some source system, immediately start "cleaning" it, drop fields you think nobody needs, coerce types, flatten structures, rename things, dedupe records, and then finally write the polished version somewhere durable.

Congrats, you built a pipeline that can only answer the questions you predicted ahead of time.

The better default is ELT:

Extract. Load. Transform.

Get the data. Store the raw thing. Then transform it after you have preserved reality.

In today's software ecosystem, APIs are the connective tissue of modern applications, especially with the rise of AI. The difference between a good API and a great one often determines whether developers love or loathe integrating with your service. Companies like Stripe and Plaid have set the gold standard as their APIs are not just highly functional, but well documented and easy to use.

But what separates an enterprise-grade API from a hastily constructed endpoint? The little details.

Hot take to start the 2026 calendar year: Microservices were a psyop created to manufacture work and "fix" poor coding decisions. In most cases, a modular monolith makes more sense.

Are microservices a valid concept? Yes! Are there benefits when compared to a traditional monolith at scale? Without a doubt! However, the industry has over-indexed on microservices as a means to create separation of concerns, enable better parallelization / ownership and stop bad coding deciions by fragmenting the code. In this post, I'll be talking about when and how a monolith makes sense, and when it doesn't.

TLDR; it all hinges on scale.

If you took physics in high school (or at least pretended to while copying homework), you probably remember this equation when doing an assignment:

p = m × v

Momentum equals mass times velocity.

In software engineering, I think of mass as the quantity of work, and velocity as how fast it's being done. Momentum isn’t about cranking up one of these. You don’t win by doing everything, and you don’t win by doing one thing really fast if it’s the wrong thing. Momentum, is about from finding balance: doing the most meaningful work at the fastest sustainable pace.

Momentum matters because time is the most valuable resource in engineering (and in life, but that's a deeper discussion for another day). Not compute. Not headcount. Not even IC talent. You can always vertically or horizationally scale servers, hire more people (what a drag), or refactor technical debt. You cannot buy back lost time!

This was the question I started asking myself about 6 months ago. JavaScript works - pretty well in fact. For whatever reason though, it still felt like something was missing.

Three long years ago I joined a 3 person startup as the first technical hire and was tasked with creating the company web application. After evaluating AngularJS, ReactJS and VueJS, I decided to build the proof-of-concept with ReactJS and TypeScript. It didn't go so well.