DEV Community: The Bug Detective

The Case for Jumping to Grokking Modern System Design

The Bug Detective — Fri, 18 Sep 2026 09:42:46 +0000

I'll admit that the word “modern” immediately made me suspicious.

Software has trained me well. Put “modern” in front of something and I expect a refreshed interface, three newer buzzwords, and Kafka appearing somewhere it absolutely did not need to be. So when I looked at Educative's Grokking Modern System Design Interview, my first assumption was that I'd find familiar System Design material with newer case studies attached.

The evidence turned out to be more interesting. The fundamentals haven't suddenly expired. Caches still cache, queues still queue, and databases continue finding creative ways to become the bottleneck. What has changed is the practice model around those fundamentals.

Clue #1 — mock interviews change the learning loop

This is the biggest reason I'm jumping.

A solved System Design problem quietly does an enormous amount of work for me. Someone has already interpreted the prompt, chosen requirements, identified important constraints, selected components, and worked through the trade-offs. I can follow every decision and still discover that I'm considerably less impressive when handed a blank canvas.

A mock interview removes that safety net. Educative's current course includes timed System Design mock interviews with model answers and rubrics, alongside AI mock-interview practice intended to simulate the interview process. Its learning objectives explicitly emphasize framing ambiguous problems, communicating trade-offs, and working through a structured 45-minute answer.

A solved case study tells me what happened. A mock interview gives me the evidence and makes me solve the case.

That's a much better test of whether I understand System Design or merely recognize it.

Clue #2 — text-based System Design is underrated

I'm also increasingly convinced that System Design suits Educative's text-first format.

Video works well for plenty of technical topics, but architecture material involves constant backtracking. I want to compare diagrams, reread the paragraph explaining a consistency decision, inspect an earlier requirement, and jump between the high-level design and the component currently causing trouble. Video becomes less charming when the explanation I need is hiding somewhere around minute 42 and my search engine is a progress bar.

Text isn't universally better, and some people absolutely learn faster from video. For material I'm going to revisit repeatedly during interview preparation, though, searchable, self-paced technical explanations make more sense to me.

Clue #3 — I can inspect some evidence before committing

I also like being able to inspect the material rather than trusting the course description.

Educative currently exposes free System Design material from the curriculum, and its course catalog includes a dedicated collection of free System Design lessons. That gives me a way to inspect the writing, diagrams, depth, assumptions, and teaching approach before deciding how heavily I want to use the full course.

Apparently my preference for evidence before commitment extends beyond suspicious stack traces.

Clue #4 — the component has to explain itself

The curriculum's emphasis on trade-offs is where the “modern” label starts making more sense.

Traditional preparation can make architecture components feel like vocabulary. Need speed? Add a cache. Need asynchronous processing? Add a queue. Need scale? Partition something and hope nobody asks a follow-up question.

Useful preparation asks why. What exactly are we caching, how stale can it become, and what happens on a miss? Why does this workflow need a queue, and what happens when messages are duplicated or consumers fall behind? What property of the workload makes partitioning worth the operational complexity?

Educative's current learning objectives explicitly include sharding, replication, consistency models, CQRS, event-driven design, bottlenecks, reliability, and explaining trade-offs under pressure. That moves the focus from naming components to defending them.

Clue #5 — failure finally gets invited to the interview

The happy path has always had an excellent alibi. Production rarely does.

A design becomes much more interesting when a dependency slows down, a queue develops a backlog, an event arrives twice, a partition becomes hot, or a replica serves stale data. The course's current curriculum explicitly includes failure models, fault tolerance, reliability, SLIs and SLOs, and lessons drawn from system failures rather than treating failure as optional reading after the architecture is finished.

That matters because a System Design interview isn't just asking whether the boxes connect. It is testing whether I understand what assumptions those connections depend on.

Clue #6 — modern doesn't mean newer nouns

The current curriculum also stretches beyond the classic URL-shortener era. It includes systems such as ChatGPT, an LLM-powered customer-support bot, an AI-powered code assistant, and data infrastructure, while Educative's broader AI System Design material covers RAG, semantic retrieval, model serving, batching, and inference constraints.

That expansion makes sense, but I don't want “modern” to mean throwing a vector database into every diagram containing an LLM. Expensive inference, retrieval, asynchronous workflows, and model-serving latency create new constraints, while queues, caching, storage, rate limiting, throughput, and reliability remain very familiar problems.

Modern architecture is not architecture with newer nouns.

The authorship detail matters for a specific reason

Educative identifies Fahim ul Haq as the author of its current Grokking Modern System Design Interview. The course page describes his background building distributed systems at Microsoft and Meta, co-founding Educative, and interviewing hundreds of candidates, and Fahim says that experience shaped the course's focus on ambiguous problems, communication, and defending trade-offs in real time.

Credentials alone aren't evidence that a course works. What interests me is whether that experience shows up in the curriculum, and the emphasis on requirements, trade-offs, failure reasoning, communication, and timed practice is where I can actually see it.

Older or generic prep	Modern Grokking approach
Read completed architectures	Practice producing them
Learn components	Defend why they belong
Focus on the happy path	Reason through failure
Study famous systems	Transfer patterns
Self-evaluate	Add mock-interview pressure
Classic workloads	Include current contexts

The real bug was my practice loop

Nothing here convinced me that the old fundamentals were wrong. It convinced me that my learning loop was too passive.

I could read a design, understand it, nod approvingly at the trade-offs, and move to the next problem. A stronger loop is to study the solution, close it, design the system myself, explain every important decision, deliberately break an assumption, and revise the architecture when the constraints change.

That is the upgrade I care about in Grokking Modern System Design. The current course puts more weight on requirements, structured reasoning, mock interviews, failure analysis, and adapting designs rather than merely recognizing finished ones.

Case closed — I’m jumping to Modern Grokking System Design

For current System Design interview preparation, Educative's Grokking Modern System Design Interview is the version I'd make my primary structured resource. Not because caches, databases, queues, and replication suddenly became different concepts, but because the course makes the practice loop look more like the thing I'm preparing to do.

My investigation started with the assumption that “modern” meant familiar System Design material wearing newer infrastructure vocabulary. What changed my mind was the emphasis on producing designs through mock interviews, explaining trade-offs, reasoning about failures, working through current architecture contexts, and responding to ambiguity rather than memorizing the finished diagram. The fundamentals survived the investigation just fine. The bug was in how I was practicing them, and that's the dependency I'm finally ready to update.

Grokking System Design Overview From the Architecture Crime Scene

The Bug Detective — Wed, 16 Sep 2026 09:36:19 +0000

If you're preparing for a System Design interview and want somewhere to practice beyond this overview, the System Design Handbook is a free resource covering System Design fundamentals, interview frameworks, real-world case studies, common interview questions, and company-specific preparation.

It also goes beyond the usual distributed-systems material with guides on AI, ML, LLM, and Generative AI System Design, so it's useful when you want to investigate a concept in more depth or practice turning what you've learned into an actual interview design.

There is a frustrating stage of System Design prep where every architecture makes perfect sense until you're the person holding the marker.

I could read a finished Twitter or YouTube design and understand why the cache existed, why data was partitioned, and why a queue appeared between two services. Then I'd open a blank canvas and realize that recognizing somebody else's decisions and producing my own were completely different skills.

That became my main suspect.

A useful Grokking System Design overview in 2026 shouldn't be a collection of architectures you learn to redraw. It should teach you how to start with an ambiguous problem, figure out what matters, make defensible decisions, and evolve a simple design as its weaknesses become visible.

What does “grokking” mean?

To “grok” something is to understand it deeply enough that you're no longer relying on memorized rules.

That distinction matters enormously in System Design. Knowing that Redis can be used as a cache is information. Understanding when caching addresses the bottleneck, what should be cached, how stale data affects the product, and whether the added invalidation complexity is justified is much closer to grokking the problem.

The same applies to queues, replicas, partitions, load balancers, and practically every other box we like drawing.

If a component can't explain why it's at the crime scene, I'm not convinced it belongs in the architecture.

The architecture diagram isn't the starting point

My first suspect is any design that somehow contains Kafka before we've established what the system does.

The useful work begins with requirements. A URL shortener dominated by reads creates different pressure from a collaborative editor handling concurrent writes. A video platform has bandwidth and object-storage concerns that a metadata-heavy service might barely notice.

This is also where capacity estimation becomes useful instead of ceremonial arithmetic. Requests per second, storage growth, object sizes, and read/write ratios matter when they change a decision. If your estimate suggests one database node cannot plausibly sustain the projected writes, partitioning has become a real discussion rather than an architecture buzzword.

Educative's current Grokking Modern System Design Interview, for example, explicitly teaches framing open-ended problems as requirements, constraints, and success criteria before moving through design decisions. Its current objectives also cover throughput, latency, bottlenecks, SLIs, SLOs, and failure handling.

That ordering is important. You need a reason before you need a component.

The real skill is connecting requirements to decisions

System Design started clicking for me when I stopped treating technologies as answers.

Suppose reads vastly outnumber writes. Caching or read replicas may become interesting. Suppose large media files dominate storage. Object storage and network bandwidth suddenly deserve more attention. Suppose events must survive traffic spikes without overwhelming downstream processing. Now a queue has an actual job.

