Mastodawn

Grzegorz Wilczyński Apr 22, 2025

Go interfaces don't say what you provide, they say what you need. They’re about behavior, not inheritance. You define the contract, not the implementer. 💡 #golang #cleanarchitecture

Grzegorz Wilczyński Feb 25, 2025

https://lunarem.com/posts/what-just-doesnt-matter/

What Just Doesn't Matter

A lot of people think the best managers and developers are the ones with the most talent, the best technical skills, or the ability to tackle every problem. But in reality, what truly sets the best apart is knowing what doesn’t need their attention, at least not right now. A great manager isn’t just someone with strong leadership or communication skills. They don’t try to control every detail, join every meeting, or make every decision. Instead, they know which discussions, tasks, and problems can be avoided without consequence or delegated to someone else. Likewise, a great developer doesn’t obsess over every line of code or chase perfection where it’s not needed. They understand that “good enough” is often better than perfect.

Lunarem by Grzegorz Wilczynski

Grzegorz Wilczyński Jan 30, 2025

Unit tests used to feel like a struggle—now they’re my guardrails. Writing documentation? Same story. I share how I turned these dev “chores” into habits that give me speed and confidence. With the C4 model, documentation doesn’t have to be hard. Start small, stick with it, and watch your workflow transform. 🚀

https://lunarem.com/posts/from-hore-to-habit/

#DevJourney #TDD #C4Model

From Chore to Habit

Every time I joined a new project, I made it a point to take responsibility for fixing bugs. Why? Because fixing bugs is the best way to understand the architecture and get familiar with the codebase. Often, there’s little to no documentation, and all the knowledge is locked inside the developers’ heads. By fixing bugs (and writing tests as I went), I created my own map to navigate the codebase, uncover its quirks, and ensure I wasn’t lost.

Lunarem by Grzegorz Wilczynski

Show thread

Grzegorz Wilczyński Jan 16, 2025

As an appendix, I recommend this article https://100go.co/5-interface-pollution/, and the entire book https://www.manning.com/books/100-go-mistakes-and-how-to-avoid-them in general

Interface pollution (#5) - 100 Go Mistakes and How to Avoid Them

None

Show thread

Grzegorz Wilczyński Jan 16, 2025

✨ Testability and Mocking. When the factory function returns the struct, consumers can create their own interfaces based on their specific needs. This makes it easier to mock the behavior for testing since the interface can be narrower and focused on the specific methods the test cares about.

Show thread

Grzegorz Wilczyński Jan 16, 2025

✨ Interface Segregation. Returning the concrete struct allows you to add methods to the struct in the future without breaking backward compatibility. If you return an interface and later need to add a method, all implementations of that interface need to be updated, which can be disruptive.

Show thread

Grzegorz Wilczyński Jan 16, 2025

✨ Interfaces Should Be Defined by Consumers. Interfaces are generally more useful when defined by the consuming code rather than the producing code. Returning a concrete struct instead allows the consumer to define and use their own interfaces as needed. This decouples the producer from the consumer and avoids forcing a specific abstraction on the user of the handler

Grzegorz Wilczyński Jan 16, 2025

I was looking for distilled information about clean architecture in the context of GO. In the meantime, my colleague found (in my opinion) the best article that describes this topic in great depth: https://pkritiotis.io/clean-architecture-in-golang/

In general I like most of it. However, what I don't like is that every handler's builder returns an interface instead of a concrete struct, and the domain defines the repository interface.