My name is Haton, and I am an application engineer in the Authentication and Authorization Infrastructure team at freee. My favorite language is Go!
During my school days, I was a mathematics student who had nothing to do with computer science and didn’t even know the difference between memory and storage. Having embarked on programming after joining the workforce, I suppose I view myself more as a “somewhat-engineer”.
In this article, I’ll discuss how I familiarized myself with Go.
What I liked about Go
Go has few language features, so I think it’s easy to learn the language specifications. This is similar to the feeling that if you only understand the proof method without memorizing the mathematical formulas, you will be able to derive and use the necessary formulas at any time. I’m not good at memorizing a lot of things, so I really like languages like Go.
Even in the standard package, everything up to the system call is written in Go, and I think it’s great that you can read it without any special setups as long as you have the motivation to do so.
When it comes to language design, take the io package as an example; I appreciate how it seamlessly handles everything from network to file I/O through the io.Reader and io.Writer interfaces, creating a beautifully unified experience.
Immersed with Go
My introduction to Go happened when I joined a project that opted for a web framework named Goa.This was right after the release of version 3, so resources were limited, and we encountered a few questionable behaviors upon its release.
Of course there were already some Japanese-speaking committers, so it was not like I wasn’t able to ask questions. But at the time I thought it might be rude for a beginner to ask questions to the Goa community, so I decided to try to solve the problem myself. In order to understand the code surrounding the processing that I was having trouble with because I didn’t understand anything, I used vscode’s debugging function to jump to the code inside Goa and just kept reading the code.
I didn’t really understand it at the time, but as I was jumping through the code, I often ended up looking at Go’s standard packages. I was uneducated and could only understand about 10% of the processing of the optimized standard package.
However, after learning that even beginners can observe behavior, I had a small but successful experience, and gradually began to feel comfortable reading Go.
Getting into the habit of debugging
Even when I was using Go for about two years, I still had hesitation reaching out to Go experts for questions. So, if I had a library behavior issue, I would first run debugging to understand its contents and repeatedly determine if I was using it incorrectly or if it was simply just a bug.
As I continued to follow these steps, I developed a habit of debugging promptly whenever an issue arose or a document didn’t align with my intentions. Though seemingly straightforward, with each reading session, I deepened my understanding of code behavior, eventually becoming the go-to person for Go-related inquiries and establishing myself as an expert within my team. Being relied upon by others brings me joy and serves as motivation to expand my knowledge even further.
Trying various application architectures in projects
About three years after I started using Go, I had many opportunities to think about application architecture. I tried various architectures such as MVC, clean architecture, and lightweight DDD in projects. Because I was experimenting with architecture without much understanding, I can say I went through a lot of regrets, reflections, and painful experiences.
From this learning experience, I have come to the idea of keeping the structure and code as close to the Go standard as possible, and incorporating libraries and architecture as needed. During the initial implementation, I believe it is important to share the entire process with the team during the POC, so I often try to improve the visibility of the code without paying too much attention to the architecture.
Trying various application architectures in projects
About three years after I started using Go, I had many opportunities to think about application architecture. I tried various architectures such as MVC, clean architecture, and lightweight DDD in projects. Because I was experimenting with architecture without much understanding, I can say I went through a lot of regrets, reflections, and painful experiences.
From this learning experience, I have come to the idea of keeping the structure and code as close to the Go standard as possible, and incorporating libraries and architecture as needed. During the initial implementation, I believe it is important to share the entire process with the team during the POC, so I often try to improve the visibility of the code without paying too much attention to the architecture.
I think this way of thinking is suitable for small teams.
Contributing to Open-Source Software (OSS)
During this period, my confidence grew as I found myself leading more frequently in technical matters.My burning desire to contribute to open-source software, something I believe crosses everyone’s mind at least once, intensified.
Initially, I attempted to create my own library, but I eventually lost interest and didn’t pursue it further. Instead, I started examining the source code of the libraries I regularly utilized, aiming to make modifications and potentially contribute something valuable. Despite not being an active open-source software (OSS) user, I primarily focused on three tasks.
- Commented that certain issues will be resolved if its PR is merged into the sqlx issue.
- Submitted a small PR to gocsv and have it merged.
As I continued my OSS activities, I realized that people in the community were kind enough to reply to even newbies. This helped me to lower my psychological hurdles towards OSS, which made me want to continue contributing if I had the opportunity to do so in the future.
Go experience at freee
Recently, I was able to create a foundation for application architecture, and I’m having fun doing that.
There are many people at freee who I feel are more knowledgeable about Go than I am, so I’m keen on improving my ability to naturally absorb information from experts, something I’ve struggled with in the past.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
Conclusion
Transitioning into engineering after entering the workforce presents several challenges, particularly due to the absence of systematic knowledge. However, I was reassured that my extensive exposure to code had helped mitigate this gap.
I believe Go is a language that facilitates behavior observation through debugging. I encourage you to immerse yourself in debugging as much as possible to truly make Go your own!
