TL;DR: I explain my process of creating the graphical style and illustrations for GitByBit. There's a timelapse video at the end.

---

People keep asking me which AI model I use for creating GitByBit illustrations. These questions are somewhat infuriating amusing, considering that I create most, if not all, art with my sloppy hands. So I decided to write a bit about my illustration process and tools.

I'm not a pro artist. I am and always was a developer at heart. And like most developers, I thought that I couldn't draw at all. Frankly, when I look at many of my paper sketches, I still don't understand how that can turn into something decent if only you spend some time developing it further.

I deeply believe basic drawing/designing skills are SUPER useful to a software/web developer, especially if you plan on creating projects of your own. They let you express your ideas visually and make your products stand out.

I would argue that for many people who are looking for a dev job during these weird times, spending a month or two learning basic design skills is a much better investment than grinding through endless LeetCode problems (but not learning more Git, ha-ha). That's something that can make you stand out from the crowd and help you get noticed. That's something you can use in your own projects. That's something you can pivot to if you ever get tired of coding. And maybe like it was for me, that's something you discover you enjoy doing.

Why illustrations?

When your job is educating a human, illustrations are your best friends.

• A picture can explain some stuff better than a page of text.
• A clever visual metaphor can drill an abstract concept into your memory like nothing else.
• A comic strip can provide some mental relief when you’re digging through tough, boring material.

The logo

I try to think about the overall graphic style of a new project from day one. It’s important to decide on the tone early, because you’ll end up with a more consistent style and content at the finish line.

When I started working on GitByBit, I knew I needed an adorable mascot for the project. I friggin' love mascots. In fact, everyone loves them. A lot of people know me solely as that guy with the raccoon website, referring to Refactoring.Guru.

But I didn't have the slightest idea what kind of mascot would fit this particular project. A creature always associated with Git was the octopus. And while octopuses are fascinating creatures, it's pretty hard to draw an adorable octopus. I tried for a while, but then abandoned this approach.

It was only a few weeks into the project, and in parallel, I was working on the first draft of the content. The git init chapter had this little joke about a cat sleeping on keyboards, while you were away.

That’s when I had a revelation: cats are perfect! They are cute, they are funny, and they are known for their love of keyboards. Plus, there’s a long-standing stereotype about programmers being cat lovers, a team of programmers being a cat herd, and so on. This whole project being remembered as "git with cats" would be just perfect. It all clicked together nicely.

So, this is how the first version of the project logo was created.

This was enough for a start, but I didn't have clear plans for the rest of the illustrations yet. At that point, I wasn't even sure that the whole project would take off. So I decided to focus on the core content first and worry about the rest later.

The visual style

Another breakthrough happened way later, almost a year into the project, in December 2024. By that time, the first version of the content was almost ready, so it felt that creating some graphics was overdue. I still didn't have any clue about the overall visual style. Worse yet, after a year of working on the content, I was burned out creatively and the whole cats thing felt a bit stale.

Nevertheless, during the Christmas break, I tried some rough ideas, which eventually led to the illustrations that can now be seen at the start of the course, the whole I messed up my project story (which is based on real events, btw).

After converting to vector and adding some basic interactivity on top, I ended up with the complete set of illustrations for the first chapter, which is very similar to what you can see in the course now.

Cats everywhere

After finishing some more illustrations in the same style, I had a "this is it" moment. This style is playful, cute, and a bit silly, which is exactly what I wanted. It also fits the overall tone of the project perfectly. But there were no cats, which was a bummer. At some point, in frustration, I sketched a cat head over one of the existing illustrations and found it was EXACTLY the look and feel I was looking for from the very beginning.

It's frustrating having to backtrack and change all the completed illustrations, but it's part of making a good consistent result, and I think it all ended up looking amazing. People seem to love it too.

The process

Here's the timelapse of me producing the Staging area illustration: 5 hours of real time in 5 minutes.

* * *

I hope you've found this little peek into my illustration process entertaining. If you have any questions or want to share your own experiences with creating illustrations, feel free to drop me a line at support@gitbybit.com.

I'm yet to announce this properly in the next post, but GitByBit has left the Early Access last week and (finally) became a proper product. The main course remains free, but the focused practices are now part of the paid addon, the GitByBit PRO.

