A Bit of SaaS Weekly: Time to be ambitious.

This is a weekly newsletter on the Software as a Service world. Learning, building, and shipping. Written by Ethan Mick.

So while some people know what they want to do at 14, most have to figure it out.

-- Paul Graham

For the record, I knew at 14. I fell in love with programming computers. I don't think I knew it would lead me here, though.

The Best Bits

• Seamless and efficient Docker and Linux on your Mac.
• Zed is a high-performance, multiplayer code editor.
• A SaaS for metrics, logging, and event tracking.
• H0w to do great work, by Paul Graham.

How to up your debugging game

As a software engineer, I think the most important skill is learning how to debug. And not just the "I put in some console.log()" statements; the deep dive and methodical working to figure out what's wrong.

So if debugging is so important, how can you get better?

Check the state

First, walk through the problem and make sure the state is what you expect. That is, for any value that changes, check it before and after it changes. This should let you find obvious bugs where the state is simply being manipulated into the wrong state.

Don't skip this step even if you think you know what the state is. This is the place where you start your sanity checks, and will find a lot of common problems. How many times have you forgotten to await a promise and the value you are dealing with is the Promise object itself, not the value?

Check the logic

If the state is correct (or not, and you know where to look), step through the logic. Make sure the app is doing what you think it's doing, at a high level. This might require some knowledge of the framework you're using and often requires looking up APIs or source code.

Most of the time, you can step through your logic easily.  You wrote it, after all. But when it comes to reviewing your teammate's code or an open-source project, you'll need to learn how to read code well and understand what it's doing. Often you'll learn what you thought the code was doing... it's just not.

Create the most simple reproduction possible

When all else fails, you might have a bug on your hand. The question is... is that bug in your code... or someone else's?

To master debugging, create the most simple reproduction possible. I mean simple.

As simple as possible.

No extra dependencies. No unnecessary CSS. As few lines of code as possible. Just get to the heart of the bug as quickly as you can.

This is great for two reasons.

1. If it is indeed a bug, you now have the perfect project to submit as a reproduction.
2. It's probably not a bug, and you'll discover what you did wrong when making the simple reproduction.

That being said, this weekend, I ran into two bugs that were actually bugs. When I built my simple reproduction, I was able to narrow down the exact cause of the bug and track down the GitHub issue that tracked it.

Follow these steps, and you're debugging skills will be unparalleled!

Learn to Build SaaS

With the US holiday, I only streamed on Thursday. It was a great session, though. We built out projects and updated the rest of the app to use clients and projects. We also built the rough admin section, opening the doors to building teams and billing. Tune in next week to see that happen!

Tech Tip

If you want to use pnpm as your package manager with GitHub actions, you can install it with the pnpm/actions-setup action.

jobs:
  install:
    runs-on: ubuntu-latest
    steps:
      - uses: pnpm/action-setup@v2
        with:
          version: 8.6.2

Go forth and code!

Cloud Chronicles

• YouTube Subscribers: 1,586 (+71 in the last 7 days)
• Newsletter Members: 353 (+21 in the last 7 days)

Weekly Update: v2023.7.05

Last week I changed my content strategy to focus on streaming. And I think it worked! Well, at the very least, it got me to sit down and create content for long periods of time. Is that content worth the same? To be determined. But there’s a lot to like.

Build SaaS with EthanEthan Mick

This was a short week with a holiday on Tuesday; I was out of town, and so didn't have a stream. I did a stream on Thursday where we made a lot more progress on the SaaS app. There were also some great chats happening, which made the entire thing a lot of fun.

Instead of cutting content straight from the stream, I think I'll retake the content with the code I already wrote. This will make it more streamlined, and I don't need to cut out interruptions. Not sure I'll get something done tomorrow, but I'll try to make it happen next week!

Last Byte

• Style your RSS feed.
• PhD Simulator.
• GitHub achievements that did not make the cut.