DEV Community: The Bug Detective

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.

I Tried 50 Python Courses, Here Are My Top 5 Recommendations

The Bug Detective — Fri, 21 Aug 2026 09:39:44 +0000

Somewhere around course twenty, I realized I had developed a new debugging skill: detecting suspiciously familiar Python curricula.

Variables. Strings. print(). An enthusiastic explanation of loops. A calculator project. Repeat.

I started this experiment because people kept asking me which Python course I would actually recommend. After looking at enough “complete Python bootcamps” to fill a small data center, I wanted a better answer than whichever course had the nicest landing page.

So, I tried 50 Python courses and Here are my top 5 recommendations based on one question: which ones would I genuinely tell another developer to spend their time on?

A small confession before we examine the evidence: I did not complete all 50 from beginning to end.

1. Educative – Learn Python 3 from Scratch

Educative stood out because it minimizes the distance between reading about Python and writing Python.

The course is browser-based and structured around interactive lessons and coding practice. It starts with fundamentals such as variables, operators, functions, conditionals, and loops before moving into more substantial Python concepts.

That makes it my pick for someone who dislikes video-heavy courses. You can read an explanation, change some code, break something, fix it, and keep moving without constantly switching between a video player, editor, and terminal.

The limitation is essentially the same thing that makes it good: if you learn best from a charismatic instructor talking through concepts in depth, a text-first interactive format may feel less engaging.

Pick this if: you want a focused, interactive path where you're coding almost immediately.

2. University of Helsinki – Python Programming MOOC

The Helsinki MOOC was the course that made me think, “Okay, somebody brought homework.”

And I mean that as praise.

The course spans introductory and advanced programming material, with exercises that go well beyond tiny syntax checks. As you progress, you encounter topics such as files, error handling, objects and classes, comprehensions, recursion, and functional programming.

The progression feels closer to taking an actual university programming course than consuming tutorials. You repeatedly have to turn requirements into working programs.

That also makes it less appealing if you want instant gratification. It requires patience and considerably more effort than breezier beginner courses.

Pick this if: you want rigor, lots of exercises, and don't mind earning your progress.

3. CS50's Introduction to Programming with Python

CS50P wins a different category: teaching.

The course is entirely focused on Python and covers functions, conditionals, loops, exceptions, libraries, unit testing, file I/O, regular expressions, and object-oriented programming, alongside problem sets and a final project.

What kept CS50P out of my discard pile was how much attention it gives to thinking about programs. Debugging, testing, readability, and design aren't treated as optional decorations after you learn syntax.

David Malan's lecture style is a major part of the experience, though that creates an obvious trade-off: this is more lecture-oriented than Educative or Helsinki.

Pick this if: you want someone to actually teach programming rather than hand you a Python syntax checklist.

4. Automate the Boring Stuff with Python

This is my recommendation for the person asking, “Cool, but when does Python become useful?”

Very quickly.

Al Sweigart's Automate the Boring Stuff with Python takes the fundamentals and quickly turns toward practical automation: manipulating files and spreadsheets, working with documents, web tasks, and automating repetitive computer work.

That's its superpower. Instead of making programming feel like preparation for someday programming, it gives beginners reasons to automate annoying things now.

The trade-off is that I wouldn't choose it as my only resource if my goal were a more systematic computer science or software engineering foundation.

Pick this if: you have boring computer tasks and would enjoy making Python eliminate them.

5. 100 Days of Code: The Complete Python Pro Bootcamp

Angela Yu's 100 Days of Code survived because repetition matters.

The course revolves around building projects across 100 days and ranges through Python fundamentals into automation, games, web development, APIs, and data work. The variety gives you plenty of opportunities to stop following along and actually build something.

The advantage is momentum. Instead of endlessly “learning Python,” you keep having to use it.

My reservation is scope. The course covers a lot, and learners who obsess over completing every day perfectly can turn an enjoyable challenge into a second job.

Pick this if: projects keep you motivated and you want sustained practice rather than a short introduction.

My five-course cheat sheet

Course	Best for	Why I'd pick it
Educative	Interactive learners	Code while learning
Helsinki MOOC	Serious practice	Rigorous exercises
CS50P	Lecture learners	Excellent teaching
Automate the Boring Stuff	Practical beginners	Useful automation
100 Days of Code	Project learners	Repetition + building

Case closed: which one would I actually take?

If I wanted the fastest interactive start, I'd choose Educative. If I wanted the strongest exercise-heavy foundation, Helsinki would be my prime suspect. For teaching quality, I'd go CS50P. For immediate usefulness, Automate the Boring Stuff. For building a daily coding habit, 100 Days of Code.

After investigating 50 resources, that was the useful finding: there isn't a universally “best” Python course. There are courses that are unusually good at making a particular kind of learner keep coding.

That's a much better filter than course length, star ratings, or the number of times “zero to hero” appears on the landing page.

Which Python course actually made Python click for you? And which one should I add if this investigation gets reopened?

DEV Community: The Bug Detective

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

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

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

3. Udemy — when I need that exact course

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

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

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

My six-platform cheat sheet

Case closed: which one would I actually pay for?

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

This book made “simple” systems suspicious again

The trade-offs are the actual lesson

Failure stops looking like an edge case

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

I wouldn't recommend it to absolutely everyone

Case closed

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

So what exactly is a JAR?

Let's open the evidence bag

That mysterious META-INF folder

So how does java -jar actually work?

Building one without hiding behind Maven

Why knowing this actually helps

Case closed

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

First, what survived the bookshelf investigation?

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

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

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

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

5. Think Python — for learning how programmers think

My five-book cheat sheet

Case closed: which book would I actually pick?

I Tried 50 Python Courses, Here Are My Top 5 Recommendations

1. Educative – Learn Python 3 from Scratch

2. University of Helsinki – Python Programming MOOC

3. CS50's Introduction to Programming with Python

4. Automate the Boring Stuff with Python

5. 100 Days of Code: The Complete Python Pro Bootcamp

My five-course cheat sheet

Case closed: which one would I actually take?

So how does `java -jar` actually work?