3 posts tagged with "technical"

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.