We quit our jobs to help people write software more mindfully

Leaving a principal software engineer role while having a newborn kid, a mortgage to pay, and a house being built may not sound like the best idea. Still, I took a significant pay cut so I could make a living by educating people about software. Some people literally told me that I’m crazy.

Well, Miłosz (the co-founder of this blog) and I decided to build a company we love to work at without VC funding.

It wasn’t an easy decision. Finances, of course, are always a concern. Also, we may not have as much time to work after hours as we used to. Let’s also be brutally honest; we won’t be alive forever. Still, we have families we need to provide for, and we want to build a company we can be proud of.

Let’s start with how it all began.

Our Journey

I met Miłosz in 2008, when we were in high school. At that time, we started writing software together — after school and after work (sometimes, we even worked at the same company). For a decade, we have been working two full-time jobs.

Our after-hours projects were more or less successful. For example, in high school, one of our online game servers became the biggest one in Poland. We earned enough money so that Miłosz could buy a car, and we even threw high school parties. We were making good money for the time!

During that time, we saw how different software development strategies work in different scenarios. We learned how to cut corners and write code in the simplest way possible. For two-team projects, following “the simple way” was usually fine, but for bigger projects, we needed to learn more advanced techniques.

Starting this Blog

A couple years later, when we were leading and mentoring teams, we saw that some techniques were hard to grasp for our less experienced teammates. Sharing our knowledge to a wider audience sounded like a good idea. So, 7 years ago, we started this blog. Since then, we have created 39 detailed articles. A good example is our article about Live website updates with Go, SSE, and htmx. There are a couple other articles describing SSE in Go, but most of them are quite surface-level. We like to go extra deep to show real-life scenarios.

It’s great to see that there is a demand for in-depth content about complex techniques. In fact, every year, our blog is visited by around 270k people!

Watermill - Monetizing Open Source While Staying Open Source

Around the time we started our blog, we also worked on a project that explored how event-driven architecture would make the application faster and easier to develop. Unfortunately, most of our team didn’t have any experience with this kind of architecture.

At that time, we asked ourselves a question: “How can we make building event-driven Go services as simple as HTTP API?” This is how Watermill was born. It is now the most popular Go library to build event-driven applications (at least according to GitHub stars, since we don’t have a better measure).

You may be asking yourself: “Don’t you want to monetise it? Is it time to change the license and start charging people?”. That’s not our plan. We treat Watermill like a good marketing tool, and that’s it. We have also heard that Watermill is useful for people, and that makes us happy!

We are self-funded, so we can afford such extravagance. Truly, we don’t believe that potential income would be worth losing our community’s trust.

The Process of Finding Better Ways to Share Knowledge

About 4 years ago (3 years after starting our blog), we released our book Go With The Domain. We already knew the content we were creating was useful. This was the first in-depth book about Domain-Driven Design in Go. We later heard from people that their teams used it as a guide on how to develop their applications. But it was still missing one critical piece.

You can read tons of books and watch hundreds of videos and take all sorts of courses, but if you don’t put into practice what you have learned, you won’t accomplish anything.* There is no shortcut here; you need to mindfully use things you want to learn and evaluate the tradeoffs and hidden complexity. The best way to learn is by working on real-life projects. Not TODO apps or calculators; such applications are too simple. You need to learn how to overcome problems you’ll likely face while building real-life applications.

Learning in the Age of AI

These days, everyone (including me and Miłosz) uses AI during the development. Learning practical skills is even more important now than ever before. AI is widening the gap between junior and principal engineers. Junior engineers now struggle to find a good job. Ironically, it’s hard to find skilled principal engineers who can build applications that AI can’t handle (and likely won’t be able to handle anytime soon).

Principal engineers can do their job faster, while junior engineers may spend hours mindlessly copy-pasting AI-generated code without actually learning anything. The demand for engineers who can do simple applications is decreasing, as AI can handle these jobs more efficiently.

If you are afraid of AI taking your job, you should find a way to make yourself indispensable.

Building a Custom Learning Platform

Learning by practice requires a lot of time and patience. You need to find a good project theme and proper materials. It may also be frustrating when you are stuck and don’t have anybody to ask for guidance.

To speed up the learning process, we built a learning platform that supports users through building complex, real-life projects. It’s not yet another platform where you watch videos and code in the browser. It’s a way to put what you’ve learned to practical use.

Building a learning platform from scratch requires more time than running an open-source project or a blog. We didn’t have a choice; we had to work on it during the weekends and on holidays. We have been very productive! People were surprised when we told them we were going to work full-time at Three Dots Labs. They asked, “Aren’t you already working at Three Dots Labs full-time?”

We created a CLI tool, which clones and executes code. Our CLI will clone exercises for you, then execute them. It will save you a lot of time. This is why the feedback loop is so fast:

A Platform is Nothing Without Content

Our first training on the platform is called “Go In One Evening.” Many people said, “No way! It’s not possible to learn Go that fast!” We love to build things that people don’t believe can be real.

We were leading teams of people who had never written a single line of Go in their lives. We saw for ourselves how quickly they became productive - so we know it’s possible. Data we have gathered confirms this.

The agenda includes creating a simple social media platform clone and building the ls CLI tool. It’s designed for software engineers who know how to code already but want to learn Go. We don’t waste your time with how variables and functions work; you already know that stuff. Instead, we focus on things that will be essential in your work.

“Go In One Evening” is not our only training. We also have our flagship training, “Go Event-Driven,” where we teach how to build production-grade, event-driven systems. The core idea is the same: we teach by building real-life projects.

I won’t spend much time describing how it works; I would encourage you to try it!

Financials

Last year, 746 people joined our trainings, translating to $129,741 in revenue.

While that may sound like very good money, it’s less than we earned at our jobs. Our income is not stable yet, so we don’t take it for granted. If you have a steady office job, you may not appreciate that you will always be paid for your work. It doesn’t matter if you have a bad month. In this business, however, you can work on a project for a year, earn $0, and waste your time and money. Hackernews is full of such stories:

What Are Our Next Plans?

This is where we are right now. What are our next steps?

We want to continue doing all initiatives, like our blog and open-source projects. But we have a couple new things on our plate, including:

• starting our own podcast,
• doing more online trainings, and
• sharing what we are working on (building in public).

That may not sound very original; hundreds of people are doing the same things. But there are a couple of things we want to do that are totally different!

Let me explain.

Why Do We Need Another Live Podcast?

If you go to the gym, you may hear the term bro science. Some guys will tell you things like, “Take this pill, and you can exercise less and still get bigger. Don’t be a moron who wastes time.” For less experienced people, that may sound appealing, especially when you hear it from some big guys. The same thing happens in the software world.

There are a lot of bros who give software advice that is supposed to be a silver bullet and make your life easier. I don’t accuse anyone of lying; they are probably sharing what worked for them. However, people should stop advising as if it’s the silver bullet for all problems and acting as though their solution is the only way to do things. Something that works for a solo developer will not necessarily work on a global financial platform. Social media algorithms make this problem worse because they favor polarization and extreme opinions.

You may ask, “Why should I care?”. Companies are good at rejecting people who don’t know how to solve company problems. If you don’t want to find yourself out of a job market, you need to learn how to adapt. I’ve been interviewing people for years, and I could easily tell whether someone is truly interested in solving real-world problems or just follows CV-driven development.

If you are ambitious, you probably prefer to work with passionate people as well. Joining such teams is not easy – they usually have a high bar to join them.

That’s why we’re creating a space where you can learn battle-tested programming practices that actually scale - from solo side hustles to complex enterprise systems. No bro science, just real-world experience.

Polarization in Software

Polarization is quite prevalent in the software community now. There are two very distinct camps out there:

1. Engineers: For them, technical excellence is important; they care about maintainability
2. Shippers: For them, technology is secondary; they care mostly about shipping as many features that customers can use as quickly as possible; they are known to take shortcuts

There is an ongoing war between those two camps. You often hear very different arguments from both camps, like: “It won’t scale,”, “Just ship it,” “That’s not how it should be done,” “You don’t need unit tests,”
“It won’t be maintainable,”_ and “Quality doesn’t matter; we can always rewrite it.”

Both camps have valid points. The problem starts when people are unable to see the other side. Often, Engineers focus too much on technical excellence, and they may not be delivering anything usable for far too long. On the other hand, Shippers, after releasing a successful MVP, may wade into technical solutions that won’t work for bigger teams or products.

