At most places I’ve worked before, we were conditioned to complete tasks entirely - PR, deploy to stage or testing environment - and only then would we get feedback from the “Product Team” / “QA” team.
I started becoming interested in computers when I was very young. Back then, I still remember using Windows 3.1. Although the main purpose was just to play Prince of Persia, I kept tinkering with other things too. Calculator, PaintBrush, and whatever I could explore.
As a kid, I really loved playing games. To the point where my parents would get angry because I was always gaming. At that time, my mother was still studying. She brought home books about computers, if I remember correctly, Borland C. I tried to implement the simple instructions from the book on the computer. By then, I was probably already using Windows 98.
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:
go code snippet start
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.