The design should form a chain of reasoning: requirement, constraint, decision, consequence.

This is also why “modern” should not mean “contains more fashionable infrastructure.” Kafka doesn't automatically make something scalable. Kubernetes doesn't make it reliable. Microservices aren't inherently more sophisticated than a monolith, and adding an LLM doesn't automatically justify a vector database.

Every extra component creates another thing to deploy, observe, scale, debug, and eventually blame during an incident.

Failure belongs in the design

Finished diagrams have an unfortunate tendency to look like every machine is healthy, every request succeeds, and networks have finally decided to behave themselves.

Production has declined that arrangement.

A useful System Design approach asks what happens when the happy path breaks. Can an operation be retried safely? Could the same event be processed twice? What happens when a dependency slows down rather than disappearing completely? Do we degrade functionality, apply backpressure, fail over, or let queues grow?

A box labeled “database” is evidence, not an explanation. Once availability, replication, consistency, and recovery matter, I want to know what guarantees we're actually depending on.

Educative's current course reflects this emphasis with patterns including sharding, replication, consistency models, CQRS, and event-driven design alongside explicit failure-handling and reliability material.

Modern System Design has expanded

The fundamentals haven't disappeared in 2026, but the systems we're applying them to have expanded.

Traditional questions about databases, caches, queues, APIs, consistency, and scaling still matter. Modern architectures can also involve streaming workloads, event-driven systems, real-time processing, and AI-enabled applications. Educative's current 2026 System Design material has likewise expanded into AI-era infrastructure, including LLM serving and RAG-related architecture.

AI changes some of the economics without repealing distributed-systems fundamentals. Inference can involve expensive, capacity-constrained compute. Batching may improve utilization while increasing latency. Queues can protect limited serving capacity, but an overloaded queue can produce a wonderfully reliable system for answering users far too late.

That's the kind of trade-off I want modern preparation to expose.

Reading solutions isn't enough

This is where I think System Design learning can create misleading confidence.

A finished architecture hides much of the hard work because somebody else already clarified the requirements, identified the workload, discovered the bottlenecks, and chose the trade-offs. You get to evaluate their reasoning instead of generating your own.

The fix is uncomfortable but straightforward: practice from a blank canvas.

Take an unfamiliar problem, establish scope, make your assumptions explicit, estimate only where the numbers could affect the architecture, and draw the simplest design that could plausibly work. Then investigate it. Find the bottleneck, introduce a new constraint, break a dependency, change the traffic pattern, and decide what complexity is now justified.

That's much closer to the actual interview skill. Educative's current course uses its RESHADED framework to structure a 45-minute answer and includes timed mock interviews designed around explaining decisions and trade-offs, rather than merely reproducing diagrams.

There usually isn't a secret architecture the interviewer is waiting for you to discover. They're watching how you reduce uncertainty.

Case closed: what “grokking” System Design should leave you able to do

I don't want System Design preparation to leave me with ten architectures I can reproduce from memory.

I want to be handed a system I've never designed before and know how to begin.

That means clarifying what we're building, identifying the constraints that actually shape the architecture, starting with something simple, predicting where it will fail, and adding complexity only when I can explain what problem that complexity solves.

The diagrams will change. The databases will change. The fashionable infrastructure certainly will.

The reasoning is the part worth grokking.

What part of System Design took the longest to stop feeling like memorization and start feeling intuitive?

I Investigated the “Original” Grokking System Design Course. Here’s the Evidence.

The Bug Detective — Thu, 10 Sep 2026 07:54:50 +0000

Search for the original Grokking System Design course and you’ll eventually encounter a small identity crisis.

There’s Design Gurus. There’s Educative. There’s history connecting the two. And there are enough claims about what counts as the “original” that I started wondering whether I needed a System Design course or a corkboard with red string.

So I investigated.

The history was easier to untangle than I expected. Deciding which course I’d actually use was harder, mostly because I eventually realized that “original” wasn’t particularly useful evidence.

TL;DR

The earlier Grokking the System Design Interview material was created by Arslan Ahmad and the Design Gurus team and distributed through Educative. So if we're investigating historical provenance, Design Gurus has a legitimate claim to that earlier material.

But I wouldn't choose a programming course, framework, database, or interview resource just because it arrived first.

After comparing what I actually want from System Design preparation today, I lean toward Educative's current Grokking Modern System Design Interview. I prefer how Educative builds from fundamentals toward independent interview reasoning and practice.

The distinction matters.

Exhibit A: “Original”

This was the obvious place to start.

The earlier Grokking material came from Arslan Ahmad and the Design Gurus team and was distributed through Educative. Educative now has a separate current course, while Design Gurus has continued developing its own.

That resolves most of the historical question.

It does not resolve the buying question.

“Original” is one of those words that sounds like evidence until you ask what it proves. The original version of a resource can be influential, foundational, and genuinely excellent without automatically being the version I'd choose years later.

Software developers should be especially suspicious of that logic. We spend half our professional lives replacing things that were once perfectly reasonable because the requirements changed.

So I crossed original off my list of deciding factors.

Exhibit B: The curriculum comparison wasn't helping much either

My next instinct was to compare topics.

That didn't solve much.

Both courses live in the same universe of System Design fundamentals: scalability, databases, caching, partitioning, replication, messaging, consistency, estimation, trade-offs, and large-scale design problems. Naturally, there are differences in structure and emphasis, but a checklist quickly becomes less useful than it appears.

This is a recurring problem with technical courses. Two resources can both say they teach caching while producing very different levels of understanding.

The useful question isn't:

Does this course cover caching?

It's closer to:

Could I recognize when caching is appropriate, explain why I'm introducing it, tell you what can go wrong, and decide when not to use it?

That is much harder to determine from a landing page.

The investigation needed another test.

Exhibit C: Remove the answer

This is where the comparison became more interesting.

Completed System Design solutions are dangerously pleasant to study. You read one and everything seems logical. Of course the database belongs there. Obviously that operation should be asynchronous. Naturally we need a cache.

There's just one tiny problem.

Someone else made all those decisions.

Give me the finished architecture for a feed and I may be perfectly capable of explaining it. Give me an empty page and vaguely say “design a feed,” and suddenly I have to decide what matters before I can decide what exists.

That's much closer to the interview problem.

So my test for either course became simple: how quickly does it stop showing me the answer and make me do the thinking?

That changed how I looked at Educative.

Its building-block-first approach initially looks slower than jumping directly into famous architecture problems. But there is a useful reason for the sequencing. You learn what components solve in isolation, encounter them again inside complete systems, and then have to connect those choices back to requirements, bottlenecks, failures, and trade-offs.

I don't think that automatically makes every learner better at System Design. No course architecture has discovered a way to bypass practice. But as a learning path, I found the progression more convincing.

Exhibit D: Change the requirements

Then I tried the test that usually exposes suspicious architecture.

Change one assumption.

Imagine we've designed a file-storage service. Files go into object storage, metadata lives separately, and frequently accessed content can be delivered efficiently through a CDN.

Looks respectable. Nobody call the architecture police.

Then an enterprise requirement arrives: customer data cannot leave its assigned geographic region.

Now things get interesting.

Can the CDN serve the file from another region? Where are metadata replicas allowed to exist? What happens during disaster recovery? Does our replication strategy violate the residency requirement? Which services need regional isolation?

The individual technologies didn't suddenly become bad. The assumptions supporting some of our decisions changed.

This is the kind of preparation I care about because memorized architectures become less useful as soon as an interviewer starts modifying the prompt.

And this is where Educative started pulling ahead for me. Its current course puts considerable emphasis on moving from requirements and constraints into architecture, then examining bottlenecks, failures, trade-offs, and interview communication. The mock-interview component also matters because eventually you need to produce a design without conveniently having the reference solution open in another tab.

That's closer to the uncomfortable part of the actual interview.

The evidence that didn't convince me

Lesson counts didn't.

Number of diagrams didn't.

A proprietary framework acronym didn't automatically convince me either. Frameworks can be useful for keeping an interview organized, but memorizing the framework is not substantially better than memorizing the architecture if you don't understand the reasoning underneath it.

And “modern” isn't evidence by itself. You can attach AI, RAG, agents, or whatever technology is having a good quarter to a curriculum without improving how System Design is taught.

What I cared about was the learning progression.

Does the course give me enough foundation to understand the components? Does it show me how those components interact? Does it force me to connect decisions to constraints? Does it expose failure modes? And eventually, does it make me attempt the reasoning myself?

On those criteria, I preferred Educative.

So, which Grokking course would I actually choose?

This is where the investigation landed somewhere less dramatic than the search results suggested.

If the question is which current course I'd use for my own System Design interview preparation, I'd choose Educative's Grokking Modern System Design Interview.

The reason isn't that one course is “real” and the other is a copy. They're current, distinct learning products, and treating the decision as an authenticity contest doesn't tell me much about how either one teaches.

I simply think Educative currently gives me the stronger path from learning distributed-systems concepts to applying them inside architectures and eventually practicing the messy part: making, explaining, and revising those decisions myself.

