About This Tech Blog

This blog is my working notebook for becoming a better systems-minded engineer.

I do not use it as a place to post quick opinions or shallow summaries of trending topics. I use it to slow down, study a subject properly, and explain it in a way that would still make sense a year from now.

Most of the writing here sits somewhere between study notes and engineering essays. The goal is not just to define terms, but to build the kind of intuition that helps when you have to make an actual technical decision.

What I Write About

The core themes of this blog are:

  • Platform engineering: internal platforms, developer experience, golden paths, service ownership, and operational tradeoffs
  • MLOps: model lifecycle management, reproducibility, data quality, feature infrastructure, and serving systems
  • Linux and systems internals: processes, memory, filesystems, networking, synchronization, and containers
  • Compilers and computer architecture: how software maps to lower layers, and why that matters in practice
  • Python fundamentals: not just syntax, but the runtime behavior and mental model behind the language

I am especially interested in the boundary between abstraction and reality: the point where a convenient interface meets the underlying system constraints.

Why This Blog Exists

I started this blog because I wanted one place where my learning could become structured instead of scattered.

A lot of technical content online is either too shallow to be useful or too fragmented to build real understanding. You can collect definitions forever and still not know how the pieces connect. Writing helps me fight that. It forces me to turn vague familiarity into a clearer model.

So this blog serves a few purposes at once:

  • it helps me study carefully
  • it gives me a place to connect ideas across topics
  • it leaves behind explanations that are useful to other engineers who are trying to go deeper

How I Try to Write

I care about a few things when I write here:

  • fundamentals before jargon: if a concept cannot be explained clearly, I probably do not understand it well enough yet
  • practical relevance: I want each post to answer not only "what is this?" but also "when does this matter?"
  • systems thinking: I prefer explanations that connect components, tradeoffs, and failure modes instead of describing topics in isolation
  • steady accumulation: I would rather build a coherent body of writing over time than chase novelty every week

That is also why many posts appear as series. Some topics are not worth compressing into one article.

Who This Is For

This blog will probably be useful if you are:

  • an engineer who wants stronger technical depth, not just tool familiarity
  • someone moving from application development toward infrastructure or platform work
  • a student or self-learner trying to build a more connected mental model of software systems
  • the kind of reader who enjoys long explanations when they are concrete and well organized

It is probably less useful if you only want quick copy-paste answers or framework news.

What You Should Expect

You should expect:

  • long-form series instead of isolated hot takes
  • explanations that try to connect theory to engineering decisions
  • posts that revisit the same topic from multiple angles when needed
  • occasional opinion, but usually in service of a technical argument

You should not expect:

  • daily updates
  • product announcements disguised as writing
  • generic career advice

A Note On Perspective

I am still learning, and this blog reflects that honestly.

Some posts are written from direct engineering experience. Others are written from careful study, synthesis, and reconstruction. When I explain something, I am trying to make the model clearer, not pretend to be finished.

That is part of the point of this site: to make my thinking more rigorous in public.

If You Are New Here

The easiest way to start is to pick a series rather than a random post.

If you care about infrastructure and developer experience, start with the platform engineering series. If you want stronger systems intuition, try Linux, compiler, or computer architecture. If you are interested in the gap between research notebooks and production systems, start with MLOps.

If a post helps you think more clearly, then the blog is doing its job.

Start Here

If you want a concrete entry point instead of browsing blindly, these are good places to begin: