First, there’s some essential reading in the excellent Google SWE Book: Large-Scale Changes chapter. A key point being brought up by Adam Bender:

Today it is common for a double-digit percentage (10% to 20%) of the changes in a project to be the result of LSCs, meaning a substantial amount of code is changed in projects by people whose full-time job is unrelated to those projects. Without good tests, such work would be impossible, and Google’s codebase would quickly atrophy under its own weight. LSCs enable us to systematically migrate our entire codebase to newer APIs, deprecate older APIs, change language versions, and remove popular but dangerous practices.

A “modify after write” error refers to a situation where a program or process attempts to modify data after it has been written or committed to a particular location or state. In Go terms, this can mean that a field may be modified after the struct has been written to the database.

When debugging a login issue, we found a field was not updated in the database. On investigation, I found that a field in the user data was being modified after it had been saved to the database. Fixing it was just reordering a few lines of code.

Hello, my name is Tit Petric. I’m a Senior Engineer working on Go code at Tyk Technologies. I’m working on back-end code for the open source Tyk API Gateway and the Tyk Dashboard API management product.

I’ve started the Semgrep Code Intelligence project to collect test utilities, toolings, reports, code review feedback, experiments and other development efforts aimed to improve the process around development and the overall vibe of the codebase. Knowing what to fix requires knowing what is there and how it’s coupled.

Don’t optimize prematurely - but have a plan how you’re going to do it. With the services I write, a lot of the code may be clear, simple and readable over actually optimizing for speed. Sometimes, the difference between that code, and the optimized code, is a short refactor.

When it comes to logging in your Go services, the immediate package to reach for is the standard library log package. As it happens, you’ll outgrow the log package needs almost immediately, because the log package is able to send the relevant logs only to one io.Writer stream, by default sent to os.Stderr.

After a few years of writing JSON APIs for various purposes, with more success than this article may lead you to believe, I have come to the conclusion that the JSON support in the wider Go ecosystem is broken. And it isn’t really Go’s fault, but fixing it so it plays nice with other very common programming languages is something that hasn’t been given much consideration to.