That's the evidence I care about.

Turns out the suspicious variable wasn't originalCourse.

It was canIStillDesignThisWhenTheAnswerDisappears.

Case closed.

The Grokking System Design Course Debate Was a False Lead

The Bug Detective — Tue, 08 Sep 2026 13:53:00 +0000

Search for Grokking System Design preparation and you eventually encounter an oddly specific problem: two current courses with very similar names, plenty of history, and developers arguing about which one counts as the “original.”

That clue is easy enough to investigate. The earlier Grokking the System Design Interview material was created by the Design Gurus team and was previously distributed through Educative. Design Gurus deserves the historical credit.

Case solved? Not really.

That tells me where the material came from. It does not tell me which System Design course I would choose if an interview were approaching and my preparation time was limited. For that, I need better evidence.

Exhibit A: the empty whiteboard

Imagine both courses disappear and the interviewer says:

“Design a large-scale notification system.”

No diagram. No preselected database. No conveniently positioned cache waiting for you to nod approvingly.

Design Gurus prepares learners for this better than an “old course” stereotype would suggest. Its current flagship course has 82 lessons, 237 assessments, 11 videos, and 15+ real-world design problems. More importantly, it teaches a repeatable process for requirements, estimation, architecture, technology choices, and trade-offs.

Educative takes a similar foundation but pushes harder on the interview sequence itself. Its current Grokking Modern System Design Interview has 206 lessons, eight mock interviews, and the RESHADED framework, which structures a 45-minute interview around requirements, constraints, capacity, architecture, bottlenecks, reliability, and trade-offs.

Both suspects know how to get from ambiguity toward architecture. Educative simply gives that process more room to become active practice.

Exhibit B: interrogate the architecture

Now suppose the candidate adds Redis.

Why?

What exactly are you caching? How stale can the data become? How does invalidation work? What happens during a miss? If Redis disappears, does the application degrade gracefully or does the database discover a new and exciting definition of load testing?

Kafka deserves the same questioning. Why should this workflow become asynchronous? What ordering guarantees matter? What happens if a consumer performs the work and crashes before acknowledging the message? Can the operation safely happen twice?

This is where component recognition stops being useful and architectural reasoning starts.

Design Gurus is genuinely strong here. Its current course devotes 24 lessons specifically to System Design trade-offs, including SQL vs. NoSQL, strong vs. eventual consistency, REST vs. gRPC, and other recurring decisions. That is one of its clearest strengths.

Educative also teaches those reusable choices through patterns such as sharding, replication, consistency models, CQRS, and event-driven design, but connects them more directly to capacity, failure handling, SLIs/SLOs, and communicating decisions under interview pressure.

So far, the evidence is annoyingly balanced. Good. Rigged investigations are boring.

Exhibit C: the interviewer changes the requirements

This is the harder test.

Say you design a social feed using fan-out on write. For ordinary users, that can be perfectly defensible: do more work when someone posts so follower timelines become cheaper to read.

Then the interviewer adds one account with 200 million followers.

Now every post from that user creates ridiculous write amplification. A candidate who understands the original trade-off can explain why it stopped fitting the workload and consider fan-out on read or a hybrid model for high-follower accounts.

A candidate who memorized “Twitter uses fan-out” has just lost the script.

That distinction is what I want interview preparation to develop: not remembering the correct architecture, but recognizing when an architectural decision no longer matches its constraints.

Educative starts pulling ahead here because its curriculum places more emphasis on capacity reasoning, bottlenecks, reliability, communication, and repeated mock interview scenarios. The eight mocks matter less as a number than as a mechanism: they push the learner toward producing and defending designs instead of only inspecting completed ones.

The evidence board

Evidence	Educative	Design Gurus
Interview framework	45-minute RESHADED process	Strong repeatable master framework
System Design fundamentals	Broad integrated coverage	Strong, focused foundation
Trade-off reasoning	Deeply integrated	Excellent dedicated section
Case studies	Broad building-block-to-system progression	15+ end-to-end problems
Assessments/practice	Quizzes + interactive learning	237 assessments
Mock interview experience	8 embedded mocks	Framework and case-study practice
Emerging architecture	Traditional + GenAI/ML coverage	Traditional + separate AI System Design course
Best fit	Deeper interview execution	Focused, structured preparation

Design Gurus gets real points for focus. Its flagship course is roughly 20 hours and relatively compact, while its separate System Design Fundamentals course offers 172 lessons for developers who want more grounding before tackling interviews.

Educative is the larger learning path. More content is not automatically better — I have seen enough enterprise codebases to reject that theory permanently — but here the additional depth supports interview execution rather than simply increasing the lesson count.

The clue everyone keeps arguing about

This brings us back to “original.”

It was not false evidence. It was just weak evidence for the decision we are trying to make.

Historical originality answers who created the earlier Grokking material. It does not automatically answer which current Grokking the System Design Interview course best fits someone preparing now.

Developers generally understand this everywhere else. We do not select a database because it won the archaeological contest. We evaluate it against the workload, constraints, operational requirements, and trade-offs in front of us.

Interview preparation deserves the same treatment.

The clue I cared about more

A useful curriculum should also evolve without pretending its fundamentals suddenly expired.

Caching, partitioning, replication, messaging, consistency, and reliability still matter. What changes is the environment in which engineers apply them.

That is why Educative’s expansion into GenAI System Design is relevant. Modern architecture increasingly includes model serving, RAG pipelines, vector retrieval, inference latency, evaluation, and compute constraints alongside familiar distributed-systems problems.

Design Gurus is evolving here too, with a current Grokking the AI System Design Interview covering LLM serving, RAG, retrieval, agents, inference economics, monitoring, and AI-specific failures.

So this is not evidence that one platform moved while the other froze. Both moved.

What strengthens Educative’s case is how its broader curriculum connects those evolving architecture domains with structured reasoning and interview practice.

The verdict

Design Gurus remains a serious option. Its current course is actively maintained, its trade-off coverage is excellent, its structure is approachable, and the original creators deserve the historical credit attached to Grokking.

But if someone asked me which course I would choose for modern System Design interview preparation, I would pick Educative.

Its current learning experience more completely connects concepts to architecture, architecture to trade-offs, trade-offs to communication, and communication to actual interview practice. The RESHADED framework, deeper reliability and capacity reasoning, reusable patterns, and embedded mock interviews make it better suited to the part candidates eventually cannot avoid: producing, explaining, and revising a design themselves.

The case started with two courses carrying the Grokking name and a lot of noise about which came first. The more useful evidence appeared later.

A System Design interviewer does not stop once your diagram looks respectable. They keep questioning it until they discover whether you understand why it works — and what you will do when it stops working.

That is the interrogation I want the course to prepare me for.

Case closed.

The Best Grokking System Design Course Is the One That Evolved

The Bug Detective — Tue, 08 Sep 2026 13:17:09 +0000

There are several Grokking the System Design Interview resources now, and one clue keeps getting treated like the decisive one: which course was the original?

Design Gurus deserves the historical credit for the earlier Grokking material, and its current course still identifies itself as the original System Design interview course from the original creators. That matters when discussing history. It matters considerably less when deciding on the best System Design course for an interview in 2026.

Technical resources are not museum exhibits. If interviews evolve, the preparation has to evolve too. So I followed the evidence past the origin story and looked at what both courses actually teach developers now.

The first clue: the interview changed

System Design interviews are no longer particularly impressed by your ability to reproduce a familiar architecture.

A candidate might start with a reasonable design, add Redis for caching, introduce Kafka for asynchronous processing, and choose a database that fits the expected access pattern. Then the interviewer starts asking the questions that actually matter.

What are you caching? How stale can that data become? What happens if Redis disappears? Why is Kafka preferable to a synchronous call here? What delivery guarantee do you need? What changes when traffic grows by 100x?

That is where memorized diagrams start behaving suspiciously.

Modern System Design preparation has to teach candidates how to move from ambiguous requirements into constraints, scale assumptions, architecture, data flow, bottlenecks, failures, and trade-offs while explaining every meaningful choice.

Both current courses recognize this. Design Gurus teaches a repeatable master framework built around requirements clarification, back-of-the-envelope estimation, scalability, reliability, and trade-offs. Its current flagship course lists 82 lessons, 237 assessments, 11 videos, and 15+ real-world design problems.

Educative pushes the interview structure further. Its current Grokking Modern System Design Interview has 206 lessons, eight mock interviews, and a 45-minute RESHADED framework for turning open-ended problems into requirements, constraints, architecture, capacity reasoning, reliability analysis, and defensible trade-offs.

That difference becomes important later in the investigation.

Exhibit A: what the two courses do well

Neither course is simply handing learners a stack of completed diagrams.

Evidence	Educative	Design Gurus
Fundamentals	Broad distributed-systems coverage	Strong, approachable foundations
Reusable patterns	Sharding, replication, CQRS, event-driven design	Master template + recurring trade-offs
Trade-off reasoning	Integrated throughout designs	Excellent dedicated trade-off section
Interview practice	8 embedded mock interviews	Assessments + interview framework
Modern topics	Traditional + separate GenAI material	Traditional + separate AI System Design
Best fit	Deeper interview execution	Compact, structured preparation

