Forem: Josh Lawson

Stop Using `console.log` — These Debugging Tricks Will Blow Your Mind

Josh Lawson — Wed, 21 May 2025 22:08:38 +0000

Let’s face it: console.log is the comfort food of debugging. It’s quick, familiar, and kind of satisfying in that junk-food sort of way. But if you've ever buried your terminal in a jungle of console.log("HERE"), console.log("THERE"), and the classic console.log("WTF is going on"), then you already know — it doesn’t scale.

Here’s the thing: if you're building real software (not just tinkering on a rainy Sunday), you need sharper tools. Tools that let you see what's happening under the hood without littering your codebase with digital breadcrumbs.

So yeah, it’s time to break up with console.log. But don’t worry — I’m not gonna leave you hanging. Let’s look at some smarter, dare I say, mind-blowing ways to debug your code without turning your terminal into a cry for help.

But First… Why Do We Cling to `console.log`?

Honestly? Because it works. It’s there. It’s easy. You don’t need to configure anything, and the feedback is immediate. It’s like that friend who gives you bad advice, but at least they answer your calls.

The problem is — it doesn’t help you think. It doesn’t offer context. It’s noisy. It’s often too much or too little. And worst of all, it turns your code into a mess of cluttered print statements that never get cleaned up. (And yes, you will forget one and push it to production.)

So let’s talk about real tools.

1. Set Breakpoints Like a Grown-Up (Seriously)

Debuggers aren’t just for Java or C++ elitists. In modern environments — think VS Code, Chrome DevTools, WebStorm — breakpoints are stupidly easy to use.

Here's how this works in practice:

Open your file in VS Code.
Click next to the line number. Boom — that’s a breakpoint.
Run your app in debug mode.
Execution stops right there. You can hover over variables, peek into scopes, even change values on the fly.

It’s like hitting “pause” on your code mid-movie. Want to see what user.isLoggedIn actually contains right there? Done. No need to type console.log('isLoggedIn:', user.isLoggedIn) five lines in a row.

And if you’re in the browser? Same deal. Open Chrome DevTools → Sources tab → click the line number. You're in.

Honestly, once you start using breakpoints properly, going back to console.log feels like debugging with a blindfold and a stick.

2. Watch Expressions (a.k.a. X-Ray Vision for Variables)

Imagine if you could track a variable’s value as your code runs — without manually logging it every time it changes.

That’s what watch expressions do.

In your debugger panel (again, VS Code or Chrome DevTools), there’s usually a section called Watch. Add a variable name, like cart.total or this.state.user. Now, every time you hit a breakpoint, you get an updated snapshot of its current value — no print statements, no noise, just insight.

Bonus tip? You can even write little expressions like userList.filter(u => u.isAdmin) — and it’ll evaluate them live.

If console.log is a flashlight in the dark, watch expressions are night-vision goggles.

3. Conditional Breakpoints (a.k.a. “Only Stop When It’s Weird”)

Here’s a scenario: you're in a loop that runs 1,000 times, and you only care about the 437th iteration when things blow up. You don’t want to slog through the first 436 steps, right?

Just right-click on your breakpoint and set a condition like i === 437.

Now your code runs normally — until the exact moment something gets weird. You can even go fancier:

user.role === 'admin' && user.isActive === false

Feels like cheating. It kind of is. Use it anyway.

Leverage the Power of `debugger;` (Yup, It’s a Real Keyword)

This one's criminally underused. If you're in JavaScript land, you can literally type debugger; in your code. When DevTools is open, your app will pause there like you set a breakpoint — no clicking required.

It’s like planting a trap in your code. Want to pause right inside an anonymous callback? Or deep in a dynamic component? Drop a debugger; and let it stop on its own terms.

Just — and I’m begging you here — don’t leave it in your commits. 🙃

5. The Network Tab Is Your Best Friend

Raise your hand if you've ever tried to debug a bug that wasn't yours.

You’re calling some API. It returns… something. Maybe. Or it fails mysteriously. Or the payload is missing one tiny field that throws everything off.

Stop guessing. Just hit Network in your browser's DevTools.

You can see the full request and response.
Headers, payload, status codes.
Even how long it took.

It’s like calling the restaurant and asking, “Hey, what did you actually put in my order?” Then they send you the receipt and a recording of the kitchen.

6. Step Through Code Like Sherlock Holmes

Instead of logging ten things in a row, how about just… walking through the code?

Use Step Over, Step Into, and Step Out in your debugger to:

Move one line at a time (Step Over)
Jump inside a function call (Step Into)
Bail out of that function (Step Out)

It’s like flipping pages in a mystery novel — but you’re also the detective.

Once you get used to stepping through functions, you’ll catch weird async bugs, silent fails, and logic errors that logs just can’t show you.

7. Use Logging Libraries (If You Must Log)

Okay, okay. Sometimes you need to log.

But at least do it with style. Use libraries like:

debug: Enables you to toggle logs by namespace (e.g. DEBUG=auth:* node app.js)
winston: For serious, production-level logging with levels, formats, and transports.
pino: Ridiculously fast logger for Node.js apps.

These tools make logs meaningful. You get timestamps, categories, and the ability to turn logs on or off without editing your code.

Think of it like upgrading from Post-It notes to a whiteboard wall with color-coded markers.

8. Embrace Time Travel Debugging (Yes, That’s a Thing)

Instead of this:

console.log('Something broke')

Try this:

console.trace('Something broke')

It prints a full stack trace — so you see where that line was called, and who called it before that.

Especially handy when dealing with callbacks, async flows, or when your app feels like a spaghetti monster with 14 limbs and no memory.

10. Stop Blaming Yourself — Use Linters and Type Systems

Let’s be real: not every bug is a logic bug. Sometimes, it’s a typo. Or a missing prop. Or an undefined variable that only crashes under specific conditions.

You shouldn’t have to debug those. That’s what static analysis is for.

Use TypeScript to catch type mismatches before you run anything.
Use ESLint with solid rule sets to catch sneaky mistakes (like unused vars, unreachable code, or accidentally shadowed variables).

Less time debugging dumb stuff means more time fixing real stuff.

Final Thought: Tools Don’t Make You Lazy — They Make You Smart

There’s this weird macho culture in dev sometimes — like if you’re not suffering, you’re not doing it right. Forget that.

The best developers aren’t the ones who suffer through a thousand logs to track a bug — they’re the ones who build tools, understand systems, and use every trick at their disposal to get the job done faster and better.

