Proud to be a Grug
Tags: codequality, testing, articlereview
Published: 2023-01-04 00:36:00

---
title: Proud to be a Grug
published: true
description: Breakdown review of grugbrain.dev
tags: codequality, testing, articlereview
cover_image: https://grugbrain.dev/grug.png
published_at: 2023-01-04 00:36 +0000
---

This is a review of an article (calling itself a guide, or is it a manifesto?): [The Grug Brained Developer](https://grugbrain.dev/)

First off, I agree with a staggering majority of statements!  

Also I highly applaud it's writing style (hello [Pygmy](https://en.wikipedia.org/wiki/Pygmy_(novel))) - the broken, stripped-down 1sentence=1paragraph English makes it strangely more readable than most IT texts (or maybe it's very late).

I broke this down into three parts:

1. ✅ I like 100% for things which ... I like 100% with short explanations why
2. 🤷 Neither here nor there for things which I think the author didn't clearly state their position on or possibly I didn't understand it
3. 🫤 not 100% for mixed stuff which I have serious doubts about and I dig into it

Let's go.

## ✅ I like 100%

[Complexity](https://grugbrain.dev/#grug-on-complexity) in no unclear terms asserts that "complexity spirit demon" is bad. That's it. 100% correct. No point in musing about accidental vs. intentional complexity. It's all bad.

Saying [No](https://grugbrain.dev/#grug-on-saying-no) & [OK](https://grugbrain.dev/#grug-on-saying-ok) are very nice descriptions of the ideal & realistic tools to handle the complexity problem. I like the 80/20 (although don't take the numbers seriously) rule & especially not dumping the *entire* truth on non-techies.

[Factoring](https://grugbrain.dev/#grug-on-factring-your-code), aside from the nice touch of accuracy in calling it factoring without the superfluous re, has very valuable advice in not taking it too far - you don't yet know in what direction the code will go and you're in danger of factoring yourself out of readability.

Similarly [Refactoring](https://grugbrain.dev/#grug-on-refactoring) and [Chesterton](https://grugbrain.dev/#grug-on-chestertons-fence) are very nice, although I have a feeling the author separated "factoring" & "refactoring" to two pretty different contexts (improving code locally & globally, respectively) the examples (J2EE & OSGi) & advice are dead-on.

[Microservices](https://grugbrain.dev/#grug-on-microservices) tells it succinctly, reminding me of the question: If you can't factor your codebase properly, what makes you think putting network calls in the mix will improve things?

[Type systems](https://grugbrain.dev/#grug-on-type-systems) section is a nice warning to not go too far with them. We're not researching new branches of maths here, we're trying to build software.

[DRY](https://grugbrain.dev/#grug-on-dry) is explained very well, also [closures](https://grugbrain.dev/#grug-on-closures), [concurrency](https://grugbrain.dev/#grug-on-concurrency) & [optimising](https://grugbrain.dev/#grug-on-optimizing), all of which are aspects of tackling complexity which can get out of hand (i.e. become complex themselves).

[APIs](https://grugbrain.dev/#grug-on-apis) section is OK, albeit a bit specific while being unclear at the same time. Is the author not happy with Java APIs? So is *this* author! Switch to Typescript & Kotlin! 😉

[Parsing](https://grugbrain.dev/#grug-on-parsing) is also touched upon in this (apparently very broad) guide. I almost put it in Neither here nor there, but gave it a 2nd read and liked it: Basically, complexity is the enemy (again). Keep it simple.

In the end of the guide, [fads](https://grugbrain.dev/#grug-on-fads), [FOLD](https://grugbrain.dev/#grug-on-fold) & [impostor syndrome](https://grugbrain.dev/#grug-on-imposter-syndrom) are pretty accurate descriptions of issues in developer psychology.

## 🤷 Neither here nor there

The bit about [Agile](https://grugbrain.dev/#grug-on-agile) has nothing really of note ... The Agile concept has a *lot* of potential. If done right it can completely transform people and companies they work in for the better. Tech practices like automated testing (and test-first practices like TDD) can seriously help in this.

[Separation of concerns](https://grugbrain.dev/#grug-on-soc) is in my view misrepresented by an erroneous example of separating HTML, CSS & JS while the proposed solution (Locality of behaviour) is *actually* what SoC *is*. So, we basically agree on the principle but not the naming which I don't care about anyway.

The [visitor pattern](https://grugbrain.dev/#grug-on-visitor-pattern) has only "bad" with link to the Wikipedia article, so not much to go on here ... for what it's worth, I don't see much use for the pattern in modern languages and architectures.

The section on [frontend development](https://grugbrain.dev/#grug-on-front-end-development) reminds me of a simplified take of a mostly-backend developer. Today's frontends are apps in themselves & and their complexity is simply the result of mounting user expectations arising from explosion of app users with the majority of them being quite non-tech.

## 🫤 not 100%

In the [Testing](https://grugbrain.dev/#grug-on-testing) section I like the non-mocking part.

Also I *kind* of like & agree with the "small, well curated end-to-end test suite" + "integration test sweet spot" *if* by "integration tests" the author means deployable-level (backend-only, frontend-only) acceptance tests which don't focus on implementation details but on behaviour.

However, using them with a lot of debugger action is just a sign of missing unit tests (which is clear from the other parts of the section). Having good unit tests (and lots of them, especially on backend, which the author is apparently at home in) is a life-saver when writing acceptance tests since the acceptance tests can also be narrow and focused - as they should, since they're harder to write and slower to execute.

[Tools](https://grugbrain.dev/#grug-on-tools) is basically a call for debugging. To me frequent debugging is a sign of missing unit tests (see previous paragraph) and shows room for improvement in your testing strategy.

The [Expression complexity](https://grugbrain.dev/#grug-on-expression-complexity) section is just a specific example of an "optimise code for debugging" strategy, although the specific "good" example strikes me as more readable than the "bad" one. Nevertheless, I wouldn't recommend optimising your code for anything other than readability.

Likewise, [logging](https://grugbrain.dev/#:~:text=grug%20be%20frank-,Logging,-grug%20huge%20fan) is also an example of trying to improve things where unit tests (and possibly "integration" tests, or rather acceptance tests) are lacking. A well-tested deployable has to have logging only for input & output traffic. Logging "all major logical branches within code (if/for)" is just crazy.

# Conclusion

I like Grug. They're headed mostly in the right direction regarding principles and mindset. Unfortunately, automated testing is hard to get right but when you do the payback is more than handsome!