Design Gurus has a legitimate advantage in compactness. Its flagship course is around 20 hours, and the platform also offers a separate 172-lesson System Design Fundamentals course for developers who need a slower introduction to load balancing, caching, databases, APIs, messaging, and the other usual suspects.

Its dedicated trade-off material is also genuinely strong. The current curriculum spends substantial time on decisions such as SQL vs. NoSQL, strong vs. eventual consistency, REST vs. gRPC, and other choices that interviewers actually probe.

So no, the evidence does not support “Design Gurus is old, therefore Educative wins.” That would be an impressively lazy investigation.

Consuming System Design is not producing System Design

Completed architecture solutions are dangerously comfortable.

Someone else already clarified the requirements. Someone else selected the database. Someone else decided where the cache belongs and whether eventual consistency is acceptable. Kafka has already been summoned and placed in exactly the right rectangle.

You can understand every decision after seeing the answer and still freeze when someone gives you an empty whiteboard.

That is why reusable mental models matter more than memorizing another “Design Twitter” solution. A candidate who understands fan-out strategies, caching, partitioning, replication, queues, consistency, and failure handling can recombine those ideas when the interviewer asks about something unfamiliar.

Both courses teach transferable reasoning, but Educative gives it more room to develop. Its curriculum moves from distributed-system fundamentals into reusable patterns, capacity estimation, reliability, complete designs, and then mock interview scenarios.

The best preparation gradually removes the scaffolding. This is where Educative starts looking stronger.

The strongest evidence is interview execution

There is a difference between learning about System Design and performing it while another engineer evaluates your reasoning.

Educative explicitly optimizes for that second problem.

Its RESHADED framework gives candidates a 45-minute structure, while the current curriculum includes throughput and latency calculations, bottleneck analysis, SLIs and SLOs, failure handling, fast diagramming, checkpoints, and communication under pressure. The eight mock interviews then require learners to move closer to generating and defending designs rather than merely recognizing good ones.

Design Gurus absolutely teaches communication and justification too, particularly through its master framework and deep trade-off coverage. But Educative currently puts more of the interview itself inside the learning experience.

That matters because architectural vocabulary is cheap evidence.

Knowing Redis exists tells me very little. Explaining why this workload deserves caching, how invalidation behaves, what a miss costs, and whether the system survives without the cache tells me considerably more.

The same interrogation works for databases, queues, replicas, and partition keys. A candidate who cannot connect a requirement to a design decision may know the components perfectly and still struggle in the interview.

Then System Design evolved again

Staying current does not mean replacing fundamentals every twelve months. Caching, partitioning, replication, consistency, availability, and messaging remain durable ideas.

What changes is where those ideas get applied.

Educative’s Grokking the Generative AI System Design is a useful piece of evidence here. The course covers GenAI architectures involving transformers, embeddings, RAG, inference optimization, parallelism, evaluation, capacity calculations, and systems spanning text, image, speech, and video.

Those systems introduce concerns around vector retrieval, model serving, inference latency, compute constraints, data freshness, and evaluation that were not central to traditional System Design preparation.

Design Gurus is evolving here too. Its current Grokking the AI System Design Interview covers LLM serving, RAG, retrieval, inference economics, AI agents, monitoring, and AI-specific failure modes.

That distinction matters because the case is not “one platform evolved and the other did nothing.” Both are actively updating.

The stronger clue is that Educative has built a broader progression from traditional System Design into dedicated GenAI System Design while continuing to emphasize structured interview reasoning and mock practice.

The verdict

Design Gurus deserves its historical credit, and its current material remains a strong option, especially for developers who want a tighter learning path, approachable fundamentals, and excellent dedicated trade-off coverage.

But if I were recommending one resource for **System Design interview preparation in 2026, the evidence points toward Educative.**

Its advantage comes from how the current curriculum connects durable fundamentals with reusable patterns, capacity and reliability reasoning, communication, a structured 45-minute interview methodology, and embedded mock interviews. Its continued expansion into areas such as GenAI System Design also suggests that the curriculum is being treated as something that needs to evolve alongside the systems engineers are increasingly asked to design.

The investigation started with the question of who was original. That turned out to be useful historical evidence, but weak evidence for choosing what to study.

When the actual interview starts, nobody is going to ask who published the first Grokking course. They are going to hand you an ambiguous system, change a requirement when your architecture finally looks comfortable, question one of your trade-offs, and see whether your reasoning survives.

That is the test the course should prepare you for.

Case closed.

I Investigated the “Original” Grokking System Design Debate

The Bug Detective — Tue, 08 Sep 2026 10:17:42 +0000

I Investigated the “Original” Grokking System Design Debate. Wrong Clue.

There are two Grokking the System Design Interview courses in my case file: Educative’s current course and Design Gurus’ course from the original creators.

Naturally, one clue gets a suspicious amount of attention: which one is the original?

Design Gurus has the stronger claim there. Its current course identifies Arslan Ahmad and the Design Gurus team as the original creators and says earlier material was distributed through Educative. (designgurus.io) That history deserves credit, but it turns out to be weak evidence for deciding what to study now.

Software engineering changes. Interviews change. Infrastructure changes. We don’t keep a questionable production architecture because it has historical significance, and I’m not sure why interview prep should receive special treatment.

Exhibit A: what are they actually teaching?

The first useful clue is that both courses have evolved.

Design Gurus’ current course has 82 lessons, 237 assessments, 11 videos, roughly 20 hours of material, and 15+ case studies. More importantly, it teaches a repeatable framework covering requirements, estimation, trade-offs, scalability, caching, partitioning, APIs, and technology choices. (designgurus.io)

Educative’s Grokking Modern System Design Interview is broader, with 206 lessons, eight mock interviews, and roughly 26 hours of material. Its RESHADED framework explicitly trains candidates to turn vague prompts into requirements and constraints before working through capacity, architecture, bottlenecks, reliability, and trade-offs. (educative)

Here’s the evidence board:

What I investigated	Educative	Design Gurus
Fundamentals	Broad distributed-systems coverage	Strong, approachable foundation
Problem-solving method	RESHADED + reusable building blocks	Repeatable master template
Trade-offs	Integrated throughout the curriculum	Excellent dedicated trade-off section
Interview practice	8 embedded mock interviews	Assessments + interview framework
Beginner experience	Comprehensive but larger	More compact and approachable
Emerging topics	Separate GenAI System Design track	Separate AI System Design track

So Design Gurus is not some abandoned artifact from the early Grokking days. Its flagship course was listed as updated within the past week when I checked, and the current material explicitly teaches communication and trade-off reasoning. (designgurus.io)

The case gets interesting when we ask what happens after you close the course.

The memorized diagram is my prime suspect

Reading a completed System Design solution can create a dangerous amount of confidence.

Study Twitter and everything looks reasonable. Of course we need caching. Naturally the data gets partitioned. Eventually Kafka appears because, after enough arrows accumulate, Kafka tends to materialize on its own.

Then the interviewer gives you a system you haven’t memorized.

This is why both courses are right to emphasize reusable reasoning. Design Gurus dedicates 24 lessons to System Design trade-offs and teaches a master template for approaching new problems. (designgurus.io) Educative builds its curriculum around reusable concepts including sharding, replication, consistency models, CQRS, and event-driven design before applying them to complete systems. (educative)

For a beginner, I actually like Design Gurus’ tighter approach. It gives you a clear route into the subject without making System Design feel like you accidentally enrolled in a distributed-systems degree.

For someone who already understands the basics, Educative gives those mental models more room to develop.

The interview evidence points toward Educative

This is where Educative starts pulling ahead for me.

Knowing System Design and performing System Design in an interview are related but different skills. You have to clarify an ambiguous prompt, estimate meaningful scale, construct an architecture, identify its weaknesses, and explain your decisions while another engineer keeps modifying the evidence.

Educative explicitly structures its course around that experience. RESHADED provides a 45-minute answer framework, while the curriculum includes capacity and latency calculations, SLI/SLO reasoning, failure handling, fast diagramming, trade-off narratives, and communication under pressure. Its eight mock interviews then move learners closer to producing a design rather than simply recognizing one. (educative)

Design Gurus covers much of the same intellectual territory. Its course teaches candidates to clarify requirements, make estimates, choose technologies, defend trade-offs, and communicate their decisions. (designgurus.io)

The difference is emphasis. Educative currently puts more of the interview itself inside the learning experience, and that matters when the objective is not merely understanding architecture but explaining one under pressure.

Redis is innocent. Your reasoning might not be.

Suppose you add Redis to your design. Fine.

Why is this data worth caching? How does invalidation work? What happens during a miss? How stale can the data become? What failure mode did you introduce in exchange for lower latency?

The same interrogation works for Kafka, replicas, partitions, queues, and databases. Interviewers are not checking whether you have collected enough infrastructure nouns to complete the diagram. They want to know whether your choices form a coherent system.

Both courses recognize this. Design Gurus deserves particular credit for its dedicated trade-off material, including decisions such as SQL vs. NoSQL, strong vs. eventual consistency, and REST vs. gRPC. (designgurus.io)

