Go: Baseline Testing

The Other Bob
Feb 21 · 4 min read

It was a stressful week. Several services written in legacy languages (C++ or Java) started acting up and had to be refactored into microservices written in Go.

For those of you who don’t know, Go is a programming language with a focus on concurrency and simplicity. Let me briefly explain both terms. Concurrency is a programming jargon for peforming tasks in parallel. This is something Go excels at. Whatever your concurrency needs, be it socket I/O or socket I/O, Go is optimized to do it efficiently (as long as it’s socket I/O).

Simplicity is a more general concept where Go by design doesn’t adpot loads and loads of features routinely adopted by other languages (C++, Java, C#, Python, Rust, …). The problem with many of these features is that they are rarely useful outside of university research, in real world, especially if you want to just Get Sh*t Done. The main problem with those features is that they cause significant cognitive load, which is something you want to avoid at all costs. I mean, sure, those features might be useful for research stuff like designing algorithms or data structures, but let’s face it, are you going to really need that in real life? No, not really. You’re not going to design algorithms or data structures. You’re not even going to write code that cares very much what data structures or algorithms are used. Odds are (95%+) that you’re going to write code that fetches some data from a database and writes them out onto a http connection, or a similar task.

The takeaway here should not be that the other languages I mentioned are bad, it’s rather that one should always use the right tool for the job. And if the job itself is rather simple, using a complex tool and learning new things is not only unnecessary, but even harmful, as it gets in the way of Getting Sh*t Done. It would be like using a Dremel to open a can. Sure, Dremel is a nice and versatile tool, but it’s also complex and requires complex set of accessories, which one could spend years on mastering. A tool like that might make sense for some complex construction job. But not everyone works on a job like that, few people do, in fact. And so if you just need to open a couple of cans (and odds are that you are, statistically speaking), then a simple low-cognitive-load tool — such as a can opener — is preferable.

However, the temptation of the complex tools is very dangerous:

Many people are naturally prone to learning new things.

And what’s worse, often not out of the requirement to Get Sh*t Done, but rather out of curiousity, interest or other such whims. When trying to keep things simple, this is very dangerous. You don’t want that. If your colleagues are learning new things, it’s a sign that your bussiness might be in trouble. Soon enough they’ll start writing “clever code”, unreadable for other people and dreadfully distinct from idiomatic code.

Which is why our startup has adopted baseline testing recently to spot these red flag signs early and proceed accordingly.

When facing stress, one’s defenses are low. This is why we’re taking the baseline test at least weekly.

Transcript of my last baseline test

commander: “Officer Bob, let’s begin. Ready?” Me: “Yes, sir.” commander: “Recite your baseline.” Me: “And blood-black complexity began to spin… A system of classes interlinked within classes interlinked within classes interlinked within one JAR… And beautifly simple against the dark, a tall white fountain played.” commander: “Code.” Me: “Code.” commander: “Have you ever been in a corporation? Code.” Me: “Code.” commander: “Do they keep you in a cubicle? Code.” Me: “Code.” commander: “When you’re not performing your duties do they keep you on call? Code.” Me: “Code.” commander: “Simplified.” Me: “Simplified.” commander: “What’s it like to hold a pointer guaranteed to not be nil? Simplified.” Me: “Simplified.” commander: “Did they teach you how to use sum types? Simplified.” Me: “Simplified.” commander: “Do you long for having your types parametrized? Simplified.” Me: “Simplified.” commander: “Do you dream about interfaces and implementors being interlinked? Simplified.” Me: “Simplified.” commander: “What’s it like to hold your data immutably in your arms? Simplified.” Me: “Simplified.” commander: “Within code simplified.” Me: “Within code simplified.” commander: “Why don’t you say that three times: Within code simplified.” Me: “Within code simplified. Within code simplified. Within code simplified.” commander: “We’re done. Officer Bob, you may pick up your bonus.” Me: “Thank you, sir.”

Note: We call our scrum masters ‘commanders’. I think it’s fitting. But we always spell that with lowercase ‘c’ out of reverence for The Commander, the wise, who is and will ever only be one, long may be His reign, and may he deliver us from complexity both now as well as in Go2.

The Other Bob

Written by

Software engineer, Entrepreneur, Founder, Consultant, Teacher, Influencer, Builder, Father of 5, Mother of 4, Freeride snowboarder, Humility advisor