How to Debug Like a Pro When You're Just Starting Out

How to Debug Like a Pro When You're Just Starting Out

The OER Observatory aggregates and displays OER-related news and content from third-party sources worldwide. This content is not produced by UNESCO or the OER Dynamic Coalition. All rights and responsibility for the original content remain with the respective authors and publishers. The inclusion of third-party content in the Observatory does not imply endorsement by UNESCO or the OER Dynamic Coalition. Users can access the original source through the link provided with each item.

By a Senior Android Developer who has broken a LOT of things

The Truth Nobody Tells You

Every developer you admire the ones whose code looks effortless spends a huge chunk of their day debugging. Not writing elegant code. Debugging.

When I was starting out, I thought bugs meant I was bad at this. Now, 10+ years in, I know bugs just mean you're doing it. The difference between a beginner and a pro isn't that pros write bug-free code. It's that pros find bugs faster.

Here's how to start thinking like one.

1. Stop Guessing. Start Reading.

The number one beginner mistake: seeing a red error and immediately changing random things hoping it goes away.

Don't do that.

Read the error message. Actually read it. The Android logcat (or your console/terminal) is telling you exactly what went wrong, on which line, in which file.

java.lang.NullPointerException: Attempt to invoke virtual method

'java.lang.String android.content.Intent.getStringExtra(java.lang.String)'

on a null object reference

at com.example.app.MainActivity.onCreate(MainActivity.java:42)

This message is your friend. It says:

- What: NullPointerException (something is null that shouldn't be)

- Where:

MainActivity.java

, line42

- What was happening: You tried to call

.getStringExtra()

on a null Intent

Go to line 42. Don't Google first. Read first.

2. Learn to Use a Debugger (Not Just Print Statements)

We all start with Log.d("TAG", "I am here")

sprinkled everywhere. That's fine, it works. But the debugger is a superpower you need to learn early.

In Android Studio, you can:

- Set a breakpoint (click the line number gutter)

- Run in Debug mode (the bug icon, not the play button)

- When the app hits your breakpoint, it pauses

- You can now inspect every variable at that exact moment

No more guessing what userList

contains. You can see it, live, with all its values.

The shift in thinking: Print statements tell you what was. The debugger shows you what is.

3. Reproduce the Bug First

Before fixing anything, make sure you can reliably reproduce it.

Ask yourself:

- What exact steps cause this to happen?

- Does it happen every time or only sometimes?

- Does it happen on all devices or just one?

If you can't reproduce it, you can't verify you fixed it. A bug you "fixed" but can't reproduce is just a bug hiding.

4. Isolate, Don't Shotgun

When something breaks, beginners often change five things at once. Then it works and they have no idea which change fixed it. Or worse, it doesn't work and now they've made it worse.

Change one thing at a time.

If you think the issue is in fetchUserData()

, comment out your changes, add them back one by one, and test each time. This feels slower but is actually much faster.

5. The Rubber Duck Method (Seriously)

Grab a rubber duck. Or a coffee mug. Or your dog.

Explain your bug out loud, line by line, to this inanimate object.

"Okay, so on line 35 I'm calling this function... and it returns a list... but then on line 42 I'm assuming it's never empty..."

You'll catch your own bug before you finish the sentence. About 70% of the time. I still do this on hard problems. It works because explaining forces clarity.

6. Read Stack Traces Bottom-Up (For Android)

In Android, when your app crashes, you get a big, scary wall of red text the stack trace. Most beginners look at the top and panic.

Look at the bottom first to understand what triggered the chain. Then read upward to find your code (usually the first line that mentions your package name, like com.yourapp

).

That's where the real problem is. The top of the stack is often just Android framework code reacting to your mistake.

7. Use Git as a Debugging Tool

If your code was working yesterday and is broken today, git is your best friend.

git diff

This shows you every change you've made since your last commit. Often, the bug is staring right at you in that diff.

If things are really messy:

git stash

This temporarily removes all your changes. If the bug disappears, one of your changes caused it. Add them back one by one.

8. Google the Right Way

When you do Google (and you will, we all do), be specific:

- Bad:

"android crash"

- Good:

"NullPointerException getStringExtra null intent Android"

Copy the key part of the error message into the search. Not the whole thing. The part that describes what went wrong, not the file names (those are unique to your project).

Stack Overflow answers from the last 2-3 years are usually most relevant.

9. Know When to Take a Break

This sounds like a cop-out. It isn't.

Your brain is a pattern-matching machine that gets tired. If you've been staring at the same bug for 45 minutes, close the laptop for 15 minutes. Get water. Walk around.

The number of times I've come back and spotted the issue in 30 seconds is embarrassing. There's actual neuroscience behind this: your brain keeps working on problems in the background when you step away.

10. Build a Bug-Hunting Mindset

The pros think about debugging differently. When they see a bug, they don't feel defeated. They get curious.

Ask yourself:

- What did I assume that turned out to be wrong?

- What was I expecting to happen vs. what actually happened?

- What's the smallest possible thing that could explain this?

The answers lead you straight to the fix.

The Takeaway

Debugging is a skill. Like any skill, it gets better with intentional practice.

Start small: next time something breaks, before touching anything just read the error. Find the line. Understand what it's saying. Then set a breakpoint and look at your data.

You'll be surprised how fast things click.

Every bug you fix teaches you something. The developers who grow fastest aren't the ones who write perfect code they're the ones who learn the most from each failure.

So go break things. Then fix them. That's how you get good.

Thanks for reading! If this helped you, follow me for more no-fluff Android dev content. Have a debugging tip I missed? Drop it in the comments.

👋 Let's Connect

If you enjoy content about Android development, Jetpack Compose, Kotlin, software architecture, and engineering best practices, I'd love to stay connected.

📺 YouTube

In-depth Android tutorials, real-world projects, architecture discussions, and practical development tips.

💼 LinkedIn

Professional updates, technical insights, articles, and lessons from my software engineering journey.

✍️ Medium

More deep dives into Android development, clean architecture, testing, performance optimization, and modern engineering practices.

📚 Want to Go Deeper?

If you're looking for structured, comprehensive learning resources, check out my Android development books, where I cover concepts in much greater depth than a typical article.

☕ Support My Work

Creating free technical content, books, tutorials, and open educational resources takes considerable time and effort. If this article helped you learn something valuable, you can support my work by:

* Purchasing one of my books

* Sharing my articles with others

* Buying me a coffee

Every bit of support helps me continue creating high-quality content for the Android community.

SOLID Principles for Android Developers -- Learn how to write maintainable, scalable, and testable Android applications using SOLID principles with real-world examples.

👉 Explore all my books: Book Link