Jon helped a lot of teams improve their software engineer processes. We talk about the importance of testing, having sane Ci and CD pipeline, pairing and a lot of other extreme programing concepts.

Links:

• Tuple pair programming guide:
• The Mob Tool
• Pop — Screen sharing for remote teams

If you'd like to support the show spread the words about it, join the slack channel #gopodcast, take a Patron subscription, purchase Zero to Gopher, my latest course.

My desire to run a sustainable software business started somewhere near 2003 in the Business of Software forum. I've built, sold, and acquired a dozen of products since that time, with I have to admit the majority of failures.

I've seen three distincts era for software companies, we're definitably in the 3rd one, one that still has to be identified as good or bad.

Software companies, especially calm company is excruciably hard to be successful at. But when you're honest and define what is success to you and set out realistic goals, there's ways to succeed even without have $2m in ARR.

Go is of course a great choice to build a SaaS, but software product has almost zero to do with technology, especially at first and you'll most certainly end up rewriting to a v2 at some point after learning what the product really need to be. So the good old advice of use what you're most proficent in to write code is most often than not the correct answer.

I talk about my experiences trying to run a sustainable software company for the last 17 years.

Links:

• My last course Zero to Gopher with a discount for listeners
• Support the show on Patreon

As always if you can talk about the show it helps spread the words. If you'd like to talk about something you're passionate about related to Go please reach out. If you'd like to support the show you can purchase my courses and/or take a Patron subscription.

Jakub is returning to the show, he's about to launch a book called "50 Go Testing Mistakes" and we talk about the most common mistakes Gophers are making when it testing. Having a trustable testing suite is known to be critical for long-live software system. I can testify having maintained a .NET codebase for 20 years without any tests, it sucks.

Links:

• Jakub's website
• Mailing list
• LinkedIn
• Bluesky

One university published attracted my attention, because it was on Go, it's titled: "Assessing Golang Static Analysis Tools on Real-World Issues".
Do you find your static analysis and linters tools could be more helpful when reporting issues?
I'm mixed feeling really, I think that they're pretty damn good. Tools can always improve for sure, not sure if we will need the help of LLMs to mix static analysis checks and LLM analysis / proposed fixes, maybe that will be the next step for those tools.

Links:

• Paper's link

I finally gave Gleam a serious look and ho boy I'm excited. I've looked at Gleam a long time ago back when it started with the ML-like syntax. I've always been an Elm fan, I discovered functional programming with Elm. Near 2016-2017 I tried Elixir and Phoenix, and gave it a try multiple times following the years, but I'm not fully sure why it never clicked completely for me.
As someone engage with Go for the last 10+ years, I won't lie that I was looking for some excitement lately. Not because I'm tired of Go or anything, I've dabbled seriously into Python/Django in the last 3-4 years. But Gleam, at least so far, as this I don't know what that I felt when I started Go back in 2014.
There's so many programming languages these days that I suppose it's really comes down to a matter of taste. I do have some minimal checkboxes that a language must checked before I even considered looking at it, and Gleam was checking them all. It's a refreshing language after 10 years of Go. Just another tool in the toolbox, but I'm extremely picky about which tool I put in my toolbox haha, so Gleam for now is in the evaluation phase, but so far I'm excited and I haven't felt like this for a long time.

The message is everywhere: LLMs are here to make us 10x more productive and change software development forever. Venture capitalists are pouring billions into the vision, and big tech companies are pushing hard for us to adopt the tools. But as a software engineer who’s seen the demos and lived the reality, something feels profoundly wrong.

This week, I’m taking a step back to reflect on the current state of our industry. We'll explore the inconvenient truth that often gets lost in the hype: that relying on AI can sometimes make us slower, introduce more technical debt, and even erode the fundamental skills that make us valuable.

But maybe the real problem isn't the technology itself. Maybe it's that we're looking for a quick fix for a deeper issue. Join me as we discuss what really drives developer productivity, the crucial importance of domain knowledge, and whether anyone is even considering the quality of life for the people building our systems.

Because while the "going from 0 to 1" demo is impressive, our jobs are about maintaining complex systems from 1 to 1000. And maybe, just maybe, an agentic flow that doesn't care about our codebase isn't the real solution we need.

p.s. And yes, I used LLM to improve my description draft ;)

Let's talk with a friend of the pod, John Arundel. We talk about state of thing a little regarding Go's maturity, a bit of AI, I personally am a bit fatigue of the noise and "agent". The podcast is returning slowly. , John has written a new Go book that's beginner-friendly, but goes deeper than you'd expect, he produce excellent learning and training resources.

Links:

• The Deeper Love of Go
  • John's newsletter

Go is used by multiple programmers and software engineers. Lots of path can lead to want to try Go, and this week I talk with Yann whom eventually found Go and talks about his experiences writing internal tools at his company.

Links:

• Hupload
  • YBFeed