Posts

You know, Go (or Golang, as some people call it) is known for its simplicity. But as your project grows, things won’t stay simple forever.

You can still maintain simplicity in your code organisation. How you structure your codebase really depends on your approach. Some developers start encapsulating things immediately, while others prefer to keep it simple at first.

When you start structuring your codebase, you might be biased-especially if you’re coming from a different ecosystem or programming “tribe.” Your structures are probably influenced by those other languages.

In the dim light of the office, long after most of the team had left, I found myself deep in conversation with my senior. We were hunched over a whiteboard, markers in hand, surrounded by a chaotic array of boxes and arrows that represented our project’s folder structure.

Months ago, we had enthusiastically crafted this structure, believing it was the blueprint for success. But as time passed, reality set in. Our once-promising structure had become a tangled web, tightly coupling components and making even the smallest changes a Herculean task.

In a bustling tech startup called KathTech Inc. (not the real name), our team was working on a highly anticipated app—one that was meant to revolutionize the way people ordered bubble tea (not a real app). Each of us brought unique ideas to the table, but there was one person who stood out: Adrian the Architect. Known for his brilliant mind, Adrian had a reputation for coming up with ideal, flawless technical solutions. The kind of solutions that made you go, “Wow, that’s genius!” —until you realized they would take three years to build.

I was working on a project where I need to check on certain errors that return from a deep, deep function.

The deepest function was calling a third party API. Fortunately, the third party package that I was using is pretty following ‘single responsibility principle’.

Ah, this is great! Since the function purpose is to wait until some capacity is ready on the provider side, I can just check on the error the function returns.

When I was starting to learn Go, I was passing around the instance to access the property of that instance. This is how I do it:

I’ve been reading that singleton is an anti-pattern but it helps when I want to connect to a DB instance.

There are so many thoughts. For starters, the above is a very generic statement. Some languages rely on singletons, and some languages don’t support them at all. I think that everything has a place. And as long as the consequences of doing a thing are understood, and acceptable, then it is ok to do the thing.