Educative’s advantage is connecting that reasoning directly to interview performance through explicit communication objectives and mock practice. For experienced developers especially, another definition of a load balancer is unlikely to change their career. Learning to defend one reasonable architecture against another might.

AI makes the “original” clue even weaker

There is another useful test: what happens when System Design itself changes?

Educative now offers Grokking the Generative AI System Design, covering transformers, embeddings, RAG, parallelism, inference optimization, evaluation, and capacity calculations across text, image, speech, and video systems. It uses a six-step SCALED framework and includes four mock interviews. (educative.io)

Design Gurus is moving here too, and that matters for a fair comparison. Its current Grokking the AI System Design Interview has 70 lessons covering traditional ML systems, LLM serving, inference economics, RAG, retrieval, agents, monitoring, and AI-specific failure modes. (designgurus.io)

So the evidence does not support “Educative evolved while Design Gurus stood still.”

What it does support is something more useful: System Design education has to keep expanding. Model serving, retrieval pipelines, vector search, inference costs, evaluation, and GPU constraints are becoming part of the architecture conversation. Both platforms recognize that, while Educative’s broader progression from traditional System Design into dedicated GenAI material and mock-interview practice strengthens its overall learning ecosystem.

The verdict

Design Gurus remains a strong option, particularly for beginners who want a tighter curriculum, clear explanations, a repeatable framework, and excellent dedicated trade-off coverage. The original creators are also actively maintaining their material, so dismissing it as “the old course” would be bad detective work.

But if I had to recommend one resource for System Design interview preparation today, I’d choose Educative's.

The deciding evidence is not the lesson count or ownership of the original Grokking name. It is Educative’s combination of reusable architectural building blocks, deeper reliability and capacity reasoning, an explicit 45-minute interview framework, communication practice, and embedded mock interviews. (educative)

That gives beginners structure while giving experienced developers somewhere to go after they already know what caches, queues, replicas, and load balancers do.

So yes, I investigated the “original Grokking System Design” clue. Design Gurus deserves the historical credit, and its current course deserves more than being treated as a historical footnote.

It just wasn’t the evidence that decided the case. When an interviewer hands you an unfamiliar problem and changes the constraints halfway through, your course’s provenance cannot defend your architecture for you. The mental models it gave you might.

Case closed.

I Tried 12 Excel Courses on Udemy. Here Are My Top 7 Picks

The Bug Detective — Thu, 27 Aug 2026 09:54:03 +0000

After the first few Udemy Excel courses, the landing pages started looking suspiciously familiar.

Nearly everything promised some combination of “beginner to advanced,” formulas, dashboards, productivity, and becoming an Excel expert. The problem was that those labels told me almost nothing about which course I'd actually want when I had a particular spreadsheet problem to solve.

So I tested 12 courses with a different question in mind: what is this course unusually good at?

That matters even more in 2026. AI can tell me the syntax for XLOOKUP in seconds. I'm more interested in courses that teach me how formulas, data preparation, models, dashboards, and automation fit into repeatable workflows.

If only there was an AI course generator that could come in handy

Seven courses survived the investigation, each for a different job.

1. Microsoft Excel - Excel from Beginner to Advanced 2026 — the all-rounder

Kyle Pew's Microsoft Excel - Excel from Beginner to Advanced 2026 is the one I'd choose if somebody wanted one broad starting point.

The current course moves from Excel fundamentals through formulas and functions, PivotTables, PowerPivot, dashboards, macros, and VBA. It also provides exercise files and quizzes, so it isn't purely a watch-the-instructor-click experience.

Its strength is progression. You can start without much Excel knowledge and continue well beyond formatting cells and adding columns.

The same breadth is also the limitation. If you already know Excel and specifically need Power Query or advanced formulas, I'd skip the familiar material and choose one of the specialists below.

2. Microsoft Excel: Advanced Excel Formulas & Functions — when formulas are the problem

Chris Dutton and Maven Analytics get much more specific with Microsoft Excel: Advanced Excel Formulas & Functions.

The current course concentrates on building formulas for analysis and business intelligence, with project files, quizzes, and homework exercises rather than treating functions as isolated syntax to memorize.

That's the distinction I liked. Good formula training should teach you how to compose a solution, not merely where to put the comma in somebody else's formula.

I wouldn't start here if SUM still feels exotic. This is the course I'd open after the basics, when formulas themselves have become the prime suspect.

3. Microsoft Excel: Learn Modern Excel for Data Analysis — for analyst thinking

For data analysis, I'd pick Microsoft Excel: Learn Modern Excel for Data Analysis from Maven Analytics and Enrique Ruiz.

The 2026 course teaches Excel through an analysis lens: managing and exploring data, formulas, visualization, and PivotTables, with hands-on projects built into the learning experience.

That makes it different from simply becoming “good at Excel.” You're learning to use Excel as an analytical tool.

If your goal is financial modeling or deep automation, another course goes further. For someone moving toward analyst work, however, this has the more useful center of gravity.

4. Excel Interactive Dashboards and Data Analysis — when the output has to communicate

Ian Littlejohn's Excel Interactive Dashboards and Data Analysis made my list because dashboarding deserves more than a chapter tucked into a giant Excel course.

The current version walks through building an interactive dashboard from raw data using PivotTables, PivotCharts, and slicers. It also uses activity briefs before walkthroughs, which I prefer to simply copying whatever appears on screen.

More importantly, it deals with questions such as how source data should be structured and how to present comparisons, trends, rankings, and variance.

If you mainly need formulas, it's too specialized. If your spreadsheets eventually become reports other humans need to understand, that's precisely the point.

5. Advanced Excel: Power Query, Power Pivot and DAX — when the data pipeline becomes the job

One thing testing these courses reminded me of is that “advanced Excel” increasingly means better data flow, not increasingly terrifying formulas.

Advanced Excel: Power Query, Power Pivot and DAX by Start-Tech Academy, Abhishek Bansal, and Pukhraj Parikh focuses on importing and transforming data with Power Query, creating relationships with Power Pivot, and using DAX for calculations and analysis. The current course includes sources such as CSV, SQL, folders, and XML.

I'd take this when repeated cleaning, combining, and reshaping of data has become the real bottleneck.

It isn't where I'd send a complete Excel beginner. You get more from it once normal tables, formulas, and PivotTables already feel familiar.

6. Beginner to Pro in Excel: Financial Modeling and Valuation — for finance-shaped spreadsheets

Beginner to Pro in Excel: Financial Modeling and Valuation from 365 Careers solves a much more specific problem: using Excel to model businesses and financial decisions.

Its current curriculum includes building P&L statements, financial models, valuation models, multiple scenarios, charts, functions, and PivotTables.

That's why it survived. A finance professional doesn't just need “advanced Excel”; they need Excel applied to the structure of financial work.

If you don't care about modeling companies, there are better general courses. For finance-heavy work, the context is the feature.

7. Unlock Excel VBA and Excel Macros — when repetition gets suspicious

Leila Gharani's Unlock Excel VBA and Excel Macros is my automation pick.

The course goes from VBA fundamentals and the Visual Basic Editor into loops, variables, arrays, error handling, workbook events, UserForms, and automation across Excel and other Office applications. It also includes real-world automation projects.

This is where my developer instincts kick in. If I'm manually performing the same spreadsheet ritual every Tuesday afternoon, automation immediately enters the case file.

You don't need VBA for every Excel problem, though. Learn the workflow first; automate it when repetition actually becomes expensive.

The seven-course cheat sheet

Course	Best for	Main trade-off
Kyle Pew: Beginner to Advanced	Broad Excel progression	Too broad for specialists
Advanced Formulas & Functions	Formula depth	Assumes some foundations
Modern Excel for Data Analysis	Analytical workflows	Less automation-focused
Interactive Dashboards	Reporting and dashboards	Narrower scope
Power Query, Power Pivot & DAX	Data preparation and modeling	Not beginner-first
Financial Modeling & Valuation	Finance and business models	Finance-specific
Unlock Excel VBA and Macros	Automation	Unnecessary for many users

Case closed: which one would I actually take?

In 2026, I wouldn't choose an Excel course based on who promises to make me an “expert.” AI has made isolated how-to questions easier than ever. The valuable part of a course is showing how the pieces fit together and then making you practice the workflow.

I'd choose based on the problem: foundations, formulas, analysis, dashboards, data transformation, financial modeling, or automation.

Pick the spreadsheet problem you actually want to solve, then choose the course built around that problem.

Which Excel skill took you the longest to stop Googling every single time?

I've Read 20 Coding Books. Here Are My Top 5 Recommendations After 21 Years of Writing Code

The Bug Detective — Thu, 27 Aug 2026 09:41:02 +0000

Twenty-one years of writing code has changed what I want from a programming book.

Earlier in my career, I was impressed by books that taught me something new immediately: a language feature, a clever technique, a framework I hadn't used yet. These days, I'm much more interested in ideas that still matter after the framework has disappeared and the clever abstraction has become somebody else's maintenance problem.

I've read roughly 20 coding books deeply enough to keep, revisit, argue with, or pull off the shelf when a familiar problem returns. Some aged better than others.

Looking back, these five survived the investigation because they changed habits rather than just adding information.

