Code that fits in Your head

Cognitive complexity is a software quality metric (popularized by SonarSource) that measures how challenging the code is for a programmer to understand ¹. For simplicity, we’ll assume that the cognitive complexity rises with every written line of code. The more lines of code a given program has, the harder it is for the programmer to understand, add new features or fix existing bugs. You can’t really fix code that You don’t understand.

“One of our many problems with thinking is ‘cognitive load’: the number of things we can pay attention to at once. The cliché is 7±2, but for many things it is even less. We make progress by making those few things be more powerful.” - Alan Kay

Writing programs is hard. With each written line of code two things happen at the same time: the overall cognitive complexity rises, and the number of bugs also rises ². In the current programming era we use LLM (large language models aka AI) for generating code practically every day now. We have agents embedded in our favourite IDEs ³. We use agents to solve different programming issues, unblock us in our work. But most commonly to generate lots of code.

How is a programmer expected to read and understand all of it? It takes a long time to build a mental model of newly generated code, and if it’s not correct, we adjust the prompt and get a fresh iteration of the code. Where we gain time in LLM code generation, we lose time in going through the generated code and trying to understand it. In the end it usually evens out, but only if the programmer is skilled ⁴. Oh, and there is also a phenomenon called LLM hallucinations… ⁵.

The Go language was created by Google engineers Robert Griesemer, Rob Pike, and Ken Thompson to reduce a cognitive load on the programmer, to make catching bugs easier and to make large systems maintainable. Go was designed to improve programming productivity in an era of multicore, networked machines and large codebases. The design was primarily motivated by the dislike of C++ language ⁶ which has 1300 pages of documentation ⁷ and is really complex.

”…About the same time that we were starting on go I read or tried to read the uh C++ 0x proposed standard, and that was the convincer for me”, Ken Thompson

The Go language has a unique approach to code structure. If forces programmers to produce code with low cognitive complexity by using a “Happy Path” approach ⁸. Basically, it means that the correct program execution path should always be as close to the left side of the editor as possible. Programmer should be able to quickly scan down one column and immediately understand the expected execution flow. One of the direct results of that is a preferrence to use simple if statements or even switch statements (which I just love BTW) if checking for multiple conditions and completely avoid else clause. Function should check for all exit conditions early and do not hide any happy path inside the nested code blocks. These rules (among some others), allow us to create code that can fit in our heads.

“Everything should be made as simple as possible, but not simpler”, Albert Einstein

Go is a language with a minimal set of features. But these features serve as building blocks for more complex ones. These additional features are provided by packages (and there are hundreds of them) ⁹. Code written in Go should be boring, simple, repeatable and easy to understand. There are patterns that Go programmer should follow and use constantly (like well known if err != nil idiom). Such predictable code is called idiomatic ¹⁰. When Go code is read, it creates a state of execution flow that the programmer can track almost intuitively. Every language construct that is not expected or out of the ordinary (not idiomatic) should be questioned. This approach makes Go programmers very efficient. Usually there is only one way to do things ¹¹.

Conclusion

The Go language provides a way to understand even the most complex projects by building them from minimalistic, repeatable blocks that are easy to understand in isolation. Go provides an entire ecosystem of tools that improves code generation, software creation, performance tracking, benchmarks and testing framework ¹². At the end of the day, the programmer is confident that the software written is simple, easy to understand by other programmers, efficient and thoroughly tested. At the end of the day we can say we were productive.

“We’re really bad at writing software.”, Jon Bodner