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. ...
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. ...
Years ago, before JavaScript made its way to the server side (yes, that’s an important digression, believe it or not), One of my colleagues once shared an intriguing observation with me: backend programmers, whether they come from a C# or Java background, often resemble drivers switching to bicycles when they start programming in JavaScript. It’s as if they forget all the rules. And here’s the thing: I think this observation holds true. Back then, JavaScript wasn’t respected. It was dismissed as a “dumb language.” A toy for web designers to sprinkle some interactivity onto their pages. Fast forward 15 years, and while JavaScript has become a powerhouse, I still see controversial code written by experienced programmers from so-called “real” languages. It’s the kind of code that makes you wonder if they left their instincts and good practices behind when they crossed over. ...
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. Here’s why returning the concrete structure might be a better choice in many cases: ...
“Hello, World!” is often the first program written when learning a new programming language. It’s simple, yet powerful—it marks the beginning of a new adventure in coding. It’s a rite of passage for every programmer, a small but significant moment that confirms everything is set up correctly and working as expected. ...