The books that survived the investigation

I'm using “read” the way developers actually read technical books. Some I've worked through carefully. Others I've revisited repeatedly, jumped around in, or returned to years later when experience made an old chapter suddenly make more sense.

After 21 years, that's my test: not whether I remember every page, but whether an idea still interrupts me while I'm designing, reviewing, debugging, or changing code.

1. The Pragmatic Programmer — the advice that ages with you

David Thomas and Andrew Hunt's current The Pragmatic Programmer, 20th Anniversary Edition was published in 2019, with substantial revisions and new material rather than being a straight reprint of the original.

What stayed with me isn't one technique. It's the attitude toward being responsible for your work.

After enough years, you discover that programming is only partly about producing correct code. You're managing change, communicating intent, automating repetitive work, learning continuously, and trying not to leave tomorrow's developer with a mystery you created today.

I appreciated that less when I was younger. Back then, elegant code felt like stronger evidence of skill. Now I'm increasingly impressed by codebases that can survive changing requirements without everyone becoming afraid to touch them.

This is probably the book here whose advice has become more recognizable as my career has gotten longer.

2. A Philosophy of Software Design — complexity is usually nearby

John Ousterhout's A Philosophy of Software Design is currently in its second edition, released in 2021. That edition added material on deciding what matters, expanded its discussion of general-purpose modules, and included comparisons with some of the design advice in Clean Code.

Its big contribution to my thinking is the way it frames complexity.

Twenty-one years is enough time to become suspicious of cleverness. I've seen abstractions that looked beautiful when they had three implementations become remarkably awkward when they had twelve. I've also learned that code can be locally clean while the system surrounding it remains painfully difficult to understand.

Ousterhout keeps pulling the conversation toward whether a design hides complexity or merely rearranges it.

That is a question I wish I'd learned to ask earlier. Complexity has an irritating habit of remaining at the scene long after the fashionable design pattern has left.

3. Designing Data-Intensive Applications — architecture became a trade-off question

The current Designing Data-Intensive Applications, 2nd Edition is by Martin Kleppmann and Chris Riccomini and was published in February 2026. It updates the original for modern data systems while retaining its emphasis on reliability, consistency, scalability, storage, distributed systems, and architectural trade-offs.

Experience made this kind of book more useful to me, not less.

Early in my career, architecture discussions often felt like technology selection: which database, which queue, which framework? Eventually I realized the interesting question is usually what guarantee we're buying and what problem we're accepting in exchange.

Replication helps something and complicates something else. Distribution solves one constraint while introducing failure modes you didn't have before. “Scalable” means almost nothing until you ask what exactly needs to scale.

DDIA gave me a better habit: interrogate the trade-off before becoming attached to the box on the architecture diagram.

4. Refactoring — because most code already exists

Martin Fowler's Refactoring: Improving the Design of Existing Code is currently in its second edition, published in 2018. It discusses code smells, testing, and a large catalog of refactorings with mechanics for changing code safely.

This book represents a lesson that took me embarrassingly long to appreciate: most professional programming isn't starting from an empty directory.

You're changing software somebody already depends on.

Rewriting everything can feel wonderfully clean from a distance. Years of maintaining systems make the hidden cost more obvious: undocumented behavior, forgotten edge cases, migrations, integrations, and business rules nobody realized were business rules.

Refactoring gave me a more useful instinct than “can we rewrite this?” Improve the structure while preserving behavior, and make the next change easier.

That skill has aged exceptionally well.

5. Grokking Coding Interview Patterns — experience isn't interview practice

This is the odd one out, intentionally.

Grokking the Coding Interview Patterns is currently an interactive Educative course rather than a conventional print programming book. Its present version teaches 28 reusable coding patterns across areas such as two pointers, binary search, graphs, dynamic programming, tries, and union-find, with hands-on problems and mock interviews.

After 21 years, I find its premise surprisingly relevant: knowing how to build production software does not automatically make algorithm interviews easy.

You can spend years reviewing APIs, debugging distributed systems, and maintaining enormous codebases, then stare at a timed problem and completely miss that it's a sliding-window problem wearing a fake moustache.

Pattern-based preparation is more useful to me than memorizing hundreds of disconnected solutions because it asks, “What kind of problem am I looking at?”

Its scope is obviously narrower than The Pragmatic Programmer or Refactoring. If you're not interviewing, the other books will affect your everyday engineering more. But for the strange little sport that is the coding interview, reusable pattern recognition deserves its own case file.

What actually stuck

Book	The lesson that stuck
The Pragmatic Programmer	Treat programming as a craft
A Philosophy of Software Design	Contain complexity
Designing Data-Intensive Applications	Investigate the trade-off
Refactoring	Improve code safely
Grokking Coding Interview Patterns	Recognize reusable problem patterns

Case closed: what 21 years changed

After 21 years, I care much less about whether a programming book can teach me another API.

APIs disappear. Frameworks get replaced. Today's fashionable architecture eventually acquires a migration plan.

The useful books leave something behind after those details expire: a habit of questioning abstractions, controlling complexity, understanding trade-offs, changing existing code carefully, or recognizing the structure beneath an unfamiliar problem.

Those are the ideas that survived my investigation.

Which programming book left you with an idea you still use years later? I'm always willing to open case file #21.

I Tried 20 Online Course Platforms. Here Are My Top 6 Recommendations for 2026

The Bug Detective — Sat, 22 Aug 2026 19:10:00 +0000

I have enough abandoned course-platform accounts to make my password manager look like an archaeological site.

Over the years, I've learned Python on one platform, started cloud courses somewhere else, bought suspiciously specific framework courses during sales, and occasionally discovered that reading the documentation would have been faster than finishing another three-hour video.

Somewhere in that process, the platforms themselves became the investigation.

By platform ten, “huge course library” had officially stopped counting as evidence. In 2026, information is cheap. AI can explain an error, documentation is searchable, and tutorials exist for almost everything. What I'm willing to pay for now is structure, practice, expert instruction, and less time wondering what I should learn next.

1. Educative — when I want to code instead of watch

Educative remains the platform I naturally gravitate toward when I don't want video to be the default.

Its courses are text-based and interactive, with in-browser coding, quizzes, challenges, projects, and assessments. Its 2026 offering also includes Skill Paths, Cloud Labs with temporary cloud environments, AI code feedback, and AI mock interviews. Educative's current platform is particularly focused on software development, cloud, AI, and technical interview skills.

I like being able to read an explanation and immediately change code instead of watching somebody type it first. That's personal preference, but it matters.

If you learn best from an instructor speaking through a topic, Educative can feel noticeably less human than a great video course. I'd choose it specifically when active, text-first technical learning is the goal.

2. Coursera — when I want an actual program, not another random course

I open Coursera for a completely different reason.

In 2026, it still stands out for structured learning from universities and companies, with courses, Specializations, Professional Certificates, university certificates, and full degree programs. Its current partners include universities alongside companies such as Google, IBM, Microsoft, and others. Coursera's catalog now spans more than 10,000 learning offerings.

This makes more sense to me when I want a recognizable institution behind a longer learning sequence or when the credential itself has value.

The trade-off is that this structure can be overkill when my actual problem is “I need to understand Kubernetes networking before Friday.” Coursera isn't usually my first suspect for a quick technical gap.

3. Udemy — when I need that exact course

Udemy has repeatedly won one very specific case: obscure specificity.

Want a course on a particular framework, certification, software tool, or version of a technology? There's a decent chance somebody has made one. Udemy currently supports both individual course purchases and a Personal Plan subscription covering a curated subset of its much larger catalog. Udemy's current plans reflect both ways of learning.

The enormous marketplace is simultaneously the advantage and the problem. I've found excellent instructors there, but I've also learned to investigate the course update history, curriculum, previews, and instructor carefully.

Udemy is where I'd go when I know exactly what I want. I wouldn't use the size of its catalog as a learning plan.

4. Pluralsight — when I'm treating learning like professional upskilling

Pluralsight feels strongest to me when the goal is less “teach me coding” and more “I need to systematically close technical skill gaps.”

Its current platform combines technical courses with learning paths, Skill IQ assessments, certification preparation, and hands-on labs running in temporary environments. Its coverage includes software development, cloud, AI, data, security, and IT operations.

I particularly like the assessment angle. Sometimes the hardest part of learning an established technology isn't finding content; it's figuring out what I already know and where the holes are.

For casual exploration, Pluralsight can feel more structured than necessary. For developers or teams approaching learning as deliberate professional development, that structure is the point.

5. Master Dev — when I want an expert to go deep

Frontend Masters is the platform I open when the instructor matters as much as the topic.

The name undersells its current catalog somewhat. Frontend remains central, but its 2026 learning paths also cover full-stack and backend development, computer science, Python, AI, architecture, DevOps, and other adjacent engineering areas. Courses originate as live workshops, where learners can interact with instructors, before being edited into structured courses.

I like it when I already know enough about something to appreciate an expert spending several hours on the uncomfortable details.

The obvious trade-off is that it's primarily instructor-led learning. If watching technical material makes you start checking Slack after eight minutes, an interactive platform may keep you more honest.

6. Codecademy — when I need the path to keep pushing me forward