You don’t get a gold star for sticking to console.log. You get clean code, saved time, and fewer headaches by working with the tools, not against them.

So go ahead — delete those logs. Set a breakpoint. Watch your variables like a hawk. Debug like you actually like your job.

Because you know what? You probably do.

- Josh

The One Thing Nobody Tells You About Learning to Code

Josh Lawson — Wed, 21 May 2025 06:17:45 +0000

You hear a lot when you're learning to code.

"Start with Python!"

"Just build projects!"

"GitHub is your portfolio!"

Fair enough. But there's one thing almost nobody mentions—one truth that sneaks up on every developer, whether you're hacking on your first HTML button or shipping production-grade microservices at a SaaS startup.

It’s this: learning to code isn’t really about code.

Yeah, weirdly enough—it’s about learning how to be wrong over and over... and not letting that wreck you.

The Setup: When Code Breaks You (and How That’s the Point)

There’s a particular kind of despair that only a broken build at 2:13 AM can give you.

You’re staring at a terminal. The error message mocks you—undefined is not a function. You’ve seen it fifteen times. You’ve checked the docs, double-checked Stack Overflow, even asked ChatGPT twice (guilty)—and still, nada.

This is the moment that no tutorial really prepares you for. Not the syntax, not the logic. It’s the psychological slap—that subtle hum of “maybe I’m just not smart enough for this” creeping in.

But here’s the thing:

That voice? It’s lying.

Code Is Basically the Gym for Your Brain’s Ego

When you first start learning to code, you expect it to feel like learning a new tool. Something linear. Like picking up a hammer and gradually getting better at hitting nails.

But coding is more like learning to juggle knives. While riding a unicycle. In traffic.

You think you’re grasping it, and then—bam! Segmentation fault.

You fix one bug and three more show up like some cursed Hydra.

Here’s the kicker: that’s actually how you learn.

You don’t get better because you wrote perfect code. You get better because you wrote garbage, panicked a little, and then figured it out anyway.

It’s less about code and more about emotional stamina.

Let’s Talk About Shame (Briefly)

Nobody tells you how much shame is baked into this process.

You’ll feel stupid asking a question that got answered on Reddit in 2011.

You’ll copy-paste something from Stack Overflow that works but makes zero sense.

You’ll write code that you know is a duct-taped horror show but hey—it works. Sort of.

And that’s okay.

You know why? Because the people you look up to?

They’ve done the same stuff. They’ve written worse. They’ve Googled “javascript array remove item” like, 900 times.

The difference is—they kept going. They didn’t take that feeling of “I suck at this” and make it their identity.

Debugging Yourself Is Part of the Job

Here’s a fun paradox: you’ll spend more time debugging than writing “real” code.

In fact, debugging is real code.

If you're building a SaaS dashboard and the data won’t load—congrats, you’ve just entered the real dev grind. It's not about building slick features. It’s about making things work when they absolutely don’t want to.

You learn to trace logic like a detective chasing a criminal with a three-second head start. You learn to follow the clues: that stray null, that off-by-one index, that one environment variable you misspelled three hours ago.

It’s a game of mental hide-and-seek. And yeah, sometimes it’s brutal. But solving it? Electric.

You find that one missing semicolon, refresh the browser, and suddenly—it works. And it feels like magic.

The Myth of "Just Build Stuff"

You hear this a lot: “Don’t overthink it—just build stuff!”

That’s great advice. But also kind of misleading.

Because building stuff implies that you know what you’re building and how it’ll all come together. More often, you’re cobbling together half-baked tutorials, React components you don’t fully understand, and a mess of config files from some Medium article written in 2019.

What they really mean is:

Just struggle through making stuff.

And learn to be okay with feeling like a mess for a while.

Building is how you discover what you don’t know. That’s when it starts to click—not when you're comfortable, but when you're completely confused and keep going anyway.

Meet the Emotional Dev Stack

We talk a lot about tech stacks: MERN, LAMP, JAMStack, whatever.

But there's a stack nobody talks about, and it's the one that actually carries you through:

Frustration.js – Because 90% of the time, something isn’t working and you’re not sure why.
Persistence.css – You’ll need to style your attitude with a heavy dose of “try again.”
CuriosityAPI – A healthy hunger for “what does this thing actually do?”
HumilityDB – Because you will be wrong. A lot. Document it, learn from it.
CommunityAuth – You will need people. Don’t gatekeep yourself.

This emotional stack is the real foundation. Without it, no amount of frameworks or syntax tricks will matter. With it, you’ll keep growing even when it feels like you’re stuck.

You’ll Never Really “Arrive”—And That’s Weirdly Beautiful

One of the weirdest things about learning to code is that there’s no actual finish line.

Even senior devs Google stuff daily.

Even people working at Stripe, GitHub, or Vercel break things regularly.

The difference is, they’ve built a tolerance for the chaos.

So if you’re waiting for that moment when you feel like a “real developer”?

Spoiler alert: you might already be one.

The fact that you’re struggling, questioning, fixing, building—that is the job.

It’s not about knowing everything. It’s about staying curious, humble, and a little stubborn.

Real Talk: You’re Gonna Suck… And Then Be Awesome

It’s honestly kind of wild how bad you’ll be at first.

That’s not an insult—it’s just math.

Nobody builds perfect things from day one. That landing page? Clunky. That JavaScript logic? Leaky. That database schema? Probably cursed.

But eventually, it all starts feeling less hard. You start recognizing patterns. You build mental models. You start to see the matrix, even if it’s glitchy.

Then—something weird happens.

You help someone else.

You explain a concept.

You clean up your old code and actually feel proud.

That’s the quiet arrival. The one nobody announces. But it’s real.

So What’s the One Thing?

If you’ve read this far, maybe you’ve guessed it already:

Learning to code is more about managing your own doubt than mastering the tech.

You’ll get the syntax. The logic will come. You’ll memorize weird API names and start slinging regex like it’s no big deal.

But the real game?

It’s sticking with it when it’s ugly, confusing, or straight-up demoralizing.

Every dev you admire? They’ve felt exactly what you’re feeling.

They just didn’t stop.

Final Thought: Keep Breaking Stuff

Honestly, the best advice I can give?

Break stuff. A lot.

Mess up that repo. Push broken code. Forget semicolons. Try something totally wrong and see what happens.

Because that’s how it sticks.