If you'd like to support my further work, consider purchasing a copy for yourself or someone you love. The PRO version is a one-time payment and it's priced fairly. You can even enjoy a neat Christmas holidays discount during the next few weeks.

Learn more about PROLearn more...

TL;DR: I've added a new focused practice to GitByBit that teaches merging, rebasing, and resolving conflicts. You can access it in the latest version of GitByBit for VS Code.

---

Have you ever merged a branch and been greeted by a wall of conflict markers? Or pulled changes from a remote repository only to find that your local changes are at odds with the incoming ones? This is one of the most frustrating aspects of using Git, especially for beginners.

For that reason, I've added a new focused practice to GitByBit called "Merging, rebasing, and resolving conflicts." In this practice, you will:

• Learn what the fuss is about merging versus rebasing, and when to use each.
• Explore when Git performs a fast-forward merge versus creating a merge commit—and why that distinction matters.
• Rehearse rebasing and merging on real-world branches without touching production repositories.
• Learn how to choose the right integration strategy for your project and team norms.

Conflicts are part of collaborative work, so the practice leans into them. You will see how conflicts arise, learn to spot the important bits in the conflict markers, and resolve them using both the terminal and a graphical interface.

Finally, the practice will guide you through a common failed push scenario. You step into the shoes of an experienced Git user helping a teammate push their changes to a remote repository while navigating cryptic errors and merge conflicts.

You can access the new merging and rebasing practice right away in the latest version of GitByBit for VS Code.

TL;DR: I lost several weeks' worth of new users due to a random bug in the new version of VS Code. Lesson: implement real time error monitoring early, if you can.

---

Developing a solo project is hard. You have to wear many hats: developer, designer, marketer, support, and more. You have to juggle multiple tasks and priorities, and sometimes things slip through the cracks.

The first week of July, a random update to VS Code changed the internal authentication system, causing the existing versions of GitByBit to go into an infinite loop right at the start. Basically, none of the users could use the course, until this issue was addressed. Oblivious to the issue, I was working on the upcoming Pull Request practice (which is super cool and was released last week, btw).

At some point, someone finally reported the issue on GitHub, so I was able to fix it and release a new version. But I pretty much lost several weeks' worth of new users, because they were not able to use the course.

Most of my other projects are normal web apps, served from my own server. Built with popular frameworks like Laravel or React, you could easily integrate the app with some real time error reporting system, like Sentry or Rollbar. So, once an error happens, I get notified immediately and then can upload the fix to my server and all the users will get the fix right away. Debugging the problem is also easier, because I have access to the server logs and can see what exactly went wrong.

However, GitByBit is not your normal web app. There's a VS Code extension and the web version, each having separate front and back ends. All of these are built with different technologies, so error reporting is not as easy as putting a Rollbar API key somewhere in the config. So far, I had all these places sending telemetry back to my main server, where it's stored in one centralized log.

But alas, there was no monitoring system in place to alert me about errors in real time. So, I had to open and read this to find out about errors:

One can monitor logs like this every so often, but unless it's right after release time, it's not very practical. Most of the time, nothing bad happens, so you stop checking the logs regularly. You might check them once a week or so, but then you get busy with other things and forget about it.

You assume that if something goes wrong, you'll hear about it from users or see it in the logs eventually. There is some truth to that, but it can take a while before you notice the problem, and by then, you might have lost a lot of users who couldn't use the course because of the bug. This is exactly what happened to the project in July.

---

PostHog to the rescue

I've been trying to de-google for several years now, but I still mostly use Google Analytics on my projects for tracking user interactions. Recently, I found out about PostHog and decided to give it a try. It combines several features that I need: event tracking, session recording, and error reporting. It also has a generous free tier, so I can use it in my early access project without worrying about costs for now. Also, they have a cute hedgehog mascot called Max, which I simply adore.

VS Code developer guidelines prohibit using your own analytics scripts inside the extension, mainly for performance and security reasons. However, the telemetry that you collect via the VS Code API is fair game, so you can receive it on your server and then re-send it to PostHog or any other analytics service. This way, you can still track user interactions and errors in your VS Code extension without violating the guidelines.

This solved the readability and tracking issue, but I still needed a way to get notified about new errors in real time. PostHog has a built-in alerting system that can send you notifications via Discord, Slack, or other channels when a new error occurs. This way, I can be immediately notified about any issues and address them quickly.