Can’t We Do . . . Both?

We should be open to diverse opinions. Wouldn’t it make more sense to merge these two approaches?

It’s not easy to learn how to balance the pros and cons of shipping and engineering. This requires time. We need to learn how to build software, and we also need to understand how this software affects development. Miłosz covered this topic nicely in the The Over-Engineering Pendulum post. Even though Miłosz and I have been building software together for almost two decades, we still struggle with this balance.

NEW! 🎉 No Silver Bullet Live Podcast: A Software Deep Dive from Multiple Perspectives

No Silver Bullet ideally illustrates the message and unique selling point of our live podcast: showing multiple perspectives on which tools and techniques work in various scenarios.

Over the last 17 years, we have written software for various projects. From legacy companies to startups. From simple applications to global settlement platforms. Most of the time, we acted as hands-on engineers, but we used to be managers and founders as well. We want to share our unique, diverse experience with you. We want to teach you how to apply patterns and use appropriate tools for different projects.

Like always, we aim to push the bar even higher. We want you to be part of our show so you can comment or ask questions about the topics we cover. It’s a win-win; we can go deeper into topics you care about and improve our content.

In No Silver Bullet, we’ll cover more general software engineering topics. But Go-related topics are also in the queue!

Our setup is ready; we will go live for the first time at the beginning of March! We have a list of the first 5 episodes on our live podcast page. We want to go deep for every topic, so we will stream an episode every two weeks.

NEW! 🎉 Next Trainings and Training Mentoring

Trainings are the best way for Three Dots Labs to make money. We also know that these trainings give people the most value for their money. Our trainings are a great way to leverage your skills and, hopefully, find a better-paying job.

You may be wondering: “When will the next training be available?”

Before we launch the next training, we want to finish our mentoring functionality, which will greatly help you learn these skills even faster. When you are learning something new, it’s important to be able to ask for help. This can also help you save a lot of time with problems that may be solved by someone more experienced quickly. With the current state of LLMs and our knowledge of your most common questions and obstacles, we can give you hints like we would sit next to you! I’m already sure that it will be one of the coolest features that we have.

We aim to announce the next training sometime in March.

Why We Are Focused on Go for Now

Go is one of the best-paid languages, according to the JetBrains State of Developer Ecosystem Report 2024. You don’t need a PhD to learn it. Compared to other newer languages (like Rust), finding a job as a Go engineer is much easier.

This year, we will remain focused on Go trainings. If you don’t know Go yet, how about learning a new programming language with the “Go In One Evening” training?

NEW! 🎉 Building in Public

We want to share our journey as we create a sustainable business that we love — and that you can benefit from. If you are interested in following us, we will share what worked and what didn’t work every 12 weeks. We’ll share information about our finances, and we’ll discuss what mistakes we made along the way. Miłosz is already working on a summary of the first iteration, which will be out soon!

Aim for Sustainable Growth

We aim to build a dream company that we genuinely love to work at, a company we don’t want to sell. We are realistic; we always keep a list of things we don’t like to do but need to get done. It’s all a matter of finding the right balance.

Often, the “fun things” are not justifiable from a business perspective. Since we don’t have any external deadlines, though, we can work on things that matter and make sure the products we are putting out are the best they can possibly be. We can spend this one extra mile to change good things into outstanding.

Like with our trainings platform — we spent a lot of time optimising code execution and deploying it in multiple locations to make it fast. In effect, you may feel like it’s executed locally. Would it change a lot if it were slower? Probably not, but it’s cool!

Will We Succeed?

Our unusual approach may seem naive to many people. But based on our experience, we believe we will succeed. We always love to question the status quo and blaze new trails. After all, we created Watermill and wrote Go With The Domain. Now, we are working on online trainings.

You can expect to see new articles on the blog, and we will continue working on Watermill.

Will this strategy work? What if our assumptions are wrong? Will we have to return to full-time jobs to pay our mortgages?

The best way to follow our journey is by joining our newsletter. We prefer this over social media, as we aim for a long-term relationship with you. Social media posts show up, then disappear. An email stays in your inbox forever. We are also independent of its algorithms and owners.

If you are already one of our 17k newsletter subscribers, please tell your colleagues about our live podcast!

Will you cheer us on? Do you think we will succeed? Let us know!