You’re not failing. You’re collecting war stories.

And trust me—every good dev’s got a few.

So go ahead. Get frustrated. Ask the “dumb” question. Write terrible code.

Then write slightly less terrible code.

And one day, you’ll look back and think,

“Wow—I really didn’t know what I was doing.”

But you’ll smile. Because now you kinda do.

- Josh

Why Your Side Project Will Fail (And Why That’s Totally Fine)

Josh Lawson — Tue, 20 May 2025 06:38:39 +0000

So you’ve started a side project.

You bought the domain, spun up a repo, maybe even slapped together a landing page. You're pumped. This is it. The idea that's going to finally lift you out of your day job (which you only kind of hate) and into indie hacker stardom.

But here’s the uncomfortable truth:

It’s probably going to fail.

Not because you’re lazy. Not because your code is trash. And definitely not because you lack vision.

It’s just... how this works.

Let me explain.

The Statistics Suck. But That’s Not the Point.

The numbers? They’re brutal. Something like 90% of side projects go nowhere. They fizzle out in silence—one dusty commit at a time.

But if you’ve been around devs, you already know this. You've seen dozens of "Coming Soon" pages that never... well, came.

And yet, people still start new projects. They still stay up till 2 a.m. fiddling with Next.js animations or writing API docs no one will ever read. Why?

Because even if your project fails, you win.

We’ll get to that. First, let’s talk about why these things fall apart.

The Motivation Mirage