Codecademy still makes a strong case for guided interactive learning, especially when you're building familiarity with a new programming area.

Its current Skill Paths and Career Paths combine lessons, quizzes, and projects in a defined sequence. The 2026 platform also includes AI-assisted coding help, personalized practice, career-oriented paths, assessments, and interactive projects.

What Codecademy does well is remove decisions. Instead of collecting six tutorials and pretending that's a curriculum, you can follow a path and keep practicing.

As developers become more experienced, that guidance can become less valuable because we increasingly want to jump directly to the difficult part. For beginners or anyone entering an unfamiliar area, however, those rails can be useful.

My six-platform cheat sheet

Platform	I'd choose it for...	Main trade-off
Educative	Interactive technical learning	Less appealing to video learners
Coursera	Structured programs and credentials	Can be more than you need
Udemy	One very specific course	Quality varies by instructor
Pluralsight	Professional tech upskilling	More structured than casual learning
Frontend Masters	Deep expert instruction	Primarily video/workshop-driven
Codecademy	Guided interactive practice	Less necessary once highly experienced

Case closed: which one would I actually pay for?

In 2026, I don't think access to information is a convincing reason to subscribe to a learning platform anymore. I can ask an AI assistant what a closure is before I've finished typing the question.

What platforms can still do well is organize that information into a sequence, make me practice it, expose gaps in what I think I understand, or put a genuinely excellent instructor between me and three hours of confused documentation browsing.

So I wouldn't pick one winner. I'd use Educative for interactive developer learning, Coursera for structured credentials, Udemy for a specific course, Pluralsight for systematic professional upskilling, Frontend Masters for expert depth, and Codecademy when I want guided practice.

The best platform is the one that's unusually good at solving the learning problem you actually have.

Which course platform are you still genuinely using six months after signing up? I'm accepting nominations for suspect #21.

I read Designing Data-Intensive Applications, 2nd edition and it's awesome

The Bug Detective — Sat, 22 Aug 2026 04:43:00 +0000

Most technical books leave me with a collection of answers. Designing Data-Intensive Applications, 2nd Edition left me with an inconvenient number of new questions.

I'd finish a section and start thinking about systems I'd worked with before. Why did we choose that database? What consistency guarantees were we actually depending on? What happened when two operations raced? Had we designed for a particular failure, or had we simply assumed it wouldn't happen?

That was the slightly annoying brilliance of reading Martin Kleppmann and Chris Riccomini's second edition. It didn't just add distributed-systems terminology to my vocabulary. It made architectural decisions I'd previously accepted without much interrogation look suspicious again.

For the Bug Detective, that's basically catnip.

This book made “simple” systems suspicious again

One thing Designing Data-Intensive Applications does extremely well is remove the comforting boxes we draw around infrastructure.

It's easy to draw “database” on a diagram and move on. In reality, that box immediately raises questions about storage, indexing, replication, transactions, consistency, failure, scalability, and how the data will evolve. The second edition works through those foundations across data models, storage and retrieval, replication, sharding, transactions, distributed systems, batch processing, streaming, and more.

I caught myself rereading explanations not because I didn't understand the terminology, but because I realized I'd previously understood some familiar terms rather vaguely.

“Reliable” is a good example. It's easy to call a system reliable. It's harder to specify what failures it should tolerate while continuing to work correctly.

The book kept finding assumptions I'd apparently left unattended at the crime scene.

The trade-offs are the actual lesson

I expected to come away knowing more about databases and distributed systems. I did, but the more useful change was becoming less interested in asking which technology is “best.”

The book constantly pushes the discussion toward requirements and trade-offs. A particular architecture might improve one property while introducing complexity somewhere else. A storage strategy makes sense because of the workload it serves. Replication provides benefits, but then you have to reason about lag, conflicting writes, and failures. Sharding can help with scalability while creating its own operational and query challenges.

That framing sounds obvious until you notice how often engineering conversations skip it.

Someone proposes a database because it's “scalable.” A queue gets added because the architecture should be “event-driven.” Microservices appear because the application might eventually become large.

After reading DDIA, my first instinct is increasingly to investigate the claim behind the adjective. Scalable for what load? Reliable against which faults? Consistent in what sense? What complexity are we accepting in exchange?

That's a much healthier way to discuss architecture than collecting fashionable boxes for diagrams.

Failure stops looking like an edge case

The sections dealing with distributed systems were probably the ones that changed my thinking most.

Distributed systems are particularly good at producing bugs where every individual component insists it did nothing wrong. Networks can be unreliable, clocks aren't as trustworthy as we'd like, processes pause, messages arrive late, and one machine may have a completely different picture of reality from another.

The book doesn't treat those conditions as weird disasters happening outside the “normal” system. They're part of the environment the system has to operate within.

That distinction matters.

I've definitely been guilty of designing the happy path first and mentally putting failures into a folder labeled “we'll handle that later.” DDIA makes that increasingly difficult. Once you start asking what happens during partial failure, concurrent updates, replication lag, or disagreement between nodes, those questions become part of the architecture rather than cleanup work.

It also makes certain production mysteries less mysterious. Sometimes the prime suspect isn't broken code. It's an assumption about ordering, timing, or guarantees that was never actually true.

The second edition actually earns the “2nd Edition” label

This isn't simply the 2017 book with a few newer product names inserted.

The second edition was published by O'Reilly in February 2026 and adds Chris Riccomini as coauthor alongside Martin Kleppmann. O'Reilly describes it as integrating newer technologies and trends while retaining the book's focus on the principles behind data systems.

You can see that modernization in the scope. The new edition discusses cloud versus self-hosting, cloud-native architectures, serverless computing, modern data warehouses, vector embeddings, GraphQL, event sourcing and CQRS, durable execution and workflows, local-first software, and contemporary approaches to data systems.

What I like is that these additions don't turn the book into a catalog of whatever infrastructure happens to be fashionable in 2026. The technologies remain examples for investigating deeper questions about architecture.

That gives the edition a better chance of aging well. Product names change quickly. Questions about reliability, consistency, data models, storage, failure, and trade-offs tend to stick around.

I wouldn't recommend it to absolutely everyone

Calling this book awesome doesn't mean I'd hand it to someone during their first week of programming.

O'Reilly categorizes the second edition as intermediate to advanced, which feels right. If you're still getting comfortable building applications, gaining some practical experience first will give you more systems to mentally compare with what you're reading.

It's also not a particularly casual read. Some sections demanded enough concentration that I stopped trying to make progress and reread a few paragraphs instead. That's not a flaw, but it's worth knowing what you're signing up for.

I think backend, data, infrastructure, and platform engineers will find obvious value here. I'd also recommend it to experienced application developers who have reached the point where they want to understand what the databases, queues, caches, and distributed services beneath their code are actually promising them.

If you're looking for a quick System Design interview cheat sheet, there are much faster resources. This book is more interesting than that.

Case closed

The biggest change DDIA made wasn't giving me more technologies to mention in architecture discussions.

It made me less willing to accept architectural decisions without investigating their guarantees.

I now find myself asking what a system is optimizing, what assumptions it depends on, what failure it tolerates, and what complexity we're accepting in return. That's why Designing Data-Intensive Applications, 2nd Edition is awesome to me: it changes the questions that appear in your head before you start drawing boxes.

And once those questions are there, they're annoyingly difficult to get rid of.

What's the technical book that permanently changed the questions you ask when designing software?

Back to the Basics of Java, Part 2: The JAR

The Bug Detective — Fri, 21 Aug 2026 10:32:00 +0000

This is Part 2 of my attempt to revisit the Java things many of us learned to use long before we bothered to understand them.

JAR files are a perfect example. I've added dependencies and watched .jar files appear. I've packaged applications into them, run java -jar, and occasionally blamed a JAR when some class mysteriously disappeared at runtime.

For something that shows up in practically every Java learning project, I'd spent surprisingly little time asking what the file itself actually was.

So I opened the case file. It turns out a JAR is considerably less mysterious than the layers of tooling around it can make it seem.

So what exactly is a JAR?

JAR stands for Java Archive, and the first useful fact is that it isn't some opaque Java-specific binary format.

A JAR is an archive based on the ZIP format. It bundles files together into one convenient package. Those files commonly include compiled Java classes, resources, and metadata.

A tiny application JAR might look like this:

my-app.jar
├── META-INF/
│   └── MANIFEST.MF
└── com/
    └── example/
        ├── Main.class
        └── Calculator.class

Those .class files are the bytecode produced when Java source files are compiled. The directory structure isn't arbitrary either.

If Main.java begins with:

package com.example;

then its compiled class belongs under the corresponding com/example/ path inside the JAR.

The archive can also contain non-class resources such as configuration files, images, or other data an application or library needs.

Let's open the evidence bag

You don't have to trust your build tool's description of what's inside a JAR. The JDK gives you the jar utility, and you can inspect an archive directly:

jar tf my-app.jar

Here, t tells jar to list the archive's table of contents, while f says the archive name is being supplied. Modern long-form syntax can express the same operation with jar --list --file my-app.jar.

You might see:

META-INF/
META-INF/MANIFEST.MF
com/example/Main.class
com/example/Calculator.class

