The Franconian
Coder Studio

When it comes to side projects, the question of the ‘best’ tech stack is a common dilemma. But after years of experimenting, I’ve realized the answer is straightforward: choose whatever you enjoy! Side projects should be fun, productive, and a space for learning. Whether it’s Go, which I’ve used professionally for nearly a decade, or Zig, which I’m exploring for fun, the key is to embrace the diversity of technology. Don’t chase trends or the next big thing—focus on what excites you. In this article, I’ll share why enjoying the process and learning from different stacks will ultimately make you a better developer.

Kubernetes has become synonymous with modern infrastructure, but is it always the right tool for the job? While its scalability and automation are appealing, they can lead to a lack of critical thinking about core metrics like user behavior, response times, and redundancy. As a fan of straightforward solutions—like Go for programming—I believe infrastructure should be simple, predictable, and easy to understand. In this article, I’ll share why I’ve often opted for simpler setups using tools like Traefik, NATS, and Ansible, which have proven to be highly scalable and maintainable without the overhead of Kubernetes. Sometimes, boring infrastructure is a sign that everything has been done right.

Testing during development is essential, but real-world scenarios often defy expectations. To ensure my code performs reliably in production, I’ve adopted a strategy I first used almost a decade ago: writing the same logic twice. Ideally, two developers independently implement the logic, sometimes even in different programming languages. Only when both versions produce identical results in production is the code accepted. While this approach isn’t practical for every function, it’s invaluable for critical systems. Whether running both implementations continuously or temporarily after updates, this method complements traditional testing. In this article, I’ll discuss how double programming can enhance fault tolerance, error detection, and safety in production environments.

Over 30 years of coding have taught me one thing: the right tools can make all the difference. From humble beginnings with basic text editors to experimenting with IDEs like Eclipse and NetBeans, my journey took a significant turn with PhpStorm. It set a new standard for me, and when I shifted to Go, GoLand became my go-to IDE. While I’ve dabbled with VS Code, especially for remote development, I always find myself returning to GoLand. Its seamless code completion, robust refactoring, and intuitive debugging tools make it indispensable for my work. In this article, I’ll share why GoLand continues to outshine alternatives for my Go and TypeScript projects.

When Docker entered the scene around 2015/2016, it felt like a game-changer. Containers provided isolated build and run environments, making packaging and deployment more manageable—and even fun. But as our environment became more defined, we realized containers weren’t a strict necessity. With the introduction of systemd, many of the isolation and process control issues we relied on Docker for were solved natively. This shift led me to happily switch back to DEB packages. In this article, I’ll discuss the trade-offs between containers and traditional packaging, and why it’s essential to choose the tool that best fits your needs.