Headache of Code
Cognitive complexity is a software quality metric that measures how challenging is the code to understand 1. For simplicity, we’ll assume that it 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, adjust it or fix it. 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 2. In the current programming era we use LLMs for generating code daily. We have agents embedded in our favourite IDEs 3. The thing with LLMs is that they produce lots of lines of code. How is a programmer expected to read and understand it all? It takes time. Where we gain time in LLMs 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 4. And don’t even get me started on the LLMs hallucinations… 5.
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 6 which has 1300 pages of documentation 7 and is really complex.
“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) 8. Code written in Go should be
boring, simple and repeatable. There are patterns that Go programmer should follow and use constantly (like well known
if err != nil). Such predictable code is called idiomatic 9. When Go code is read, it creates a state of
flow that the programmer can track almost intuitively. Every language construct that is not expected or out of the
ordinary should be questioned. Go code should be written in paragraphs that are easy to understand and simple. This
approach makes Go programmers very efficient. Usually there is only one way to do things 10.
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 11. 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
- https://getdx.com/blog/cognitive-complexity
- https://stackoverflow.com/a/56043694/1449403
- https://www.jetbrains.com/junie/
- https://www.reddit.com/r/ClaudeAI/comments/1qy4yhu/for_senior_engineers_using_llms_are_we_gaining/
- https://medium.com/@nirdiamant21/llm-hallucinations-explained-8c76cdd82532
- https://www.youtube.com/watch?v=c-P5R0aMylM
- https://cppreference.com/
- https://pkg.go.dev/
- https://go.dev/doc/effective_go
- https://go.dev/ref/spec
- https://go.dev/blog/pprof