Every process a software team runs was built to manage a scarce resource. For twenty years that resource was engineering time. Waterfall managed it with sequencing. Agile managed it with short cycles and constant renegotiation. Both approaches assume the same thing: writing code is the expensive step, so protect it with process.
A company runs smoothly when people can get stuff done without hunting for information. What actually wears people out day to day is not the hard engineering problem. It is not knowing which ticket to file, which team to bug on Slack, or what invisible step stands between them and getting a simple service live.
G-Eval is a reference-free evaluation framework that uses large language models to assess the quality of generated text. This article explains how G-Eval works, including rubric-based prompting, chain-of-thought evaluation, and probability-weighted scoring using token log probabilities. You will also learn its limitations, common implementation patterns, practical best practices, and when not to…
Every AI workflow is a dependency problem. You have steps that produce outputs, other steps that consume those outputs, and a hard constraint: consumers cannot run before their producers finish. Get the order wrong and you read stale data, call a tool with missing context, or trigger an agent before its inputs are ready.
If you have ever taped together a cron job, message queue, a database table for state, and a retry loop - only to watch the whole thing break during a network blip at 2am - you already understand the problem Temporal solves. The fix you built was a workflow engine. Temporal is workflow engine done right.
Most of us build RAG the same way: follow a tutorial that embeds a handful of PDFs, stores the vectors in a local Chroma instance, and chains everything together with LangChain (if that's still a thing). The demo works. The answer looks reasonable. Then you take it to production and it falls apart in quiet, hard-to-diagnose ways.
Role tagging is not cosmetic. It shapes how the model responds, how context is managed across multiple turns, and how application developers constrain and direct model behaviour at a structural level. Understanding this format is the difference between using an LLM and building reliably on top of one.
If you have used ChatGPT, Gemini, or Claude, you have already formed an intuition about what these systems do. You type something in, and text comes back that feels coherent, knowledgeable, and sometimes eerily human. But the machinery underneath is simultaneously simpler and stranger than most people expect.
You have a monolith, and you are proud of it. One repo, one deployment, one database - no Kubernetes, no service mesh. You have watched teams burn months “extracting microservices” and come out slower than when they started. You stayed sensible. You kept the monolith.
There is an implicit contract at the foundation of every database architecture decision you have ever made. You probably never wrote it down. Nobody does. It just… existed.
There is a particular kind of respect reserved in engineering for the algorithm that outlives its era. BM25 is one of them. BM25 was born out of information retrieval research in the 1970s and 1980s, polished over decades, and eventually adopted as the default ranking function in Elasticsearch, Solr, and Lucene.
When you write a SQL query with a JOIN clause, you probably do not think much about what happens next. You just expect the database to return the right rows. But this simple keyword forces your database to make one of the most consequential decisions a query planner makes: which join algorithm should it use?
We all vent at work. That is normal. Tough sprints, messy decisions, frustrating meetings - it happens, and letting off steam is okay and, in fact, healthy.
That is the half-life of knowledge in computer science and software engineering - the time it takes for half of what you know to be replaced by better tools, approaches, or understanding. For an engineering degree earned in 1930, the half-life was roughly 35 years. By 1960, it had dropped to about a decade.
Distributed databases face an interesting challenge: how do you ensure that multiple servers scattered across different machines, data centers, or even continents agree on the order and outcome of database transactions? This is where consensus algorithms come into play.
MySQL replication enables data synchronization across databases, powering read scaling and even some complex distributed architectures. At the core lies the binary log (binlog), which is the authoritative record of all data modifications on a source server.
A Bloom filter is a probabilistic data structure that answers a very specific question - have I seen this thing before? - while using almost no memory.
Partitions sit right in the middle of how Kafka works. They define ordering, parallelism, and how far it can scale. But what actually happens when you need more of them? How does Kafka grow that number, what happens to the data you already have, and which guarantees stay intact after the change?
Recommendation engines, image retrieval platforms, document matching services, and RAG pipelines all rely on finding the nearest neighbors to a given query vector in high-dimensional space. This is where vector similarity search comes in.
At the core of the attention mechanism in LLMs are three matrices: Query, Key, and Value. These matrices are how transformers actually pay attention to different parts of the input. In this write-up, we will go through the construction of these matrices from the ground up.
When you enter a prompt into an LLM, the model converts your text into numbers, processes them, and returns a response one token at a time. In this article, we go through the journey of LLM inference and see how it works.
Concurrent programming is one of the most interesting and challenging aspects of software engineering. When multiple goroutines need to share data, coordinating access becomes critical.
In distributed systems, one of the fundamental challenges is knowing whether a node or service is alive and functioning properly. Unlike monolithic applications, where everything runs in a single process, distributed systems span multiple machines, networks, and data centers. This becomes even glaring when the nodes are geographically separated. This is where heartbeat mechanisms come into play.
Apache Cassandra is a distributed database designed for high availability and horizontal scalability. This write-up explores the complete write path in Cassandra, from the moment a client sends a write request to how data gets replicated across nodes in the cluster.
One of the most fundamental design decisions in Redis replication is that it's push-based rather than pull-based. This means the master (or primary) actively sends data to replicas, rather than replicas polling the master for updates.
We've all dealt with that colleague who dominates the room, dismisses ideas, and acts like the smartest person there. That's arrogance, but it doesn't have to ruin your day...
Content Delivery Networks (CDNs) content replication is far more nuanced than most engineers realize. Let's dive deep into how CDNs actually replicate, distribute, and manage content across their global networks.
You will notice processes, tools, or practices that feel inefficient, outdated, or even wrong. Maybe the team uses Jira instead of Linear, Java instead of Go, MongoDB instead of MySQL (for a use case), or Tabs instead of Spaces. It will be tempting to point it all out immediately. Resist that urge.
Emotional outbursts are natural. I've been there too, and I've seen teams struggle because of it. We all have moments when the pressure gets too much, and emotions spill out.
When Google introduced gRPC in 2015, one of the most significant architectural decisions was building it on top of HTTP/2 rather than the widely adopted HTTP/1.1. This was just about following some trend, but a deliberate choice that fundamentally shapes how gRPC performs and behaves.
We've all been in meetings where no one really knows why they're there or what's about to happen. Always attach an agenda doc or at least a clear description when you schedule a meeting.
I follow a simple flow of questions that helps me stay focused, improve consistently, and make incremental impact at workplace. I'm never running around like a headless chicken. Here are the questions I ask myself, and answer honestly, like really true to its core
Frequent job switches can be great for short-term financial gains. I believed that early in my career as well, but here’s what I’ve learnt over the years.
Yes, higher compensation means you won't have as many options to choose from, but fewer does not mean none. As long as you can demonstrate measurable impact, there will always be opportunities at every compensation level.
Everything we interact with today is a "distributed system". From microservices to cloud-native applications, from databases to message queues. We are constantly building systems that span multiple machines. But there comes a fundamental challenge - how do we ensure that all independent nodes agree on shared state?
Database deadlocks are one of the most challenging concurrency issues encountered in production systems. Understanding why they occur and how databases handle them is important in building robust applications.
While we write code thinking about algorithms and data structures, the CPU is quietly making millions of decisions about what data to keep close and what to evict from its precious cache memory.
While strong consistency might seem like the obvious choice - given it keeps the data perfectly synchronized at all times - the reality is that eventual consistency has become the preferred approach for most large-scale distributed systems. But why so...
DNS is one of the most critical pieces of internet infrastructure, quietly translating human-readable domain names into IP addresses billions of times per day.
If you're aiming for research, go for a top school and squeeze every drop of value. If you want to switch domains or countries but can't break in otherwise (via job switches), a master's can help bridge that gap. But, doing it just because it feels like the “next step” is usually not worth it.
Remember, your job is to solve a problem, not just write code. You are not a code monkey who just hammers the keyboard. You are on a journey to build something that millions use, and for that, you have to
Mentoring someone is one of the most satisfying ways to share what you've learned and see someone grow because of it, but doing it well is what makes the difference.
If you have more than 5 years of experience, always keep a few small projects ready on the back burner. These are ideas you can pick up and run with at any time.
When participating in conversations, meetings, or discussions, we're often very confident in what we're saying and the points we're putting forward. But pause for a moment and ask yourself - do you truly know, or are you assuming, vaguely remembering, or guessing with confidence?
If you are known for owning outcomes and driving results, leadership will trust you with higher-stakes work because the most important projects go to those who get things done.