Developer Diary 1
Introduction
I’ve been self-studying a lot of courses and working on many projects recently, so I haven’t had the chance to write blog posts. Since a blog needs frequent updates, I’ve decided to introduce another format, Developer Diary, to record my thoughts and observations during development. This post covers: choosing third-party libraries, Go, and “stock responses”.
Choosing Third-Party Libraries
To implement a feature in a project, we usually pick an existing third-party library to avoid reinventing the wheel. But when there are many options, we can suffer from analysis paralysis, not knowing which one to pick. Here are some criteria I consider (in no particular order; weigh them holistically):
- Open source: Generally, open source >> closed source, but not always. Some stagnant open-source libraries may no longer be maintained or could even harbor malicious code. Conversely, a closed-source commercial product might be excellent, affordably priced, and save you a lot of time.
- Star count: This metric can be misleading. On one hand, libraries with more stars tend to be higher quality, as statistic data often bear this out. On the other hand, a high star count might stem from non-technical factors like better marketing or even purchased stars.
- Functionality: Does the library include the features we need? Are its configuration options comprehensive and rich? Are there a lot of bug-report issues?
- Documentation: Is the documentation detailed, comprehensive, up-to-date, and understandable?
- Activity: Judged by commit frequency, issue-closing frequency, PR merge/reject frequency, release frequency, and so on.
- Security: Has the library ever been reported to have a major security vulnerability?
- Sustainability: Will the author continue to develop the library? Unless the author explicitly states that support will end or the project is entering maintenance mode, we need to infer continuity from other aspects, such as other projects of the author.
- Community feedback: Check Reddit, Stack Overflow, Bilibili, and other platforms for discussions. Be mindful of vested interests or astroturfing.
- Related news: Both positive and negative press can be informative; you can even look up news about the author.
- Political content: Any library containing political content is out of consideration.
Many of these factors fall under the broad umbrellas of “ecosystem” and “community,” but I prefer to spell them out concretely.
Go
The MIT 6.824 course requires projects to be written in Go, so I started learning it. I first encountered Go two years ago and found it quite “bizarre”. But after learning JavaScript and various frontend libraries, my impression of Go changed.
Go shares many philosophies with JavaScript, e.g., “functions are first-class citizens”, and no native object-oriented support. Back then, coming from Java, I found Go’s approach baffling, as if Go were the sole outlier. After diving into JavaScript, these ideas became much more palatable.
Another thing I once found odd and hard to accept was Go’s syntax and its underlying design philosophy. Go almost disallows any alternatives: if you have for
, there’s no while
or do-while
; if you have if
, the ternary operator bool ? v1 : v2
is deemed unnecessary. I understood the benefit of doing so: enforcing a single style for all developers at the language level. But I still wondered: is Go too authoritarian?
Let’s compare with other languages first. Spring Boot’s philosophy is “convention over configuration,” providing many out-of-the-box features. Only do we follow the conventions can we enjoy a fast development experience. Otherwise, we need to manually configure something. Yet Spring Boot at least allows you override defaults and define your own rules. In contrast, Redux Toolkit and Next.js are very opinionated: we must adhere to their conventions, with almost no room for customization (and even if possible, it’s a huge hassle).
Let’s return to Go. Having learned RTK and Next.js, I now accept the uniformity of Go’s syntax because I understand that Go is an opinionated programming language. Note that being opinionated isn’t inherently bad. Just as too many third-party library choices can hamper productivity, a well-endorsed set of language rules can reduce the time spent comparing alternatives and boost efficiency.
These experiences show that learning diverse technologies is always beneficial. It builds your knowledge base and makes you more open to new technologies.
“Stock Responses”
What are “stock responses”? Here’s DeepSeek’s definition:
In tech industry, “stock responses” (八股文) is a pejorative metaphor referring to knowledge points, answering patterns, or interview styles that are rigid, formulaic, divorced from real scenarios, and overly focused on form over substance.
Interview stock responses: Standard Q&A‐style interview questions that candidates are repeatedly asked to memorize verbatim.
Indeed, “stock responses” often get bad press, yet they’re hard to avoid if you want to pass technical interviews. It’s worth noting that the questions themselves shouldn’t be blamed. On the contrary, they serve as an excellent gateway to understanding a domain, since most of them are foundational and low-level.
Note that good stock responses are those carefully curated by the author, e.g., “Xiaolin coding”, not the copy-and-paste blog posts you find all over the web. The latter are ubiquitous and heavily duplicated.
My reflection on stock responses arose when working with SQLite transactions. Unfamiliar with SQLite’s transaction model and concurrency model, I worried about deadlocks and scoured the web. Useful resources were scarce, with much duplication that made me doubt their accuracy. The official docs were hard to follow. Ultimately, I resolved my doubts via an LLM but didn’t gain a deep understanding of SQLite’s architecture.
You might ask: why not just ask the LLM directly? The answer is: if there’s no valuable SQLite material online, how could an LLM be trained to answer SQLite questions accurately? Won’t it hallucinate and give me wrong answers? I’ve experienced hallucinations before when asking about WPF.
By contrast, there are plenty of MySQL “stock responses” on the Internet. We can study them ourselves or trust LLMs to summarize them reliably. That’s why I hope to see high-quality SQLite stock responses available online.
Finally, putting aside the pejorative term “stock responses,” I believe “any question that expands the boundaries of our logic is a good one”. After learning how to use a technology and wanting to delve deeper, stock responses in FAQ form offer a path different from official docs or reading source code, which is a good thing. Besides, many people have landed offers thanks to stock responses; there’s no need to burn the bridge behind us.