This is a review of an article (calling itself a guide, or is it a manifesto?): The Grug Brained Developer

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

Also I highly applaud it's writing style (hello Pygmy) - 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 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 & 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, 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 and Chesterton 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 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 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 is explained very well, also closures, concurrency & optimising, all of which are aspects of tackling complexity which can get out of hand (i.e. become complex themselves).

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 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, FOLD & impostor syndrome are pretty accurate descriptions of issues in developer psychology.

🤷 Neither here nor there

The bit about 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 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 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 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 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 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 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 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!