Because JARs are ZIP-based, ordinary archive tools can inspect them too. The JDK's jar command is still useful because it understands operations and metadata specific to JARs.

This is one of those debugging habits that seems obvious only after you've needed it. If Java claims a class isn't available, checking whether that .class file actually exists in the archive is useful evidence.

That mysterious META-INF folder

META-INF is where a JAR can keep metadata about the archive. For this investigation, the most interesting file is usually:

META-INF/MANIFEST.MF

A minimal manifest for an executable application might contain:

Manifest-Version: 1.0
Main-Class: com.example.Main

Main-Class tells the Java launcher which class is the application's entry point. That class needs an appropriate main method, such as:

public static void main(String[] args)

The manifest can contain other attributes, but we don't need to interrogate all of them today. The important clue is that the JAR can carry information about how it should be used.

So how does `java -jar` actually work?

Suppose I run:

java -jar my-app.jar

Java isn't opening the archive and guessing which of the 200 classes looks most important.

For an executable JAR, the manifest's Main-Class attribute identifies the class the launcher should load as the starting point. In our example, that's com.example.Main.

This also explains why not every JAR is executable.

A library JAR might contain hundreds of compiled classes and resources without having an application entry point. Its job is to provide code to another application, not to be launched directly.

That's what you're often getting when Maven or Gradle resolves a Java dependency: a library packaged as a JAR that can be made available to your application through the appropriate class path or module path setup.

Same file format, different job.

Building one without hiding behind Maven

Modern build tools make packaging convenient, but doing it manually once makes the mechanics much clearer.

Imagine this source file:

package com.example;

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello from the JAR");
    }
}

First, compile it:

javac -d out src/com/example/Main.java

The -d out option tells javac where to place the compiled output. You'll end up with out/com/example/Main.class.

Now create a basic JAR:

jar --create --file my-app.jar -C out .

The -C out . portion tells jar to change to the out directory and include its contents, preserving the package structure.

If I want an executable JAR, I can specify the entry point while creating it:

jar --create --file my-app.jar --main-class com.example.Main -C out .

The jar tool records that main class in the manifest. I can then run:

java -jar my-app.jar

No Maven required for this little experiment. More importantly, none of the packaging feels particularly magical anymore.

Why knowing this actually helps

Most of us won't manually build production JARs every morning. Maven, Gradle, IDEs, and frameworks exist for good reasons.

Understanding the archive still gives you another debugging surface.

If you're chasing a ClassNotFoundException, you can inspect whether the expected class was packaged. If a resource can't be found, you can check where it ended up. If java -jar won't start the expected application, the manifest becomes an obvious suspect.

Dependency problems also become slightly less abstract once you remember that many of those dependencies are ultimately archives containing real .class files and resources.

Instead of assuming the build system performed mysterious Java rituals incorrectly, you can inspect the artifact it actually produced.

Case closed

JARs feel complicated largely because modern Java development lets us interact with them indirectly.

Strip away the tooling and the basic idea is refreshingly ordinary: a JAR is a ZIP-based Java Archive containing classes, resources, and metadata. Package paths preserve the structure of Java packages, META-INF holds metadata, and an executable JAR can use Main-Class to tell java -jar where execution begins.

The next time packaging gets weird, I'll be slightly less inclined to stare accusingly at pom.xml and slightly more inclined to run jar tf.

What's another piece of Java tooling you use constantly but have never actually stopped to investigate?

I've Read 20 Python Books, And Here Are My Top 5 Recommendations For 2026

The Bug Detective — Fri, 21 Aug 2026 09:59:25 +0000

At some point, buying another programming book becomes suspiciously good at making you feel like you're learning without requiring you to actually write any code.

I've accumulated roughly 20 Python books over the years, and my opinion of them has changed more than I expected. Books I loved as a beginner now feel too introductory. Others I abandoned after fifty pages suddenly make much more sense after spending years actually coding Python.

So when I revisited the shelf for 2026, I stopped asking, "What's the best Python book?"

The better question was: which book would I hand to a particular developer right now?

These are the five that survived the investigation.

First, what survived the bookshelf investigation?

My first suspect when evaluating a programming book is always the examples.

Does the book make me leave the page and experiment? Does it teach something specifically useful about Python? Would I keep any part of it nearby after finishing it?

For 2026, I also checked current editions. That matters more than publication dates alone. Durable explanations can age beautifully; instructions built around obsolete tooling generally don't.

1. Python Crash Course — the one I'd hand to a beginner

If someone told me, "I've never really learned Python. Give me one book and a path," Python Crash Course by Eric Matthes would be high on my list.

As of 2026, the current published edition is the third edition from 2023. A fourth edition has been announced, but it isn't due until 2027. The third edition teaches the fundamentals and then moves into substantial projects involving a game, data visualization, and a web application.

That's the part I appreciate. You don't spend the entire book collecting syntax like Pokémon cards. Eventually, you have to combine what you've learned into something larger.

It also encourages experimentation through exercises rather than letting you simply nod along with explanations. I learned fairly early that "yes, I understand lists" and "yes, I can use lists to solve this problem" are two very different claims.

I wouldn't choose it for an experienced Python developer. But for someone who wants structure without being trapped in beginner exercises forever, it remains an easy recommendation.

2. Automate the Boring Stuff — the fastest route to "oh, Python can do that?"

Automate the Boring Stuff with Python has always occupied a different case file.

The third edition arrived in 2025, which makes this recommendation especially easy in 2026. Al Sweigart updated the material and added coverage including SQLite databases, command-line programs, and audio-related tasks alongside the book's familiar automation focus.

Its real strength isn't teaching Python in the most academically complete way. It's giving beginners a reason to care.

Files need renaming? Spreadsheet work is wasting your afternoon? Need to extract information from documents or automate repetitive input? Suddenly loops and dictionaries aren't abstract concepts. They're accomplices.

That practical bias can also be its limitation. If I wanted the cleanest structured introduction to programming fundamentals, I'd pick Python Crash Course or Think Python instead.

But for someone whose motivation appears the moment code saves them twenty minutes of tedious work, this would be my pick.

3. Fluent Python — the book I appreciated much more later

I wouldn't give Fluent Python to somebody who learned for loops yesterday.

The current second edition, published in 2022, is explicitly aimed at intermediate-to-advanced developers and digs into Python's data model, data structures, functions, typing, object-oriented idioms, generators, concurrency, and metaprogramming.

This is one of those books that becomes more useful after you've written enough Python to develop questions you didn't previously know existed.

Why do certain Python APIs feel so natural? What are special methods actually enabling? When should I use protocols, generators, decorators, or particular collection types? Fluent Python investigates the language itself rather than simply giving you more things to build with it.

It's dense, and that's not a criticism. I treat it more like a book to study and revisit than something to race through over a weekend.

If you're still learning basic Python, wait. The evidence will make much more sense later.

4. Effective Python — for working code that's starting to smell funny

Effective Python by Brett Slatkin is the book I'd recommend when your Python works, but you're beginning to suspect it could work better.

The third edition was published in late 2024 and expanded the book to 125 specific recommendations for writing better Python.

I like its item-based structure because it matches how I actually revisit technical books. I don't necessarily want another start-to-finish Python curriculum. Sometimes I want focused guidance on one decision I'm making in production code.

It's especially useful when you've crossed that awkward boundary between "I can write Python" and "I want other developers to enjoy maintaining the Python I write."

Compared with Fluent Python, it feels more tactical. If you want a deep exploration of the language, choose Ramalho. If you want concentrated guidance you can apply to everyday code, I'd investigate Slatkin first.

5. Think Python — for learning how programmers think

Think Python is the least "build something impressive by chapter five" recommendation here, and that's precisely why it belongs.

Allen B. Downey's third edition was published in 2024, so this isn't a recommendation based on nostalgia for an aging Python textbook. It starts from programming as a way of thinking and develops concepts through functions, data structures, iteration, debugging, and exercises.

I like it for learners who don't merely want to know what syntax to type. It spends time developing the mental models behind programming.

The downside is obvious: if you're motivated primarily by immediately building applications, Python Crash Course or Automate the Boring Stuff will probably feel more rewarding.

If you're learning programming itself through Python, though, Think Python remains remarkably relevant in 2026.

My five-book cheat sheet

Book	I'd recommend it to...	Why it made my five
Python Crash Course	New Python learners	Structured learning + projects
Automate the Boring Stuff	Practical beginners	Immediate usefulness
Fluent Python	Experienced Python developers	Deep language understanding
Effective Python	Working developers	Better Python habits
Think Python	New programmers	Strong programming reasoning

Case closed: which book would I actually pick?

After twenty Python books, I've become increasingly suspicious of "best book" lists that never ask who is reading.

If you're beginning with Python, I'd start with Python Crash Course. If useful automation is what will keep you interested, grab Automate the Boring Stuff. If you're learning programming concepts themselves, Think Python makes a stronger case.

Once you're already writing Python professionally, the investigation changes. Effective Python can sharpen everyday decisions, while Fluent Python can change how you understand the language underneath those decisions.

That's my shelf in 2026.

Which Python book actually changed how you write Python? I'm always looking for suspect #21.