Grug help think programming

It’s been a long time since I read an article about programming with a constant smile on my face.

Grug is like most of us, not a big-brain developer, but a simple caveman who wants to write code of decent quality and get things done.

Grug isn’t that smart, but that might be his superpower. There is much wisdom in the text.

For me, it took a few minutes to sink into Grug’s way of expressing himself, but it’s worth it!

Read the full article at grugbrain.dev

Here are some golden nuggets from Grug:

Complexity

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

Saying no

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

no, grug not build that feature
no, grug not build that abstraction

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

sad but true: learn “yes” then learn blame other grugs when fail, ideal career advice

Factoring Your Code

not factor your application too early!

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!”

instead grug try to limit damage of big brain developer early in project by giving them thing like UML diagram (not hurt code, probably throw away anyway) or by demanding working demo tomorrow

working demo especially good trick: force big brain make something to actually work to talk about and code to look at that do thing, will help big brain see reality on ground more quickly

Chesterton’s Fence

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

grug not say no improve system ever, quite foolish, but recommend take time understand system first especially bigger system is and is respect code working today even if not perfect

Tools

grug love tool

good debugger worth weight in shiney rocks, in fact also more: when faced with bug grug would often trade all shiney rock and perhaps few children for good debugger and anyway debugger no weigh anything far as grug can tell

grug always recommend new programmer learn available debugger very deeply, features like conditional break points, expression evaluation, stack navigation, etc teach new grug more about computer than university class often!

Type Systems

grug very like type systems make programming easier. for grug, type systems most value when grug hit dot on keyboard and list of things grug can do pop up magic. this 90% of value of type system or more to grug

always most value type system come: hit dot see what grug can do, never forget!

Separation of Concerns

Separation of Concern (SoC) another powerful idea over many developer mind

here grug much more sour faced than DRY and in fact write big brained essay on alternative design principle locality of behavior (LoB) against SoC

grug much prefer put code on the thing that do the thing. now when grug look at the thing grug know the thing what the thing do, always good relief!

Logging

grug huge fan of logging and encourage lots of it, especially in cloud deployed. some non-grugs say logging expensive and not important. grug used think this way no more

grug tips on logging are:

• log all major logical branches within code (if/for)
• if “request” span multiple machine in cloud infrastructure, include request ID in all so logs can be grouped
• if possible make log level dynamically controlled, so grug can turn on/off when need debug issue (many!)
• if possible make log level per user, so can debug specific user issue

Optimizing

ultra biggest of brain developer once say:

premature optimization is the root of all evil

grug recommend always to have concrete, real world perf profile showing specific perf issue before begin optimizing.

never know what actual issue might be, grug often surprise! very often!

APIs

API creators think too abstract and big brained

usually grug not care too deeply about detail of api: want write file or sort list or whatever, just want to call write() or sort() or whatever

but big brain api developers say:

not so fast, grug! is that file open for write? did you define a Comparator for that sort?

grug find self restraining hand reaching for club again

not care about that stuff right now, just want sort and write file mr big brain!

Front End Development

some non-grugs, when faced with web development say:

I know, I’ll split my front end and back end codebase up and use a hot new SPA library talking to a GraphQL JSON API back end over HTTP (which is funny because I’m not transferring hypertext)

now you have two complexity demon spirit lairs

grug not like big complex front end libraries everyone use

grug make htmx and hyperscript to avoid

keep complexity low, simple HTML, avoid lots javascript, the natural ether of spirit complexity demon

maybe they work for you, but no job post, sorry

react better for job and also some type application, but also you become acolyte of complexity demon whether you like or no, sorry such is front end life

Fear Of Looking Dumb

note! very good if senior grug willing to say publicly: “hmmm, this too complex for grug”!

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!

Impostor Syndrome

grug note many such impostor feels in development

now, grug make softwares of much work and moderate open source success , and yet grug himself often feel not any idea what doing! very often! grug still fear make mistake break everyone code and disappoint other grugs, imposter!

is maybe nature of programming for most grug to feel impostor and be ok with is best: nobody imposter if everybody imposter

any young grug read this far probably do fine in program career even if frustrations and worry is always to be there, sorry