The first week? You're unstoppable. You're sketching wireframes during lunch breaks and tweaking typography at red lights. (Don't do that.)

But then, something shifts. Your enthusiasm turns into obligation. The dopamine rush dries up. You hit something mundane—billing logic or GDPR compliance—and suddenly, Netflix looks really inviting.

Motivation is like a sugar high. It hits fast, feels amazing, and then drops you on your face.

Sustainable side projects aren’t built on motivation. They’re built on something far grittier: habit, purpose, and occasionally, pure spite.

Too Many Hats, Not Enough Heads

Building a side project is like running a tiny, underfunded, chaotic startup—except you’re the CEO, CTO, CMO, and the intern. You’re doing:

Frontend and backend
Copywriting (which you swear you’re terrible at)
DevOps you barely understand
And somehow, customer support for that one guy in Bulgaria who emailed you at 3 a.m.

Unless you’re a polymath or sleep four hours a night (and I don't recommend it), you’re going to drop balls. And guess what? That’s completely normal.

The truth? Most developers underestimate how much non-coding work is involved. And when the actual building stops being fun, the whole thing screeches to a halt.

Shiny Object Syndrome Is Real

There’s always another idea.

You're deep in a project—weeks of code written, issues logged, a semi-functional MVP online—and then someone on Hacker News posts a cool new library. Or you wake up with a “better” idea. Cleaner. Simpler. Faster to ship.

Suddenly, your current project feels clunky. Messy. Boring.

So you start something new. Again.

And again.

Until your GitHub is littered with half-built empires, each one abandoned at the exact moment it stopped being fun.

Side note: this doesn't make you flaky. It just means you're creative. But eventually, you’ll have to choose whether you’re chasing novelty or progress.

You’re Not Supposed to Know Everything

One reason side projects stall? You hit something you don’t know how to do.

OAuth integrations. Pricing models. Writing actual terms and conditions.

And instead of pushing through, you stop. Not because you’re incapable—but because it’s uncomfortable.

We’re all a bit allergic to discomfort. Especially devs who are used to feeling in control.

But here's the thing: you don't need to master everything. You just need to be okay with not knowing stuff and figuring it out anyway.

Now for the Good News

So yeah—your side project might flop. But let me flip this on its head.

That failure? It's not failure at all. It’s disguised progress.

Here’s why.

1. Every Project Levels You Up

Even if no one uses your app, you used it. You learned. You tried.

You maybe figured out how to connect Stripe without crying, or got your first taste of AWS Lambda. Or maybe you finally understood why everyone complains about CSS.

Each side project is like a gym session. Doesn’t matter if you win a competition—what matters is the reps.

Your 4th failed app is way better than your 1st failed app. And the 5th might just be the one that sticks.

2. You’re Building a Personal Stack

Not just tech-wise—although yeah, your stack probably evolved from jQuery to React to SvelteKit with a sprinkle of Tailwind somewhere in between.

I’m talking about your approach. Your decision-making. Your taste.

You learn what not to build. You stop overengineering. You start writing copy that doesn’t sound like it came from an AI with a thesaurus addiction.

In short: you get better at knowing what actually matters.

3. Momentum Beats Perfection

The people who eventually ship successful projects?

They’re the ones who keep moving.

Not because they’re smarter. Just because they don’t quit completely.

They take breaks, sure. They ghost projects sometimes. But they always come back swinging—new repo, new idea, slightly less bad typography.

And eventually, one of those projects sticks. Not because it was perfect. But because they just kept going.

4. The Community Sees You (Even If You Don’t Notice)

You might feel invisible. Like you’re shouting into the void on Twitter. But people notice.

Your consistency. Your ideas. Your willingness to build.

That stuff adds up.

I’ve seen devs land jobs, collaborators, podcast invites, and newsletter subs just because they kept posting about their side projects—even the janky ones.

So don’t wait for the “perfect” project to show up. Just show up yourself.

Okay, So… What Now?

Let’s say you’re in the messy middle of a dying project right now. What should you do?

Here’s a low-stress checklist:

Pause without quitting. Step away. Breathe. You’re allowed to rest.
Talk about it. Even the messy stuff. Especially the messy stuff.
Set a tiny goal. One bug fix. One tweet. One feature.
Get feedback. Not from randos—ask people who get it.
Remember your why. Reconnect with what made this project exciting before it got hard.

And if you decide to shelf it? That’s okay too. Just don’t burn out pretending to care.

You’re Not Wasting Your Time

Look—I know it feels like you’re stuck in a loop sometimes. Starting projects, abandoning them, questioning if you’ll ever finish something worth sharing.

But you are moving forward.

You’re collecting scars, stories, skills. Stuff that won’t show up in your GitHub green squares, but absolutely shows up in how you think, code, and create.

The people who “make it”? They’re not better than you. They just kept swinging. Through the boring parts. Through the rewrites. Through the failed launches.

So yeah—your side project might fail.

But it’s still worth building.

- Josh

5 VS Code Extensions You Didn’t Know You Needed

Josh Lawson — Thu, 15 May 2025 08:51:43 +0000

So you think you’ve tricked out your VS Code setup? Maybe you’ve got Prettier auto-formatting like a digital housekeeper, or GitLens telling you exactly who to side-eye for that broken line of code. Cool, cool. But here’s the thing—there are a few under-the-radar extensions that aren’t just nice to have. They’re low-key life-changing. You might not even know you’re missing them, until you try them.

This isn’t another laundry list of the usual suspects. No shade to ESLint and Live Server, but let’s get into the stuff that flies under the radar—like that indie band you pretend you discovered before they blew up.

Let’s talk about five VS Code extensions that just quietly make everything better.

1. Polacode – Because Screenshots Shouldn't Look Like Crime Scenes

You ever try to share a snippet of code in Slack and it looks like you took a blurry picture of your monitor using a toaster? Not exactly portfolio material.

Polacode fixes that. It turns your VS Code snippet into a gorgeous, Instagrammable Polaroid-style image. It respects your theme and fonts, and yeah—it’s silly. But you know what? It’s also weirdly satisfying. Great for tweeting elegant solutions or sharing something you're irrationally proud of (like finally fixing a CSS issue that's been haunting you for three days).

Use it once, and you'll catch yourself beautifying even the tiniest of code samples. It's like code scrapbooking. And don't act like you're above that.

2. Error Lens – Because Red Squiggles Are Just the Beginning

Let’s be real: VS Code’s default error handling is about as helpful as a shrug.

Error Lens doesn’t just underline your mistakes. It shouts them from the rooftops (but like, in a constructive way). Instead of vague red lines, you get inline messages that explain exactly what’s wrong—and where.

No more hovering like a nervous wreck over a cryptic error icon. The issue is right there in your face, bold and unapologetic. If you've ever spent 20 minutes squinting at an unresolved import or a forgotten semicolon, Error Lens feels like having a very patient, very blunt friend sitting beside you.

Also? It's oddly calming to just know.

3. Peacock – Because Sometimes Context is Everything

Raise your hand if you’ve ever opened five VS Code windows and edited the wrong one. Yeah, me too. You think you're saving changes to your test environment, but nope—production is crying now.

Peacock lets you tint your VS Code workspace so you can instantly tell them apart. Maybe green for dev, red for prod (high-stakes vibe), and blue for that pet project you poke at during lunch breaks.

It’s simple. Almost too simple. But it solves a problem that costs people real hours—and possibly their last nerve. You don’t realize how much mental load you're carrying until Peacock quietly takes that weight off.

And hey, it feels kinda luxurious. Like putting your code editor in a tailored outfit.

4. CodeSnap – Sharing Code Never Looked This Good

Yeah, technically I already mentioned Polacode. But hear me out—CodeSnap deserves its own shoutout.

Why? Because it's the slightly more practical sibling. While Polacode is all about aesthetic vibes, CodeSnap keeps it clean and functional. It creates beautiful images of your code with zero fuss, and you can tweak padding, background, and theme support.

Honestly, the choice between the two depends on your mood. Want drama? Go Polacode. Want clarity? CodeSnap’s your move.

It’s also sneakily good for documentation and internal wikis. People do read those, by the way—especially when they don’t look like ransom notes.

5. TODO Highlight – Because Memory is a Lie

You know that thing where you leave a // TODO: Refactor this before Friday and then completely forget? It’s fine, we’ve all been there. Deadlines come and go, and suddenly your TODOs are like ghosts haunting your codebase.

TODO Highlight makes them pop out—literally. It adds visual flair (think neon highlighter) to your TODO, FIXME, and whatever other custom tags you like to use when future-you needs a reminder.

You’ll spot them instantly when you scroll through your files. It’s like putting sticky notes in your code—except you can’t lose them under a coffee mug.

Bonus tip: combine it with the “Bookmarks” extension and start navigating like a time traveler with a perfect memory. Because let’s face it, your brain deserves a break.

Final Thoughts: It’s Not About Bells and Whistles, It’s About Flow

The best extensions don’t add flash—they remove friction.

VS Code already does a ton. But these lesser-known tools quietly smooth out the edges of your workflow. They make code feel a bit more human, a bit more yours.

And isn’t that the point? You’re not just building apps or APIs—you’re crafting something. Sometimes, the right tool can turn a frustrating hour into a focused sprint. Sometimes, it’s the thing that helps you stay in flow, just a little longer.

So maybe try one. Or all five. Worst case? You uninstall it. Best case? You wonder how you ever wrote code without it.

And hey, if you’ve got a weird, wonderful extension that you swear by, don’t gatekeep—spread the word. The VS Code rabbit hole is deep, and honestly, that’s half the fun.

- Josh

P.S. None of these are sponsored. Just sharing the love, one extension at a time.

A Beginner's Guide to Docker

Josh Lawson — Wed, 14 May 2025 14:01:00 +0000

If you’ve ever yelled at your computer because “it worked on my machine,” hey, welcome. You’re not alone. Every developer, from the bright-eyed intern to the CTO juggling a dozen microservices, has run headfirst into environment hell. And that’s where Docker walks in like the calm friend who actually knows how to fix things, not just complain about them.

But what is Docker, really? Why is everyone talking about containers like we’ve all suddenly become digital lunch packers? And most importantly—how do you use it without spiralling into config-file-induced madness?

Pull up a chair. We’re breaking Docker down piece by piece, without sounding like a DevOps textbook had a nervous breakdown.

So… What Exactly Is Docker?

Let’s start with a simple one-liner: Docker is a tool that lets you package up your application along with everything it needs to run—dependencies, system tools, settings—into something called a container.

Think of a container like a shipping container. It doesn’t care what’s inside—Python app, Node project, a tiny Go binary that could take over the world—it wraps it all up neatly, so you can ship it anywhere without worrying about what’s on the other side.

No more “works on my machine” drama. No more weird bugs because someone had an older version of libxml installed. With Docker, you get consistency, plain and simple.

Containers vs. Virtual Machines: What's the Difference?

Quick detour here—because folks get this part tangled up all the time.

Containers aren’t VMs. They're lighter, faster, and don’t come with all the baggage. Imagine a virtual machine like renting a whole apartment just to boil some pasta. You’ve got your own walls, plumbing, kitchen—even if you’re just using a single burner.

Now, a container? That’s like sharing a kitchen in a co-working space. Everyone brings their own pan, their own spices, and just cooks their stuff—without needing an entire building.

Docker uses the host machine’s kernel but isolates everything else. That makes containers super fast to start and way less resource-hungry.

Installing Docker (Without the Tears)

Let’s keep this part short because installing Docker shouldn’t be an ordeal—and thankfully, it isn’t.

Mac & Windows

You’ll want Docker Desktop. Head to https://www.docker.com/products/docker-desktop, download the version for your OS, and follow the installer. It’s GUI-based, so even if you’re allergic to the terminal, you’ll survive.

Linux

You’ve got a few options depending on your distro, but for most Ubuntu folks:

sudo apt update
sudo apt install docker.io
sudo systemctl start docker
sudo systemctl enable docker

And don’t forget to add yourself to the Docker group if you don’t want to use sudo every time:

sudo usermod -aG docker $USER

Log out and back in—then you’re good to go.

Let’s Build Your First Container (You Got This)

Okay, let’s say you’ve got a small Python script—maybe a Flask app or something that just says "Hello, Docker!"

Here’s the thing: You can run that inside a container without installing Python on your host. That’s the magic.

1. Your App

Create a file called app.py:

print("Hello from inside the container!")

2. Your Dockerfile

Now, create a Dockerfile (no extension) in the same directory:

FROM python:3.13
COPY app.py .
CMD ["python", "app.py"]

This tells Docker:

Use the official Python 3.13 image
Copy your script into the container
Run it with Python

3. Build the Image

From your terminal:

docker build -t hello-docker .

This packages everything into an image named hello-docker.

4. Run It!

docker run hello-docker

And boom. You should see:

Hello from inside the container!

That’s it. No Python installed locally. No setup scripts. Just your app, running clean.

The Docker Commands You’ll Actually Use

Docker has a bunch of commands—but you only need a few to get rolling.

docker build -t <name> . — Build an image from your Dockerfile
docker run <name> — Start a container
docker ps — Show running containers
docker stop <container_id> — Stop one
docker images — List all images
docker rmi <image_id> — Remove an image
docker exec -it <container_id> bash — Jump inside a container (like SSH)

You’ll pick up more as you go, but these are your bread and butter.

Real Talk: Why Bother With Docker?

You know what? Let’s pause here. Because this isn’t just about tools—it’s about sanity.

Docker saves you from:

The “it works for me” nightmare
Dependency hell (pip vs conda vs NPM vs...whatever Rust is doing)
Slow onboarding (give a new hire one command and they’re good)
Weird bugs that show up only in production

It also lets you simulate production environments, test your app in different setups, and—if you’re building for the cloud—Docker is practically a requirement. Kubernetes? CI/CD? Cloud functions? They all play nice with containers.

But Wait—Where Do Images Live?

Just like code lives on GitHub, Docker images often live on Docker Hub (or private registries like GitHub Container Registry, Amazon ECR, etc.)

Once you’ve built an image, you can push it like this:

docker tag hello-docker yourusername/hello-docker
docker push yourusername/hello-docker

Boom—it’s now sharable, portable, and versioned like the rest of your stack.

A Few Gotchas (Because Nothing’s Perfect)

Okay, before we wrap, some friendly heads-ups:

Volumes — Containers are ephemeral. If you need persistent data (like database files), you’ll want to mount volumes.
Networking — Containers are isolated. If you’ve got multiple services talking to each other, you’ll need to configure Docker networks.
Image Size — Some base images are huge. Look for -slim versions or consider Alpine Linux for tiny builds.
Build Context — Be careful with what you copy into your container. Don’t accidentally ship your .env or node_modules.

None of these are dealbreakers—they're just the kind of stuff that bites when you’re not looking.

Final Thoughts (And a Bit of Tough Love)

Look—Docker isn’t magic. It won’t fix bad code, poor planning, or your coffee addiction.

But it will make your life a lot easier. It’s one of those tools that—once you’ve used it a few times—feels like cheating. You package your app, run it anywhere, and move on with your life. Clean. Consistent. Done.

And sure, you’ll hit snags. Everyone does. But with a bit of tinkering and curiosity, Docker becomes second nature. Like git—but less terrifying (most of the time).

So go ahead—containerize something small. Doesn’t matter what. A Flask app. A static site. Even a Node script that tells jokes. Just build it, run it, and see what happens.

You’ll be surprised how much smoother everything starts to feel.

Next up? Maybe orchestrating containers with Docker Compose. Or playing with Kubernetes. But for now—breathe. You’ve made it this far. And honestly? That’s already something to be proud of.

- Josh

My Developer Stack in 2025: Fast, Fluid, and Frustratingly Fun

Josh Lawson — Wed, 14 May 2025 07:27:41 +0000

You ever stare at your codebase and think, “Okay, this feels kinda… good?” Not perfect—never perfect—but there’s something oddly satisfying about seeing your stack come together. That’s been my 2025 vibe. I’ve dialled in a setup that’s fast, clean, expressive, and, most importantly, doesn’t make me want to scream into a pillow at 2 a.m.

Let me break it down for you.

The Frontend: Where I Spend Way Too Much Time

Okay, so frontend first. And yes, I know, backend folks are already rolling their eyes. But let’s be honest—we all judge apps by their UI before we even poke around the API.

These days, I’m building almost everything with:

Next.js
Shadcn/ui
TailwindCSS

This trio has become my comfort zone, like a hoodie that actually fits right. Let’s unpack why.

Next.js: Not Just a React Wrapper Anymore

Back when I first touched Next, it felt like React’s responsible older sibling—structured, opinionated, and maybe a little too into static generation. But 2025 Next? It’s evolved. I mean, with App Router, Server Actions, and built-in caching strategies, it’s the first time I’ve seen React apps behave like they belong in production by default.

Plus, the DX (developer experience) is smoother than ever. Hot reloads don’t flake out like they used to. File-based routing still feels magical. And layouts finally make sense.

TailwindCSS: Utility-First, Brain-Later

I’ll admit—I fought Tailwind at first. Something about adding px-4 py-2 to my button elements felt… wrong. Like I was breaking some kind of sacred separation-of-concerns law.

But now? Now I get it.

It’s fast. It’s readable. And with Just-in-Time mode, it’s blazing. No more custom classes unless I absolutely need them. It’s become muscle memory.

Also, if you haven’t paired Tailwind with Shadcn/ui yet, you’re sleeping.

Shadcn/ui: Design System without the Handcuffs

I used to dread building accessible, decent-looking components. Then I met Shadcn/ui. It’s not a library so much as a toolbox that lets you build your UI—just with smarter defaults.

Want to tweak that modal? Cool, it’s just code. No need to hack around somebody else’s abstraction. Shadcn lets you keep ownership of your components without starting from scratch.

Supabase: My Backend Ride-or-Die

Look, I’m not saying Supabase is perfect. But in 2025? It’s the closest thing I’ve found to a backend that “just works” without feeling like you sold your soul to a black-box platform.

It gives me:

Postgres without the setup drama
Realtime subscriptions that don’t randomly break (much)
Row-level security that actually makes sense
Storage for user uploads that doesn’t make me cry

But the real kicker? Auth.

Supabase Auth: It’s Not a Headache Anymore

You know what? For years, I dreaded building auth flows. Social login was finicky, email/password flows were security nightmares, and don’t even get me started on magic links.

Supabase Auth fixed a lot of that. Built-in email/password? Check. OTPs and third-party providers? Yep. Session persistence? Actually reliable.

The email templates still need a little love (okay, a lot), but the rest of the flow is straightforward. Also, RLS + Auth integration means I don’t have to build custom guards everywhere. Just define my policies in SQL, and boom—my data protects itself.

A Few Other Tools I Can’t Shut Up About

Alright, so here’s the part where I sneak in some extras. Because yeah, frontend/backend/auth is the meat—but the garnish matters too.

Zod for schema validation. Catching bugs before they hit the DB is a small joy I treasure.
tRPC (yep, still alive and kicking) for typesafe APIs between my frontend and backend.
Vercel for deployments. It’s still magical—even when it breaks stuff. (Looking at you, edge functions.)

I’ve also been leaning into GitHub Copilot more than I’d like to admit. It’s like pair programming with a semi-reliable ghost. Not perfect, but it gets me through boilerplate way faster.

Stuff I’ve Dropped (and Why I Don’t Miss It)

Let’s be real. You don’t fall in love with your stack without going through a few breakups. Here’s what I’ve cut loose:

Firebase — The vendor lock-in felt suffocating.
Redux — Honestly, I haven’t touched it in years. Zustand and context do more than enough.
Custom UI kits — Shadcn ruined me. I’m not going back.

Sometimes letting go is the best upgrade.

So... Why This Stack?

It’s not flashy. It’s not trendy. But it’s mine.

Every piece pulls its weight. Nothing feels overengineered or duct-taped together. And I can build apps—real ones—in hours, not weeks. That’s the real win, right?

I’ve had fewer meetings with myself about infrastructure and more actual building time. Which, ironically, means more time for debugging obscure edge cases and naming things badly—but I’ll take it.

- Josh

One Last Thought (Because You’re Still Here)

If you’re still reading this, thanks. Seriously. Writing about your stack is weirdly intimate. It’s like showing someone your desk—messy cables, half-finished Post-it notes, and all.

But the point isn’t perfection. It’s momentum. It’s progress. It’s building stuff that works—and maybe even feels good to use.

So, if you’re assembling your stack for 2025, don’t chase trends. (That feels contradictory now that I've written it.) Find the tools that feel like extensions of your hands. And when you do, don’t look back.

Now excuse me while I push to production and pray nothing explodes.

Why your Tech Stack shouldn't change.

Josh Lawson — Sat, 27 Jul 2024 04:05:38 +0000

Technology is constantly changing. It honestly feels like there is a new JavaScript framework popping up EVERY SINGLE MONTH. But JavaScript frameworks aside, a key part of shipping SaaS faster is writing code faster.

When I first learned to code, I was overwhelmed by the amount of languages I could choose from. Like thousands of others, I went down the rabbit hole of YouTube, trying to find the best programming language to learn. Fast forward a few years or so, and I've refined my Web Development tech stack into something so efficient that I can ship in under a week.

This is the tech stack I'm using to develop Cli.ck

Front-end

My entire tech stack is javaScript oriented.

I use Next.js, Tailwind, and DaisyUI.

DaisyUI is an awesome tailwind component library I use to speed up development. It's got every single component under the sun, and comes with its own beautiful styling and 20+ colour themes.

I've heard shadcn/ui is great, but haven't tried it yet.

Back-end

All my back-end computation is handled by Serverless Functions. Next.js handles these really well, and it makes life 100x easier than writing API routes for everything.

For storage I use Vercel's integrated PostgreSQL database. You get a free one with their hobby plan so I would highly suggest checking it out.

I also use Prisma as my database ORM because I hate writing raw SQL.

Hosting + Extras

All my websites are hosted with Vercel. The same people who made Next.js also made Vercel, so it integrates nicely with my current stack. This is the main reason I use Vercel's PostgreSQL databases.

I use Auth.js for user authentication and user management, and Lemon Squeezy for payments.

All my emails are handled through Resend.

Tech stacks don't matter. What matters is how you use it. NASA sent men to the moon with a calculator (ok, not quite, but a computer with the same computational power), so it doesn't matter what languages/tools are in your tech stack.

- Josh

P.S: I'm currently developing my own SaaS, Cli.ck, aimed at making click tracks easier for small bands to use. If you're interested in that, or just want to follow my journey, sign up for the waitlist here. I'll be updating you about the behind-the-scenes of the development process.

Do people want your SaaS?

Josh Lawson — Wed, 10 Jul 2024 10:04:28 +0000

So you've found your next SaaS idea: a platform that translates cat meows into Shakespearean sonnets. You're confident it will make millions and be the next biggest app of the year. You then go on to get 5 customers and lose hundreds of dollars on a product that flopped. The issue: no one wanted your SaaS. It's one thing to find an idea, but it's another thing to find a good one.

The key to good ideas: Validation

Let's face it. Good startup ideas come once in a blue moon. Everyone these days seems to think they've got the next great idea that will bring them $100k/month so they can quit their day job and go live in Bali. Spoiler alert, it won't. But for those of you nieve enough to continue down the startup rabbit hole, validating your idea could just be the single biggest factor determining if your startup flops or flies.

According to [Harvard Business School (https://online.hbs.edu/blog/post/market-validation), market validation is the process of determining if there’s a need for your product in your target market. Why is this important? Because even the best ideas are meaningless unless you can have customers at scale that pay for your startup.

Without proper validation, you'll spend months or even years developing your MVP, only to find that no one wants it and you've wasted countless hours and dollars. That's why it is essential that you don't make the mistake that just because you think your idea is good, it doesn't mean that others share the same view.

Here are the 2 things I always consider before starting a SaaS startup:

1. Does it solve a Pain Point?

The number 1 rule to remember is that money is an exchange of value. Without getting into the specifics of it here, if someone doesn't see the value in your product, they aren't going to hand over any money. And the best way to ensure customers see the value in your product is for it to solve a pain point.

Consider a habit tracker app and a ride-sharing service like Uber or Lyft. The habit tracker targets individuals who want to break bad habits, while the ride-sharing service appeals to anyone needing transportation from point A to point B without a car. Now, imagine launching both products simultaneously with identical marketing strategies. I can confidently predict that the ride-sharing app would outperform the habit tracker by a significant margin.

Why? Because the habit tracker is like a vitamin—it’s beneficial but not essential. In contrast, the ride-sharing app is like a painkiller—it addresses an urgent need. As Mark Lou’s analogy suggests, you want to focus on ideas that solve unmet customer needs, not just create something that’s ‘nice to have’.

2. Would you (Really) use it?

I'm a drummer. That's why I'm developing Cli.ck, a click track creation tool for small bands. I created Cli.ck because I'd use it. The advantage of this is that I know what others would want from it because I am my target market. It would make no sense for me to go and build an AI flower identification tool because, frankly, I hate gardening. I would never use my app and would have no idea what others want from it.

How to validate your idea

Ok, now you've established if your idea is a good one in theory, it's time to see if others agree with you. The easiest way to do this is to set up a waitlist. Create a simple landing page that explains your product and its benefits, and include a form for interested users to sign up for updates. Promote this page through social media, forums, and other channels where your target audience hangs out.

Collecting emails from potential users not only validates interest but also builds a list of early adopters who can provide valuable feedback and help spread the word about your product.

I launched my waitlist for Cli.ck only 3 days ago, and already have over 30 people on the waitlist. And while this number doesn't sound massive, 30 customers paying $15/month is over $450/month or $5400/year, and while that isn't enough to quit your job for, it's starting revenue that you can use to promote your SaaS further.

There is no such thing as a perfect idea. All ideas are born ugly, and some stay that way. The only real way to know is to launch your idea and find out, but idea validation is a good way to minimize the risk. So, before you dive headfirst into development, take the time to validate your idea. Conduct surveys, create landing pages, engage with potential customers, and most importantly, listen to their feedback.

Validating your startup idea is not just a step; it’s a continuous process. Keep refining your concept based on the feedback and market needs. This approach not only saves you time and resources but also increases the chances of your startup succeeding.

So, before you write a single line of code, remember: validate, validate, validate.

- Josh

P.S: I'm currently developing my own SaaS, Cli.ck, aimed at making click tracks easier for small bands to use. If you're interested in that, or just want to follow my journey, sign up for the waitlist here. I'll be updating weekly about the behind-the-scenes of the development process.

You're starting SaaS startups wrong

Josh Lawson — Sun, 07 Jul 2024 03:15:04 +0000

Launching your first SaaS is always rewarding, although it isn't always easy. More often than not, your first few (or many) startups will fail or never get off the ground like you hoped. Sometimes this is because your idea is holding you back, but sometimes it is because you missed a few key steps when launching your SaaS. Today, I'll cover some of the things I've learned while launching my first SaaS startup, Cli.ck.

Step 1: Find an Idea

I've covered this in my last post (Go check it out after this), but to summarise, your SaaS needs to provide value. Every successful SaaS starts with a problem that needs solving. Look around your industry or personal life and identify a gap technology can fill. Maybe you’ve noticed a cumbersome process at work or a task that could be streamlined. Once you’ve pinpointed the problem, you’re already on your way.

Step 2: Validate your idea

There's nothing worse than spending 3 months on a project only to realise no one wants it and you've wasted your time. So before developing your MVP, which I'll cover in step 4, make sure there's a demand for your SaaS. Talk to potential customers, mention it on related forums, and post about your idea on social media channels. Once you're getting enough positive responses, you're good to begin development

Step 3: Plan your product

Sketch out what your product will do and how it will work. Focus on the core features that address the problem you identified. Remember, it’s better to start small and expand later. Create wireframes or mockups to visualize your product. Keep it simple and user-friendly.

Additionally, decide on a tech stack. While there will always be the next best product or web framework, choose something that works for you and stick with it. This will make development easier in the long run. Here's the tech stack I currently use for developing Cli.ck:

Front-end: Next.js with TailwindCSS and DaisyUI
Back-end: Node.js
Emails: Resend
Database: Supabase
Payments: Stripe
Hosting: Vercel

Step 4: Develop your MVP

Build a Minimum Viable Product (MVP) – a basic version of your product with just enough features to solve the problem and attract early adopters. This version allows you to test your concept without investing too much time and money. Use agile development to iterate quickly based on user feedback.

The biggest tip I can give here is to utilise Generative AI during your development. ChatGPT or GitHub Copilot are much better and quicker at debugging issues than your average developer, so use them to your advantage.

Step 5: Build a Waitlist

This should really be step 4.5 (although it also fits in step 2). Build a simple waitlist to collect emails from potential customers. It can be as simple as a one-page website with a simple header and a call-to-action with an email field, but all it needs to do is build your initial customer base. Use something like Resend to handle email collection, and optionally send weekly development updates to engage your audience.

If you want an example, check out the Cli.ck waitlist I built here

Step 6: Launch! (Kinda...)

Once your MVP is ready, launch it to a select group of users. Ideally, this is the group you collected from your waitlist, although it doesn't have to be. Gather their feedback and use it to improve your product. Don’t be afraid to make changes. Iteration is key in the SaaS world. The goal is to refine your product until it meets your users' needs perfectly.

Step 7: Actually Launch

Now you've ironed out any creases and bugs in your beta version, it's time to release it to the public. Market like crazy on every possible social media platform and related forum, and possibly paid ads. Turn the customer emails on your waitlist into the start of your newsletter, and pump out weekly emails. The key here is to be consistent.

Bonus Tip: Keep Learning

The tech landscape is always evolving, and so should you. Stay updated with the latest trends, tools, and best practices. Engage with the SaaS community, attend webinars, and read industry blogs. Continuous learning will keep you ahead of the curve.

Starting a SaaS business is a thrilling adventure filled with ups and downs. By following these steps, you'll be well on your way to creating a product that not only solves a real problem but also brings value to your users. So, roll up your sleeves, get started, and enjoy the journey!

- Josh

P.S.: I'm currently developing my own SaaS, Cli.ck, aimed at making click tracks easier for small bands to use. If you're interested in that, or just want to follow my journey, sign up for the waitlist here. I'll be updating weekly about the behind-the-scenes of the development process.

Why you won't find a SaaS idea

Josh Lawson — Wed, 26 Jun 2024 10:43:16 +0000

The other day, I sat down at my desk ready to complete my daily list of mundane tasks, when it hit me:

"Why aren't I working for myself?"

I mean, think about it. No boss telling you what to do, no deadlines, no annoying co-workers, sounds like a dream. You decide when you log on and off, you decide what you work on, and you set your deadlines.

What is a SaaS Startup?

Naturally, I turned to SaaS, the latest hot topic in the world of software development. I'm sure most people know what it is, or at least have heard of it. Love it or not, it's one of the easiest ways to profit from programming, next to freelancing.

For those who have been living under a rock for the past couple of years, a SaaS Startup is a company that offers software as a service, paid for by end users usually in a subscription model. They're usually developed by individuals or small teams, giving them the potential for large revenue margins. They often focus on delivering a solution to a specific audience's issues, while building a loyal customer base simultaneously.

But I'll save the specifics of starting a SaaS Startup for another article. Instead, today I want to focus on the very first step for any SaaS Startup.

So what do I build?

You've decided to launch your own SaaS Startup, planning to build the next Instagram. So you open up your favourite code editor (Dark mode, hopefully) run npm create next app and...

"Wait, where do I start?"

We've all been there, motivated to begin programming, but then overwhelmed by the blank file. This is precisely the reason why it is crucial to know what you're going to build before you build it.

"But where do you find SaaS ideas? They don't just grow on trees, Josh". Correct! But the main issue with this question is it ignores the premise of a SaaS Startup. The market for startups is extremely oversaturated, so you need to make sure yours stands out. It can't just 'exist', it needs to solve something. The best startups succeed because they solve something most people experience, but are too lazy to solve.

The key to finding a SaaS idea is to look at other's pain. People are only going to pay for something that brings value to them, so you need to provide them with that value before they'll hand over their bank details.

Even if you don't find anything good, start creating something. Make a fun little game, write a blog post like this one, build a note-taking app. There will be issues along the way that you'll encounter, and boom, there's your SaaS Startup

Stop thinking, start doing.

- Josh

Forem: Josh Lawson

Stop Using `console.log` — These Debugging Tricks Will Blow Your Mind

But First… Why Do We Cling to console.log?

1. Set Breakpoints Like a Grown-Up (Seriously)

2. Watch Expressions (a.k.a. X-Ray Vision for Variables)

3. Conditional Breakpoints (a.k.a. “Only Stop When It’s Weird”)

Leverage the Power of debugger; (Yup, It’s a Real Keyword)

5. The Network Tab Is Your Best Friend

6. Step Through Code Like Sherlock Holmes

7. Use Logging Libraries (If You Must Log)

8. Embrace Time Travel Debugging (Yes, That’s a Thing)

10. Stop Blaming Yourself — Use Linters and Type Systems

Final Thought: Tools Don’t Make You Lazy — They Make You Smart

The One Thing Nobody Tells You About Learning to Code

The Setup: When Code Breaks You (and How That’s the Point)

Code Is Basically the Gym for Your Brain’s Ego

Let’s Talk About Shame (Briefly)

Debugging Yourself Is Part of the Job

The Myth of "Just Build Stuff"

Meet the Emotional Dev Stack

You’ll Never Really “Arrive”—And That’s Weirdly Beautiful

Real Talk: You’re Gonna Suck… And Then Be Awesome

So What’s the One Thing?

Final Thought: Keep Breaking Stuff

Why Your Side Project Will Fail (And Why That’s Totally Fine)

The Statistics Suck. But That’s Not the Point.

The Motivation Mirage

Too Many Hats, Not Enough Heads

Shiny Object Syndrome Is Real

You’re Not Supposed to Know Everything

Now for the Good News

1. Every Project Levels You Up

2. You’re Building a Personal Stack

3. Momentum Beats Perfection

4. The Community Sees You (Even If You Don’t Notice)

Okay, So… What Now?

You’re Not Wasting Your Time

5 VS Code Extensions You Didn’t Know You Needed

1. Polacode – Because Screenshots Shouldn't Look Like Crime Scenes

2. Error Lens – Because Red Squiggles Are Just the Beginning

3. Peacock – Because Sometimes Context is Everything

4. CodeSnap – Sharing Code Never Looked This Good

5. TODO Highlight – Because Memory is a Lie

Final Thoughts: It’s Not About Bells and Whistles, It’s About Flow

A Beginner's Guide to Docker

So… What Exactly Is Docker?

Containers vs. Virtual Machines: What's the Difference?

Installing Docker (Without the Tears)

Mac & Windows

Linux

Let’s Build Your First Container (You Got This)

1. Your App

2. Your Dockerfile

3. Build the Image

4. Run It!

The Docker Commands You’ll Actually Use

Real Talk: Why Bother With Docker?

But Wait—Where Do Images Live?

A Few Gotchas (Because Nothing’s Perfect)

Final Thoughts (And a Bit of Tough Love)

My Developer Stack in 2025: Fast, Fluid, and Frustratingly Fun

The Frontend: Where I Spend Way Too Much Time

Next.js: Not Just a React Wrapper Anymore

TailwindCSS: Utility-First, Brain-Later

Shadcn/ui: Design System without the Handcuffs

Supabase: My Backend Ride-or-Die

Supabase Auth: It’s Not a Headache Anymore

A Few Other Tools I Can’t Shut Up About

Stuff I’ve Dropped (and Why I Don’t Miss It)

So... Why This Stack?

One Last Thought (Because You’re Still Here)

Why your Tech Stack shouldn't change.

Front-end

Back-end

Hosting + Extras

Do people want your SaaS?

The key to good ideas: Validation

1. Does it solve a Pain Point?

2. Would you (Really) use it?

How to validate your idea

But First… Why Do We Cling to `console.log`?

Leverage the Power of `debugger;` (Yup, It’s a Real Keyword)