Blog: Grug Brained Developer Make Sense                  

A colleague pointed me at the grugbrain.dev website the other week. It is a very humorous set of observations on corporate life and advice to young developers – written in a silly “cave-man” style. It is obviously based on long experience. The text is also quite quote-worthy, with some passages even being quite poetic in their rough-hewn simplicity.

Fear Complexity!

The main point of the Grug is to fear complexity and avoid it if at all possible. Complexity is consistently referred to as a spirit or demon that infects the code and makes it hard to change and easy to break.

given choice between complexity or one on one against t-rex, grug take t-rex: at least grug see t-rex

In the opinion of grug, complexity sneaks in invisibly from good intentions. Especially from “big brain developers” that create complex solutions just because that is how they do things.

complexity is spirit demon that enter codebase through well-meaning but ultimately very clubbable non grug-brain developers and project managers who not fear complexity spirit demon or even know about sometime

I can very much agree with the sense that some code or its design is clubbable. When I spot something bad in code, it does indeed feel like you either want to take a club to the code, or whoever was responsible for creating it in the first place.

And fear concurrency. Totally agree:

grug, like all sane developer, fear concurrency

Saying No!

Another observation that I fully agree with is the need to say “no”. That is what defines a good designer (and a good product manager). A software product is only a software product if it is possible to say “no” to certain feature requests, or even decline entire customer engagements. If there is no choice from the development team, what you have is a software service or bespoke software. Not a product.

Saying yes to all feature requests is going to end up with a big complex mess.

best weapon against complexity spirit demon is magic word: “no”

“no, grug not build that feature”

“no, grug not build that abstraction”

“no, grug not put water on body every day or drink less black think juice you stop repeat ask now”

note, this good engineering advice but bad career advice: “yes” is magic word for more shiney rock and put in charge of large tribe of developer

But the last paragraph is also true. It is much easier to be popular saying yes. And sometimes it is necessary for non-technical reasons.

sometimes compromise necessary or no shiney rock, mean no dinosaur meat, not good, wife firmly remind grug about young grugs at home need roof, food, and so forth, no interest in complexity demon spirit rant by grug for fiftieth time

Chesterton’s Fence

The best part is the piece I think was on Chesterton’s fence. I had not heard about that parable before, and while it originally applied to politics and religion, it makes perfect sense for (almost) everything else. The idea is that you should not effect change until you understand why things are as they are – there might be a very good reason that is not immediately obvious. Investigate the underlying design and reasons before arguing for changes.

Just making changes without understanding is not likely to end well.

many older grug learn this lesson well not start tearing code out willy nilly, no matter how ugly look

grug understand all programmer platonists at some level wish music of spheres perfection in code. but danger is here, world is ugly and gronky many times and so also must code be

That is sheer genius. Software exists to solve real-world problems, and the real world is rarely neat. The structure of a piece of software is inevitably related to the structure of the problem being solved.

grug early on in career often charge into code base waving club wildly and smash up everything, learn not good

Indeed.

Fear of Looking Dumb

Another deep insight into the psychology of programming is the fear of looking dumb. This can easily silence relevant critiques of a design – just saying “I don’t understand this” could just as well be seen as admitting to a personal shortcoming (i.e., being dumb) as a failure of the design. While it could well be the design that is at fault and really is not easy to understand.

The Grug points out the key that senior developers and architects and others have a key role to play. They must be willing to admit that they think things are too complicated. This encourages junior team members to also speak up.

many developers Fear Of Looking Dumb (FOLD), grug also at one time FOLD, but grug learn get over: very important senior grug say “this too complicated and confuse to me”

this make it ok for junior grugs to admit too complex and not understand as well, often such case! FOLD major source of complexity demon power over developer, especially young grugs!

I have seen the fear of looking dumb in action many times. It rarely ends well.

Premature Abstraction

The grug goes on to talk about how to properly split a code base (factoring) and insists that this should only be done after developing at least some code and getting a better understanding for what the problem looks like. Trying to set up cut points/interfaces too early will most likely result in bad design decisions.

grug try watch patiently as cut points emerge from code and slowly refactor, with code base taking shape over time along with experience. no hard/ fast rule for this: grug know cut point when grug see cut point, just take time to build skill in seeing, patience

sometimes grug go too early and get abstractions wrong, so grug bias towards waiting

big brain developers often not like this at all and invent many abstractions start of project

grug tempted to reach for club and yell “big brain no maintain code! big brain move on next architecture committee leave code for grug deal with!”

It is very tempting to set up abstractions early on, but unless you are very good at what you do (or this is the second try at solving the same problem), early solutions are very likely to be wrong.

The right way to develop (according to the grug brain, and I tend to agree) is to start with a prototype, learn the problem domain, and then build the real thing based on the learnings. That methodology seems to work in all kinds of domains, not just programming.

Microservices

Pure gold.

grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too

Methodology Shamans

One thing that comes up a couple of times is the skepticism towards methodology experts… called shamans.

unfortunately also many test shamans exist. some test shaman make test idol, demand things like “first test” before grug even write code or have any idea what grug doing domain!

And:

danger, however, is agile shaman! many, many shiney rock lost to agile shaman!

whenever agile project fail, agile shaman say “you didn’t do agile right!” grug note this awfully convenient for agile shaman, ask more shiney rock better agile train young grugs on agile, danger!

grug tempted reach for club when too much agile talk happen but always stay calm

Totally agree. Going overboard and getting religious about methodologies does not work. Real problems are not black-or-white, but always shades of grey. Most methodologies contain really good ideas, but there is no harm in borrowing a little here and there and making up something that works for your team.

Testing

The grug opinion on testing does not quite agree with mine. The grug-brained developer prefers to use tests involving a small number of modules. Not the smaller unit tests, nor the hairy end-to-end tests.

in-between tests, grug hear shaman call “integration tests” sometime often with sour look on face. but grug say integration test sweet spot according to grug: high level enough test correctness of system, low level enough, with good debugger, easy to see what break

also, grug dislike mocking in test, prefer only when absolute necessary to (rare/never) and coarse grain mocking (cut points/systems) only at that

I guess it depends on the reuse of modules. I kind of like the elegance of extensive mock-based unit tests for modules that are intended to be truly reused (such as virtual platform hardware models). Maybe less so if it is just some pile of code that gets compiled into a program statically. But for dynamically loaded modules, mock-based tests are pretty necessary.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.