The Grug Brained Developer

by huimang • 4 years ago

1068 374 4 years ago

tines• 4 years ago

As a grug-brained developer, I love the spirit of this, but it's kinda hard to read. Maybe the author can publish an English translation? :)

andrepd• 4 years ago

grug think grugposting is part of the charm

layer82• 4 years ago

Grug thinks there would be middle course keeping most of charm but less exhausting to read.

bitwize• 4 years ago

This reminds me rather of a cross between "Code Monkey" (Jonathan Coulton song) and Film Crit Hulk Smash.

egypturnash• 4 years ago

BE THANKFUL GRUG NO TYPE IN ALL CAPS LIKE FILM CRIT HULK, FILM CRIT HULK HAVE MANY THOUGHTFUL POINTS TO RAISE ABOUT FILMS SND STORIES BUT ALSO READING ALL CAPS FOR MORE THAN ABOUT ONE PARAGRAPH IS OUCHY

(Film Crit Hulk released a book; half of it was in all caps, the other half was the exact same text except in normal sentence case.)

raphlinus2• 4 years ago

I might be willing to give this a shot. I appreciated the charm and humor in the original, but especially for readers who don't have English as a first language it probably gets in the way of the message.

raphlinus2• 4 years ago

Here are the first few sections: https://gist.github.com/raphlinus/f6b34f85d63c4b73a0242481ed...

I'll keep going if there's positive feedback, delete it if the author doesn't appreciate it.

crooked-v3• 4 years ago

On the other hand, I'd be interested in seeing a 'ten hundred most common words' version of it that dumps those complicated words like 'refactor'.

reidjs• 4 years ago

https://github.com/reidjs/grug-dev-translation

Translated as best I could

whoomp12342• 4 years ago

this is nothing short of amazing

throwawayacc2• 4 years ago

Grug no read good but grug fink is good advice here

genjipress• 4 years ago

You've heard of Film Crit Hulk? Here's Software Dev Hulk.

whiskeytuesday• 4 years ago

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 code so also must. humility not often come big brained or think big brained easily or grug even, but grug often find "oh, grug no like look of this, grug fix" lead many hours pain grug and no better or system worse even. grug early on often charge into code base waving club wildly and smash up everything, learn not good
grug not say no improve system ever, quite foolish, but recommend take time understand system first especially bigger system is and respected code working today even if not perfect

grug read this and grok spirit, grug enlightened. master not club grug so much.

Rantenki• 4 years ago

Grug state Chesterton's fence very easy understand way.

odipar• 4 years ago

big brain really like post. lesson learn is deep!

"(best grug brain able to herd multiple big brain in right direction and produce many complexity demon trap crystals, large shiney rock pile!)"

tboyd47• 4 years ago

The advice is fantastic! Fear the club.

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!"
grug tempted reach for club when too much agile talk happen but always stay calm

TranquilMarmot• 4 years ago

I think this nicely captures everything I've learned about programming over the past n years that I wish other people would realize too.

eurasiantiger8• 4 years ago

What have been the most complex business requirements for a project you have worked on, and what made them complex? Was the resulting system less complex than the requirements?

residualmind4• 4 years ago

Sorry to hijack without being asked. I totally agree with the original piece and this comment. For me the most important part is: no matter how complex your requirements are, how you deal with complexity and abstraction in your codebase and architecture, will make or break it. Abstractions should match what's actually happening (with just the minimal right amount of future telling). Useless abstractions and missing abstractions are both bad. Getting rid of a bad abstraction in a system is harder than introducing one, though. Erring on the side of fewer abstractions and dumber (not bad, just boring) code especially in early stages can save you literally thousands of hours of debugging, fixing, scratching your head. I may be wrong, this is how I feel right now.

arbenpurben• 4 years ago

This makes me so happy

jamal-kumar• 4 years ago

smol brain can dodge [1]

[1] https://preview.redd.it/g1lpdmt1iiv51.jpg?auto=webp&s=a5f27c...

GrumpyNl• 4 years ago

That's a great write up.

csours• 4 years ago

Even big brain developer is grug brain when read code later.

pixelrevision2• 4 years ago

Big brain no read later code. Big brain go to conference.

weeeeelp• 4 years ago

Big brain developer go to new tribe to paint new cave for shiny rock, leave old cave with grug

euroderf• 4 years ago

Grug brain see grug code later. Grug brain say to grug: this code not grug code. Grug scratch head, kill favorite flea. Grug must grok old grug code but get no shiny rock for grok own old grug code. Grug sad, say to grug, next time make grug code more good. Grug boss say: no time, grug do as grug boss say. Grug lift rock, want tell grug boss stuff it. Grug not tell. Grug frustrated. Grug ask more snacks in work cave. Grug ask Aeron butt hammock.

mcbishop• 4 years ago

that grug say many variables good. make this grug many happy.

layer82• 4 years ago

put explicit type on variable even more good for read code

agentultra3• 4 years ago

Ah, the ample club of wishful thinking.

There are two general ways of approaching software design (and I'm paraphrasing Tony Hoare here):

1. You can write software so simple there are obviously no errors

2. You can write software so complex there are no obvious errors

One thing that escapes "grug" is that achieving 1. often requires more sophistication than their magical club allows. Most well-intentioned "grug" developers will write software so simple that it becomes it's own form of complexity: a giant mud-ball of for-loops, while-loops, variable assignments, and other wonderful side effects. Instead of addressing complexity head-on with abstraction, "grug" will beat "galaxy brain" over the head.

What grug fails to understand is that simplicity isn't easy or familiar. It doesn't mean "sticking to what you know." If often requires being able to reason about programs and to verify that reasoning!

But go ahead grug... keep beating people over the head with the club and hope that the complexity will go away.

recursivedoubts2• 4 years ago

^ sound convince and probably very big brain right at times

however!

beware apply advice put form data from web page into database with many layers abstraction not needed! grug see many time!

fear of looking dumb (FOLD) great danger in such conversations and beware!

jjoonathan• 4 years ago

It will go away -- to other devs, who will awkwardly and painfully route around grug, adding loads of complexity. Not grug's complexity, though!

lijogdfljk2• 4 years ago

Most well-intentioned "grug" developers will write software so simple that it becomes it's own form of complexity: a giant mud-ball of for-loops, while-loops, variable assignments, and other wonderful side effects. Instead of addressing complexity head-on with abstraction, "grug" will beat "galaxy brain" over the head.

Hah. Related, i became disgruntled with my previous favorite language for this reason. It promoted this style of development. Surface level simplicity built into the language, with minimal tools to actually manage the complexity that is inherent to the problem space you're working in.

short_sells_poo• 4 years ago

Alright I'll bite :)

Python? Java? C? Assembly?

pharmakom• 4 years ago

Python is this. Complex made easy (in Rich Hickeys terminology)

kazinator2• 4 years ago

Software in category (1) and (2) can be of any relative size.

1 could be 50,000 lines, 2 could be 500.

frostwarrior• 4 years ago

That's the classic "only coder" mindset. Instead of being uncomfortable learning about software architecture, side effects or even pure functions, tries to solve every problem with for and while loops.

WesolyKubeczek2• 4 years ago

Sir, may I remind you that when you get down to it, your architecture and higher order functions are all made of branching and for and while loops, and branching and for and while loops are all made of goto.

titzer4• 4 years ago

Undoing someone's copy-pasted for-loops and while-loops is called "factoring" and undoing someone's bad abstractions is called "re-factoring" and is about 10x as slow. At this point in my career I have seen way more crappy abstractions and needlessly abstracted code than grug-brain code.

And, to be brutally honest, as much as I love those functional combinators, first-class functions, streams, etc, they suck to reason about.

Sometimes loops are better!

eurasiantiger8• 4 years ago

I think you found the head of the nail, so let me hit it:

”Simple” code is simple to reason about, but it is not as expressive.

”Complex” code is just as simple to reason about, but being more expressive, it requires more intimate knowledge of the language features and abstractions used.

Then there is ”bad” code, which is confusing for reasons other than domain complexity.

Sometimes complexity just gets handed to a developer even if they say no, and that doesn’t make their complex code bad code.

stonecolddevin• 4 years ago

I personally almost always use loops (in Java) unless I know the dataset being dealt with is small, unless I'm writing stuff in Scala where maps and flatMaps are first class, but diving into Scala is its own can of worms.

lmm6• 4 years ago

And, to be brutally honest, as much as I love those functional combinators, first-class functions, streams, etc, they suck to reason about.
Sometimes loops are better!

That I think is backwards. A loop could be doing literally anything - it probably is futzing with global variables - so there's no way to reason about it except by executing the whole thing in your head. A map (or mapA) or a fold (or foldM) or a filter or a scan is much more amenable to reasoning, since it's so much more specific about what it's doing even without looking at the body.

joshuamorton• 4 years ago

I've seen a massive, "simple", abstraction-free function of 500-1000 lines take smart engineers quarters to safely "factor". I've seen this same thing happen a handful of times. Big spaghetti function requires someone to build a new test suite from scratch so that they can refactor safely, because everything ends up having spooky surprising distant effects, because there isn't any abstraction to contain things.

They're dead simple, there's no abstraction, its just loops and variables (and state, which is the real killer). But they're impossible to reason about as a result.

dahdum• 4 years ago

As usual the truth is somewhere in the middle. I’ve seen nearly $1m in development cost and a year of time lost to the complexity demon due to big brains playing AWS Service Bingo while a competitor hired a single grug to do the same task.

That single grug got it done in ~1 month for basically nothing, and without the multiple AWS service overhead it ran much faster, fewer resources, and dead simple to maintain. Bigger company bought the smaller one, then proceeded to toss the grug code and continue the big brained approach, as far as I know never reaching parity.

But there were cool network diagrams, data diagrams, and all sorts of new, interesting, and complex technology developers enjoy playing with.

I’m more inclined to side with grug now.

joe_the_user• 4 years ago

The OP's point is that being able to produce a simple solution to a complex problem only seems like the product of "refusing to be smart" from the outside. From the inside, there's always a delicate balancing act - each step involves choosing approaches that may generate complexity just in different ways. The same data used in different places in the application? What do you do? Objects? Globals? Cut-and-paste. Any of those solutions might be fully justified or might degenerate into a tangle by the time the application is done. Once, if you have a nice, simple working application, you can say "it's all just 'grug'" but that's essentially what they a call "humble brag".

jfoutz• 4 years ago

could you give an example of (1)?

Only because i have run into weirdness with printf calling malloc, back in the day. Even hello world makes me a little nervous about those claims.

But I'd love to see a sample with explicit assertions about the environment, so I could be sure there are obviously no errors.

nonethewiser• 4 years ago

You're focusing on coding style but it sounds more like hes talking about business requirement.

If we are talking about coding style, then the things you have identified as actually not simple are by definition not what the article favors.

ImprobableTruth• 4 years ago

I think the post actually touches on this? It doesn't say that you shouldn't abstract, just don't abstract too early.

coldtea• 4 years ago

There are two general ways of approaching software design (and I'm paraphrasing Tony Hoare here): 1. You can write software so simple there are obviously no errors 2. You can write software so complex there are no obvious errors

And both are neither here, nor there, regarding what the article talks about, which is basic advice that always holds: avoid complexity, say no whenever possible, opt for 80/20 solutions.

One thing that escapes "grug" is that achieving 1. often requires more sophistication than their magical club allows.

Which is irrelevant to grug's point, as he doesn't pretend to advocate achieving 1.

Barrin92• 4 years ago

Instead of addressing complexity head-on with abstraction, "grug" will beat "galaxy brain" over the head.

the argument made in the piece is more nuanced than that. The author points out that you often cannot address complexity head on (in particular not with abstraction), because you don't even know what your complexity looks like, as the author says, complexity isn't trivial to see.

This was the old problem of inheritance as a paradigm which tried to anticipate structure of programs and code when often you can't anticipate what shape your program is going to take, often leaving you in dead ends and wrong hierarchies or taxonomies.

The author isn't saying to not abstract at all but to not do it early. Casey from Handmade Hero had a similar style he called, IIRC 'compression' based programming, implying that you write your code, and as you go over it again and again you see where duplication pops up and only then you factor it out into some higher abstraction.

geekbird2• 4 years ago

This. Develop the logic and flow for all of the thing, make it big, code it simple and even redundant, but really basic and simple. That's your "proof of concept". Pass two is finding and factoring out all of the redundant stuff into functions and libraries, grouping like with like. It's like in relational database design - first you grab all the fields needed, then group them and normalize them.

agentultra3• 4 years ago

I can see where one can build upon that intuition. If one replaces “abstraction” with “indirection” it becomes apparent what is happening.

When programs are defined in terms of operational semantics, that is procedurally, it must still be reasoned about in some way if your goal is to write a program so simple there are obviously no errors.

Patterns of indirection are not abstractions. It’s a fine practice for controlling indirection in code! And highly effective. But it’s not what I mean by abstraction.

Abstraction enables new layers of semantics by completely encapsulating complexity. Think of function application in almost any procedural language that is compiled to some target machine language. The compiler has to generate a lot of code in the host language to manage memory segments, return pointers, etc. As the programmer using the language you don’t even think about it at all.

One doesn’t arrive at such an abstraction by writing a bunch of spaghetti code and encapsulating common patterns.

And that is often how one arrives at simple code. It’s not “simple” because it doesn’t require anyone to learn anything or work hard to understand it. It’s simple because once the abstraction is established and proven you’re free to think about bigger, more interesting ideas.

shams93• 4 years ago

Then there's the Super Mario developer, I putta all 50,000,000 lines of code into one a fantastic pasta bowl file just for a you!

pkulak• 4 years ago

Whoa now, I was with you until you seemed to imply that "simple" software means shitty code. Simple in this context means a solution with as little complexity as possible. Hopefully written elegantly and carefully, with lots of thought for future maintenance and readability.

Maybe you use a 10-year-old, constantly maintained and thoroughly tested library to do 90% of the work instead of writing everything yourself.

Would it be faster to compute some end state without intermediate calculations? Probably. But how about we just spin a loop forward instead if it's more accurate that way and easier to understand.

What if we cached values, then made sure the caches are always in sync? That should speed things up. Well, maybe we'll write it without caching and see how that goes first.

How about an intricate system of locks and serializable transactions so that multiple requests can run at the same time? Or maybe we just queue things up and run them one at a time.

Nothing to do with nested for loops.

agentultra3• 4 years ago

Hopefully written elegantly and carefully, with lots of thought for future maintenance and readability.

Those are fine things to value even if they are highly subjective.

You might think it’s easier to read a while loop with a handful of mutating variables and a few branches. I might disagree.

I think it’s easier to read an accumulating function that uses traverse.

It’s wishful thinking that we should both hold the same values or that only one of us is right.

big brain type system shaman often say type correctness main point type system, but grug note big brain type system shaman not often ship code. grug suppose code never shipped is correct, in some sense, but not really what grug mean when say correct!

This big brain ships code every day.

Also streams big brain work in big brain language once a week to show people that it’s not the work of big brain shamans.

Big brain is happy to answer questions and help people learn.

femiagbabiaka• 4 years ago

I think of it as being more of a spectrum where abstractions get introduced as they're needed. The case where one has thousands of lines of imperative code that is terrible to debug and probably not unit tested is one where the correct abstractions were never introduced at the place and time they were appropriate. Getting this right is almost impossible, that's why we have refactoring practices.

emilsedgh• 4 years ago

a giant mud-ball of for-loops, while-loops, variable assignments, and other wonderful side effects. Instead of addressing complexity head-on with abstraction

I very much prefer to work in a codebase of poorly written loops and variable assignments rather than one with poor abstractions.

Poor abstractions can harm way, way more than spaghetti code. Their harm usually spreads out through system.

Imagine this:

* 1 single poorly written function which takes a number of inputs and has an output, but internally it's long and messy.

* A bunch of abstracted entities, which interact throughout the system, but are poorly designed.

The complexity of 1 is isolated to the implementation. There's a nice encapsulation. Removing/Rewriting is easy.

But 2 becomes a complete mess which is not isolated. You'd have to skin it layer by layer. Thats way more scary to me.

keerthiko• 4 years ago

a giant mud-ball of for-loops, while-loops, variable assignments, and other wonderful side effects.

Woah woah. This is literally the kind of complexity grug wants to avoid. Simple doesn't mean using the fewest language features or keywords, it means simple to read, follow along, reason about, and debug. Abstractions can aid in that (like using a third party library!), until they are imported/implemented aspirationally and thus often unnecessarily, and sometimes resulting in abstractions for abstractions, selective application of the abstractions vs fresh implementation, etc (...and thus AWS)

At no point does grug argue that you should stick to what you know, he just says you should trap your complexity in crystals ie literally suggesting to use the Good Abstractions, When They Make Sense.

rubinelli• 4 years ago

There is a lot of wishful thinking that goes into galaxy brain code. It assumes you know with almost complete certainty what rules are bound to change and where extension will be needed, that the next developer will be able to understand and respect the beautiful elegance of the design instead of hacking at it to achieve the desired result, and that the code will be long-lived enough to justify the initial investment. Grug coders aren't always inexperienced; many are actually repented architecture astronauts.

Too2• 4 years ago

As the idiom goes: Can’t see the forest for all the trees.

Sadly it’s often difficult to argue with someone using the complex=bad-club, because everybody knows complexity must be avoided - at all cost!!

What one should understand is the essential complexity of the problem, then design your solution around that, to control where the complexity goes and to not introduce accidental complexity. Blindly going complexity=bad will result in it popping up elsewhere later.

Many people as you say don’t even know what it means and use complex=bad for all kind of things they disagree with, including choice of tools or libraries. Using a library you don’t know is not complex, it is difficult, also something that should be avoided but that doesn’t make it the same thing. (Adding libraries and mixing competences can of course add complexity also, but let’s not get pedantic…)

whiddershins• 4 years ago

Microservices

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

seem very confusing to grug

Yes.

tharax• 4 years ago

This is perhaps the most succinct way I've ever seen this expressed. Agree 100%.

jstanley• 4 years ago

grug no able see complexity demon, but grug sense its presence in code base

This is the key problem with complexity.

Complexity is fine if you understand it! It's when you're aware that something is complex, but you start to get these mental force-fields pushing you aware from the scary parts, that it becomes a problem.

demon complexity spirit mocking him make change here break unrelated thing there what!?!

That's the happy case! The sad case is when you make a change and don't observe any obvious breakage, but then 3 years later you realise something you somewhat care about has been silently broken for a very long time.

nisegami• 4 years ago

but then 3 years later you realise something you somewhat care about has been silently broken for a very long time

The trick is to never stay somewhere long enough to feel the consequences of your bad decisions

collyw10• 4 years ago

Your reply made me smile, but it's the opposite that has given me my biggest learning experiences. Greenfield projects that you stay on a while. You only have yourself to blame when there are problems a few years in.

armatav• 4 years ago

Now this is a good post. Especially the part about the frontend Complexity Demon having a grip on the entire industry, and the Fear Of Looking Dumb. It goes hand in hand.

49531• 4 years ago

frontend Complexity Demon having a grip on the entire industry

Is frontend web development more complex than it needs to be? If so, how?

aaaaaaaaaaab• 4 years ago

Hehe, good one!

Oh, you're serious? :D

recursive8• 4 years ago

npm, babel, webpack, module compatibility, et al

collyw10• 4 years ago

Incredibly so. Our frontend devs gave us a talk on React (mainly for backend devs, who know enough frontend to fix bugs). Diagrams with arrows here there and everywhere. NPM install downloads a significant chunk of the internet just to display a hello world page. Compared to what I was doing in Django with server side templates and a bit of JQuery a few days ago this is incredible. It takes twice the works, for very limited benefit in our case at least. Most web apps are just displaying some data and a bit of form validation.

bobkazamakis• 4 years ago

this is art and all of us should be ashamed.

MrPatan2• 4 years ago

This is true and excellent, and I'd put it next to Hickey's "Simple made easy" and Metz' "The Wrong Abstraction" as something I wish every developer would grok.

vlunkr• 4 years ago

I would recommend those to anyone here that hasn't seen them.

I think this requires a big shift in community thinking. Programmers are trained in universities to throw OOP principles at every problem, and the DRY principle has deeply taken hold. Obviously both have their place, but they often used overzealously and come at the expense of readable and maintainable code.

TheOtherHobbes• 4 years ago

In "Simple Made Easy" he's recommending XML, JSON and even SQL for data. So I'm going to have go to with "No."

All that does is move somewhat messy language constructs into somewhat messy data constructs.

The data is static-ish, which is nice. But the associated code has exploded in complexity and with XML particularly you can't even be sure if it's truly compliant - especially if it's coming from an outside source.

So I think that whole talk is spectacularly missing the point. The idea is good but functional/read-only doesn't solve the problem.

Because some problems are just hard, and no amount of functional twiddling makes the hardness go away.

Names are hard. International localisation is hard. Dates and calendars are hard. International holidays and special dates are hard. Addresses are hard. Timezones and time systems are hard. Phone numbers are hard.

There is no trivial solution to any of these problems.

The most effective solution would be an international standard collection of algorithms and APIs baked into identical standard libraries for each mainstream language.

What you get instead is a lot of people wasting time and energy solving these problems over and over - badly.

And in fact XML, JSON, SQL, etc are similar. There are countless libraries and frameworks for managing these, and they're all slightly different and likely to fail in different ways - not just in different languages, but in multiple competing frameworks for the same language.

The problem isn't the code, it's the culture around it. Instead of solving a problem completely and standardising, the industry is addicted to nearly-but-not-quite solving the same problems over and over.

That's where a lot of unnecessary complexity comes from.

collyw10• 4 years ago

even SQL for data

I am lacking context, but SQL was made for data.

pyrolistical• 4 years ago

Heh, me not grug brained right?

kazinator2• 4 years ago

This reads a lot like like commit comments, status reports, e-mails and tickets in a company in which everyone is from a different country from around the globe.

If you can't read grug English, you will find it hard to navigate in the global workforce.

girvo2• 4 years ago

I have accidentally introduced “dope” as a thankful affirmative into our international developers lexicon at work. There’s another even more amusing one too but I can’t remember what it is. Working with global teams is fun!

_rgun• 4 years ago

Thankfully this is not totally correct. I personally found grug English to be harder to understand/read as a non-native English reader.

MrPatan2• 4 years ago

"deserve of club but heart in right place"

I love it.

cubano• 4 years ago

The problem here as I currently see it.

What could be complex to some could be simple to others.

How could grug developer possibly make sense of such a contradictory statement?

My name is Groot!

smm11• 4 years ago

I sense a certain age-range here.

recursive8• 4 years ago

grug sense a certain age range in comment

dusted3• 4 years ago

Well meaning..

However, what I _REALLY_ want is a sw-dev (let's just say it like it is _PROGRAMMER_) version of the BOFH stories.

sovietswag• 4 years ago

oh well, grug end up at good company anyway and rob pike dress habit increasingly erratic, so all work out in end, but point stand: logging very important!

beautiful...well done....

beckingz2• 4 years ago

Now we add GRUG to KISS and YAGNI.

bfung• 4 years ago

this grug read article, but author grug big brain, article too long. If article was smaller with less complexity, easier for regular grug to read and remember.

</grug>

SonOfLilit2• 4 years ago

grug read one sentence, grug feel smarter already. grug read next sentence, grug feel smart on different subject. grug hope have one sentence in inbox every day. or maybe little bird chirp sentence at grug. but no complex, just many subject.

planarhobbit• 4 years ago

Horseshoe theory right once again: Grug and 100x’er megaminds are aligned, and the midwits are over complicating and underperforming.

elwell• 4 years ago

Basically "Simple Made Easy"

nullptr_deref• 4 years ago

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 know debugger good but grug often realize grug no need debugger on smaller cases and only run it when grug need it, grug try simple code like print and log first, if grug sad and no understand grug go for debugger

dmix• 4 years ago

On the frontend I have a sweet debugger setup with neovim and chrome but there’s definitely a time investment setting it up. The overhead exists almost entirely because of how the code goes through a Typescript, Vue/Vite transpiler and needs to sync with the source map… so breakpoints aren’t a 1-to-1 connection.

So yeah console.logs are still quite common even if you have a great debugger because it’s the most accessible and laziest option.

But there’s something very rewarding about getting really good with a debugger and figuring things out quickly.

mattmanser• 4 years ago

Relying on log and print statements is like giving up. I would claim that's not simplicity, that's inexperience, but I have no idea what language you're referring to. Sometimes I do it with JavaScript when I didn't setup the project, it's using a framework I don't know and I'm not willing to spend the time figuring out how to get real debugging working so there are caveats.

But you definitely should not be doing that if you have a good debugger as It's faster to click the line to add a break point and press play. You can SEE the state. And you can view other variables at the same time if something's looking whiffy, usually by just hovering your mouse. Plus see the entire call stack.

The thing that's boggling my mind about this is that if you know the line to add a log statement on, you know the line to add a breakpoint on. It's so much easier to just add a breakpoint.

In some languages if I saw someone adding a log statement while debugging I would immediately classify them as a junior programmer and start teaching them how to debug properly.

Either you are using a shitty language with a crap debugger or you need to learn how to use your IDE.

IsopropylMalbec• 4 years ago

You are not able to, or at least should not be able to debug your code in production. More than likely all you will have is your logs.

nwatson• 4 years ago

You can't run a system handling real money or real medical records in a debugger. Or if you are, you're violating a bunch compliance standards and will get sued into oblivion.

going_ham• 4 years ago

It totally depends on the case at hand!

I use debugger all the time when I run into pointer related issue, or some checking some tensors in deep neural nets etc.

In some cases, I throw debugger just to see what is going on.

However, I have had few cases where debugger slowed me down. If you are doing something in graphics that requires you debugging issues that spans multiple frames, sometimes it's easier to notice the value over a period of time and see why things are behaving that way. From there you can reason what might be causing the issue. It can be done frame per frame inserting multiple breakpoints, recording them and viewing them accordingly! However, I prefer simple logs in such cases.

I have used both approaches as time demanded.

iamthepieman• 4 years ago

If I set a breakpoint somewhere and it ended up being a location that was useful, that's usually a good place for a log statement.

As for your point about logging being a fail condition, I was working on a distributed system where I had no control over which instance my code was running on. I would attach a debugger and make the same request a dozen times before the instance I had attached the debugger to processed the request. This wasn't a system I could setup a local instance of. I also couldn't reduce the instances to a single one because there were other devs, testers, data engineers working on it and the system did raster processing that regulary took 1-5 minutes. I resorted to log debugging.

nickysielicki• 4 years ago

Yes, I am using a shitty language.

Thus, I fully support high-level languages in which pointers are hidden and types are strong and the declaration of data structures does not require you to solve a syntactical puzzle generated by a malevolent extraterrestrial species. That being said, if you find yourself drinking a martini and writing programs in garbage-collected, object-oriented Esperanto, be aware that the only reason that the Esperanto runtime works is because there are systems people who have exchanged any hope of losing their virginity for the exciting opportunity to think about hex numbers and their relationships with the operating system, the hardware, and ancient blood rituals that Bjarne Stroustrup performed at Stonehenge.

https://www.usenix.org/system/files/1311_05-08_mickens.pdf

jesse__2• 4 years ago

In real-time systems (games, specifically) logging can be very useful for figuring out what happened on the frame _before_ the bug happened, which in a lot of cases is not immediately obvious where the bug manifests (and you'd hit a breakpoint).

The alternative is setting (sometimes many) breakpoints in different places and remembering what happened at each of them. Personally, I prefer reading a log.

residualmind4• 4 years ago

Some debuggers take longer(1-3 secs) to spin up than it takes me to add a print, compile and run and see my theory confirmed or not.

If I want a debugger and see e.g. the complete variable scope at a breakpoint, I'll use a debugger. If I just want a very quick sanity check I'll use a simple print.

Once you enter debugger land you're there. When I'm currently not in the debugger but rather compiling and executing "for real", it seems more straightforward to me to not enter debugger land when I really don't need it. Personal preference.

There are scenarios, where 2 print statements can tell you more quicker, than breakpoints. You have to step through the breakpoints, right? 2 print statements in different parts of the control flow can tell me everything I need to know at a single glance.

leetcrew• 4 years ago

Either you are using a shitty language with a crap debugger or you need to learn how to use your IDE.

or you are working in a domain where debug builds are intolerably slow.

Tao33002• 4 years ago

In some languages if I saw someone adding a log statement while debugging I would immediately classify them as a junior programmer and start teaching them how to debug properly.

Ah, the awkward "tween" stage of development. If you don't switch to the management track, you'll skin your knees enough times to learn when you need one and not the other.

deterministic• 4 years ago

30+ years professional developer here. Tell me how you would debug a customer issue that happened yesterday on their system without logging and without being able to connect to their system? Manually using a debugger is a red flag for me. It tells me that the developer doesn’t understand how to automate debugging by automatically detecting invalid application states and logging the problem. The best developers I have ever worked with never use debuggers. The worst developers I have ever worked with used debuggers all the time. Because they had so little understanding of the code that they needed to manually step through the code to get it.

nerdponx• 4 years ago

Printf bad, log good. Grug already have logging in app. Grug use logging, Grug no reinvent logging with printf.

Tao33002• 4 years ago

Except when the complexity demon creeps into the logger. That was a thing quite recently.

collyw10• 4 years ago

Really depends on what you are coding. I have my debugger set up, it's easier then trying top spot the new print statement in amongst all the other log statements being spat out.

lxe• 4 years ago

Start calling bad abstraction "indirection". If I'm debugging something, I don't want to be chasing a rabbit through figuring out what calls what, and what constant is stored where, what pattern created what instance, etc...

crooked-v3• 4 years ago

I hated dependency injection until I escaped Javaland and discovered that you could do it with direct interface references instead of four layers of indirection.

wly_cdgr• 4 years ago

This bats 0.950+

Who is this person? They must be a very senior Jedi

ntoskrnl• 4 years ago

His name is grug.

philangist• 4 years ago

His name is Robert Grugson

palotasb• 4 years ago

grug not like big complex front end libraries everyone use
grug make htmx and hyperscript to avoid

https://twitter.com/htmx_org/status/1539713592794169346

https://github.com/bigskysoftware

pawelduda• 4 years ago

grug has never used erlang, hear good things, but language look wierd to grug sorry

maybe grug try drink elixir?

nathias• 4 years ago

complexity isn't bad, redundant complexity is

thealistra• 4 years ago

Yes, people often confuse inherent problem complexity (maybe domain complexity) with unneeded complexity introduced by code architecture.

You can reduce the latter, but often you can't reduce the former. That's why it is best to keep abstraction for code architecture at bay.

nyanpasu64• 4 years ago

You can reduce inherent problem complexity by picking a simpler subset of the task to solve (for example only support a single backend rather than plugins and interfaces, or exclude complex problems like text ligatures and glyph shaping). The resulting program will be shorter, have less indirections (making it easier to trace statically, and require less scrolling between functions and jumping between files), easier to make correct and fix bugs, and easier for outsiders to read and learn the fundamentals of a problem domain from. And once you've learned a conceptual understanding from simple programs (JACK2), you'll be better-prepared to learn big complex programs (PipeWire), which are harder to learn not only because they deal with more complex problem domains (latency compensation, multi-device synchronization, video), but also because they suffer from dynamic dispatch (requiring runtime debugging to identify which type implements an interface) and are too big to learn the architecture by merely looking at individual files (though I hope projects get better at teaching architecture: https://matklad.github.io/2021/02/06/ARCHITECTURE.md.html).

Unfortunately, in some cases complex programs adopt fundamentally different architectures (dynamic dispatch and plugins, different data structures, extra modules like Harfbuzz and Pango, etc.) from simpler programs. Perhaps they have reasons for doing so, but in practice I find myself still confused even if I understand the simplified concepts and can write useful code using them.

kinbiko• 4 years ago

Kevin, is that you?

DevKoala• 4 years ago

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!

I am keeping that.

bekantan• 4 years ago

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

This resonates with me

LawnGnome• 4 years ago

Australians of a certain age might have a different (yet not that different) take on the Grug brain: https://www.simonandschuster.ca/books/Grug/Ted-Prior/9780731...

ammojamo• 4 years ago

Hah! I read the whole thing thinking that of that grug. Which gave it a really odd but lovable vibe in my head. TIL there is more than one Grug.

maest2• 4 years ago

sometimes probably best just not tell project manager and do it 80/20 way. easier forgive than permission, project managers mind like butterfly at times overworked and dealing with many grugs.

In my experience, I have to fight to keep my devs from over engineering their solutions and just get something going.

I'd love to work with a dev who's happy to think about how to most quickly deliver value and who's willing to help with the cost-benefit analysis for each suggested feature.

Problem is, for that, you need a developer who cares about and deeply understands the use case/the product. Many of the devs I've had to work with were more interested in building pristine codebases with clever abstractions and ability to scale to unnecessary numbers of users or bytes.

xupybd2• 4 years ago

I've been there, so far away from the business use of the product that my solutions focused on the tech.

I'm sorry.

Now I'm right on the front lines of the business and it's eye opening. I think we need to take time to tech the domain to devs first. It's expensive and won't pay off unless the dev stays on the project for a while but it's the only way to allow the dev to understand what they're trying to do for the business.

In reflection I'm wondering if the problem is more that an external consultant is often not aligned with the business. Being directly employed helps with alignment.

charlie02• 4 years ago

The problem is that most companies don't proactively teach the business side to the devs, I know mine doesn't.

TideAd• 4 years ago

Do you understand the basic reasons why?

Developers are on the hook for bad code and complexity. Rushed code makes feature work take longer, it makes working more irritating, and creates operational work. Everyone is burned by a team that does these things poorly at some point in their career and it drains the life out of you.

They need to trust that you'll schedule time to go back and do things correctly. Clean up technical debt, nail down all the requirements, etc.; you don't want to be jumping from MVP to MVP. Maybe you do this well, I don't know. But you need to understand the motivations and incentives of the devs you work with better or you're going to be fighting them constantly.

ornornor• 4 years ago

You nailed it.

devmunchies• 4 years ago

Rushed code makes feature work take longer

grug say nothing of "rushed code". Grug get sick if grug drinks from dirty water, even if it is closer than walking to clean water. Rushed code and dirty water hurts Grug.

But that not mean that Grug needs to dig a trench to clean water, or build wall like beaver to get more clean water, it hurts Grug's back. Grug just walk to clean water when Grug is thirsty.

Grug dig canal to clean water before, and Grug need to always keep canal clean and me not able to hunt for food because me digging new holes. One time, chief said village need to move to other side of mountain. Grug said goodbye to canal and my beaver wall. Grug should not built them.

verve_rat2• 4 years ago

100% A bad code base is a mental health hazard, and that shit hurts. Of course time crunch isn't the only thing that makes a bad code base. Devs bike shedding to much, or just not being good at maintaining a code base can have the same effect, but not having the time to protect your own future mental health really starts to weigh on a workplace.

goodoldneon• 4 years ago

It's a balance. As an engineer, I'm constantly dealing with the consequences of a "the feature worked so we shipped" mindset. Churning out features without thinking about architecture creates increasing amounts of code "tangle" that gradually slows down feature dev. On the flip side, thinking too much about architecture slows down feature dev

galaxyLogic7• 4 years ago

You have the right insight I think. The thing about putting lots of effort into "refactoring" is that the code you refactor may actually not end up in the product at all.

I think "prototyping" is better than "refactoring". Prototyping basically means that you write your app more than once. On the 2nd round you know what needs to be there and what not. You may have come up with a much better much simpler design for the whole system when you know what needs to be there and what it needs to do.

Code-quality is important no doubt, but it is not important for code that doesn't end up in the final product.

mecha_ghidorah2• 4 years ago

I definitely think prototyping should be more common but the problem is I've been burned before.

"Just build a version of this thing as quickly as you can. Don't worry about performance or anything so much, the goal is to get an idea of what these features might actually feel like to use so this is just a proof-of-concept project"

Then "Oh hey we are going to give that proof-of-concept project to a client to try out and give us feed back. Don't worry they know it's just demo code at this point"....

Shortly after that though it's "The client wants these changes and you're who has to support it now. The client says it's slow, why is it slow? Client wants a new feature, add a new feature!"

And I'm left dealing with a horrid, awful, garbage piece of code because I'm the one that wrote it. I was explicitly told to write it entirely as a proof of concept and not as anything production ready which is why it's shit. This has happened to me more than once.

So until I have my PMs and Team lead tell me a thing is going to be a prototype/PoC and it turns out to actually be one at least once at this point I assume it's a lie

eurasiantiger8• 4 years ago

Refactoring is probably a sign of problems, unless by refactoring one means ”giving abstract structure to yet unstructured code”, i.e. factoring for the first time.

That needs to happen after feature-completeness, but before a project goes into maintenance.

lmarcos• 4 years ago

That's because such developers know that they won't have to maintain such code. They will probably be gone (switch to another company) in 1 or 2 years.

SamBam• 4 years ago

I think you have it backward. I'd much rather maintain pristine, clear, well-architected code than code that was shipped to a deadline, if I had a choice.

jbreckmckye6• 4 years ago

It's a question of incentives and accountability.

PMs aren't usually accountable when their shortcuts come and bite the team further down the line. Developers feel the pain instead.

PMs won't be honest with the business that they sold an undercooked product. Need to suddenly scale up that "pragmatically" designed database? I know in my heart that too many PMs will _never_ manage expectations with their superiors if they can harangue developers into overtime, out-of-hours alerts or death marches. It’s asymmetric risk.

Don't take that personally. I’m sure you, individually, do the right thing. But my experience is that PMs / POs / team leads as a group can be bad actors. It's just the way incentives are structured for middle managers. By the time the problems of your "pragmatic" architecture have emerged, your typical PM / EM / team lead will either be working on another team, doing another job, or talking about "tech debt" as "just one of these things", a mysterious natural force, visiting your team stochastically like a freak summer snowstorm or an outbreak of measles.

_That_ is why developers are cautious. Do you _seriously_ think that you are the only person in your team who understands "commercials" or "cost benefit analyses"?

Experienced developers do, which is why we've learned the best strategy in the long run is to avoid offering too many concessions to people without skin in the game.

lukasb• 4 years ago

I'm sorry that you've apparently only worked with bad PMs.

eldavido• 4 years ago

_That_ is why developers are cautious. Do you _seriously_ think that you are the only person in your team who understands "commercials" or "cost benefit analyses"?

I realized this attitude is common to all tradespeople, not just developers, but also HVAC techs, roofers, electricians, pretty much anyone who's long-term accountable for supporting a large, complex system.

More of an observation than anything.

timr3• 4 years ago

Hi. Former engineer turned PM here.

Wow, you're spinning some wild stereotypes here, and while some are based in truth (as are all good stereotypes), I'm going to take issue with this:

PMs won't be honest with the business that they sold an undercooked product. Need to suddenly scale up that "pragmatically" designed database? I know in my heart that many PMs will _never_ manage expectations with their superiors if they can harangue developers into overtime, out-of-hours alerts or death marches.

While I've certainly seen incompetent, bureaucratic and/or poorly incentivized PMs, I don't think I've ever met one who wants to throw their developers under the bus to get a job done. I'm not saying it doesn't exist anywhere, ever (big world out there), but you've made a couple faulty assumptions:

1) A PM is not "a middle manager". It's generally a non-management position, despite the title. The classical "PM" has to use soft force for everything, and only gains authority through a history of doing the job well. We're constantly managing expectations in every direction, and "up" is just one more.

2) Even if we were "middle managers", those amongst us who have been working for a while realize it's bad practice to leave a trail of burned-out colleagues behind us, due to a history of bad decision-making.

I'll add a third, specific to my own history:

3) one reason PMs might not "care" about scaling up that database, is that it almost never needs to be scaled. Seriously.

The engineer side of my brain wants to optimize everything. The PM side is always having to remind that side that most of my engineering life was spent in a cycle of useless premature optimization. The war continues.

Anyway, it might be good to talk to your PMs and not assume they're evil villains. And if I'm wrong and you're working in a truly Machiavellian hellhole...you should look around. I hear it's a pretty good job market.

lumost• 4 years ago

Honestly, this tends to be team dependent. In any organization, there is often some "group" who is pushing to ship. Likewise, there is often a group that feels "stuck" with any fallout from a delivery - and none of the success. This could be Product vs. Engineering, Engineering vs. Support etc.

Where this border breaks down varies from org to org. No one likes having the short end of a stick. Usually if the teams have more mixed ownership boundaries and feel "the win" of a launch, then this becomes less of an issue.

thaneross2• 4 years ago

It's almost like there might be better alternatives than command-and-control structures when building software.

lowercased3• 4 years ago

PMs aren't usually accountable when their shortcuts come and bite the team further down the line.

Years ago, was in a situation where I was working with a PO/PM set of folks (rotated around a bit, but a small team). Multiple times I would suggest X, and get "No, that's confusing, we won't need it, that will confuse users, we will never need that, etc". Then... they're gone, and the new replacements are asking "why don't we have X?"

Similarly, "hey, I need to do XYZ on feature ABC". Reply along the lines of "hey, don't worry - we just need the minimum thing up now - we'll revisit later. I will take responsibility if there's any fallout from this decision." That phrase was used multiple times over the 12-18 months.

Guess who's not here any more to answer any of the 'cut these corners' decisions? Yep - that product person who said "I'll take responsibility". Who isn't around any longer.

Many things that were assumed to be 'done' because they'd been discussed earlier were later discovered to be severely cut down or missing altogether.

What's strange to me is I've seen this pattern play out probably 3 or 4 times over the past... 20 years or so. I learned it certainly wasn't a one-off unique-to-personX thing.

citrin_ru• 4 years ago

PMs aren't usually accountable when their shortcuts come and bite the team further down the line. Developers feel the pain instead.

Developers (and people in general) are bad at prediction the future. I've seen many times that a developer are solving a problems in more generic and extensible form than required, creating a complex solution in hope that future changes will be easy. But then future comes not as it was expected and refactoring is required anyway.

80/20 for me includes not solving problems you don't have but think you may have in the future. If you need to solve X and X looks like a special case if Y class it doesn't necessary mean solving more generic but bigger and harder problem Y is a good idea.

riazrizvi• 4 years ago

The difference is mostly a result of perspective, that could be fixed. The PM has the use cases and product gestalt, if this was shared and made the environment in which the devs work, their prioritizing shifts to product, and engineering concerns would be limited to more obvious ones that make sense.

But it’s human nature to protect one’s job and decision making autonomy. PMs being no exception, often underweight their roles in communication transfer and overweight them in decision taking.

jeffparsons2• 4 years ago

I think I have a near-pathological experience of coding these days that just so happens to make me the exact kind of developer you want:

1. I still want to produce excellent code that will deliver value, work predictably, be fast, and be robust against future grugs. I am driven to do this by forces I don't understand myself.

2. I also feel a deep dread of being stuck with a piece of code for any longer than absolutely necessary lest I end up trapped in it forever, so I want to be rid of this code and be rid of it now, which means I need to find a way to get it done and ship it so I can move on to the next urgent thing.

The result is that you will get a steady stream of good code from me with pragmatic and well-documented compromises, for the low, low cost of my sanity.

eurasiantiger8• 4 years ago

Imagine going to a master craftsperson, and telling them you want them to give you the 80% experience for 20% of the price.

How to do that without being disrespectful?

How come programmers accept this kind of disrespect for their craft? Aren’t they supposed to be the masters, the Hattori Hanzos of program code?

maest2• 4 years ago

Heh, that's the first time I've heard someone describe this, but I recognise the feeling. It's like constantly rushing and wondering if you're being inefficient and if there isn't a faster way to deliver what you need.

bigiain• 4 years ago

Many of the devs I've had to work with were more interested in building pristine codebases with clever abstractions and ability to scale to unnecessary numbers of users or bytes.

I've worked with my share of them, but I've also worked with my share orders who'll hack together the quickest possible kludge that meets enough of the requirements to seem to work on the surface.

Interestingly, given the choice, I'd have some of both those types on my team. I really like having the "architecture astronauts" being involved in the very early stage of greenfield projects. Their desire to push the boundaries can help ensure you start off on a great foundation. I also really like having "that guy" who can hack minified javascript and manually deploy it on prod servers to fix a critical bug _right now_ while someone else goes through the "proper process" to get it into the repo and through the CICD...

But you really really need a majority of your dev team who'll take the proper pragmatic approach, or at least who can be cajoled into doing so.

collyw10• 4 years ago

I really like having the "architecture astronauts" being involved in the very early stage of greenfield projects. Their desire to push the boundaries can help ensure you start off on a great foundation.

I would argue the opposite, having inherited a complete shambles. Started when Mongo was peak hype, but would be far better suited to a relational database. Lots of developer time spent to run on Kubernetes, so we can scale, even though we are in no danger of a having high volume of customers in the forseeable future (it's a very specialized domain).

randompi• 4 years ago

In my experience, I have to fight to keep my devs from over engineering their solutions and just get something going.

In practice tho, the grass is always greener on the other side. You either wish the developer had just hacked something to get it going, when the feature failed, or you wished they had put more effort to make it more abstract and scalable, when the feature set for scaling.

Everyone's a genius on hindsight. Getting it right is more of a mix of experience, gut feel and luck imo.

majormajor2• 4 years ago

How are you hiring your devs?

The more abstract-problem/algorithmic the hiring process, the more I see this.

Ask practical coding problems instead, screen for practical devs who can find 80/20 style shortcuts.

(You probably still want some of the abstract folks too, though, to round things out.)

Trasmatta• 4 years ago

Do you have enough of an understanding of the codebase to know what is over engineering and what isn't? If not, that's the problem I have with a lot of project managers. If you can't understand the codebase, how can you make judgment calls like that? It can be very hard to make the right call between over and under engineered, even if you're intimately familiar with the codebase.

BobbyJo• 4 years ago

PMs represent the customer. That being the case, they push hard for features and leave it to engineers to keep features coming out at predictable speed.

Engineers represent themselves. They are accountable for feature delivery speed and product stability. That being the case they push hard for hardening, automating, and maintaining.

The two have to balance each other out. PMs need to push to keep Eng focused on growing business value, otherwise the company will never make money. Eng needs to push PMs to focus on long term product delivery, otherwise customers will leave as quickly as they come, and new one's will stop showing up, no matter how pretty the UI looks.

If you had a team of engineers like you describe it would only be heaven for about 6 months in my experience. I've seen two separate teams of engineers run this way. Everything was kick-ass until it was suddenly horrible and engineers started bailing.

IshKebab• 4 years ago

Obviously it's a scale but I hope you aren't falling into the trap of only seeing the features. The developers actually have to work in the code so it might not make a difference to you if the feature is implemented cleanly or not (in the short term anyway) but it obviously does to them.

pif• 4 years ago

I'd love to work with a dev who's happy to think about how to most quickly deliver value

I'd love to work with a PM who has the courage to engage over a detailed specification document.

sdfhdhjdw3• 4 years ago

Too difficult to read, can't be bothered.

Does this style really appeal to anyone at all?

bigbillheck• 4 years ago

I didn't think reading it was very hard at all.

JetAlone2• 4 years ago

It appeals to me, absolutely, because I am familiar with and have a positive impression of the Grug character.

trwhite• 4 years ago

I have been thinking about the complexity bias that affects our perception of quality. I think as programmers it is our natural assumption that if something is complex, lots of thought must have gone into it beyond our understanding. This is especially true when starting a new job. But this is slightly ironic because often more code makes something slow, which isn't a good thing at all.

pvillano6• 4 years ago

code can be thought of explaining to a computer what do you want it to do.

In general, explaining without managing complexity is easy and makes you look smart. However, explaining so anyone can understand is very hard. Grug author good at this

dgb232• 4 years ago

What a fun article!

When reading it, I felt like it was loosely inspired by A Philosophy of Software Design by Ousterhout. And it was! Near the end it is listed as recommended reading. Cannot recommend it enough.

dack• 4 years ago

As funny as this post is to read, I don't want to see yet another developer say "complexity bad". I want to see a company deliver high-quality products with very few bugs at a fast cadence, and continue to make major changes long into the future without slowing down.

_THEN_ I want developers from that company to share their opinions about how they do it. Do such companies/products even exist? Software is so bad these days that maybe no existing software lives up to our ideals.

l5ymep• 4 years ago

Complexity doesn't necessarily slow down feature development. In my experience it reduces the project longevity. At some point it will be too big and complex to rewrite all the while more glaring problems emerge and cannot be dealt with.

ryanmcbride4• 4 years ago

If I had a nickel for every time I was hired to rebuild an app from the ground up because it became too complex for anyone to work on, I'd be able to keep up with inflation.

dgb232• 4 years ago

You mean in the form of books, tech talks, articles and so on? There's plenty of that. But it is usually very technical or about abstract problem solving, sometimes also historical/anecdotal. Things like that.

Methodology stuff sometimes comes from people who don't seem to code much at all, or haven't for a long time. I don't really read those things often and when I do I tend to skim them out of boredom.

Software design, architecture and paradigms are a mixed bag. There is plenty of distracting stuff there, and much is from people who again, don't code. But there are a bunch of rare gems in this area, even coming from academics/teachers or veterans who haven't been in the trenches for quite a while, but have plenty of useful things to say.

danuker• 4 years ago

_THEN_ I want developers from that company to share their opinions about how they do it.

Beware of survivorship bias.

For every successful company using a technique, there might be 10 others using the same technique but running into the ground.

And not sharing the embarassing failure.

Microservices strike me as a pertinent example. It might fit huge companies very well, but not if your customer base might as well be served by a cheap Raspberry Pi.

throwaway8922385• 4 years ago

I don't want to see yet another developer say "complexity bad".
I want to see a company deliver high-quality products with very few bugs at a fast cadence, and continue to make major changes long into the future without slowing down.

you want eat cake and have cake.

xbar• 4 years ago

...and now you have 2 cakes.

deltarholamda• 4 years ago

I wonder if the key word in there is "company." Modern companies tend to be VC funded monstrosities that onboard a lot of programmers to do things to make VC firms find more seed capital.

This selects for complexity, not finished product.

We've seen a lot of one-man or small-team companies do some pretty amazing stuff, because usually they are solving a problem that they have. If you're high on VC cash (or are trying to get high on VC cash), the problems you are trying to solve is more marketing than technical.

residualmind4• 4 years ago

Thanks, I needed to hear that, be reminded of it.

jesse__2• 4 years ago

Yes, it's called RAD game tools, recently aqui-hired by Epic. If you're not familiar with RAD, they're some of the best programmers in the game tools industry.

Jeff Robers and Casey Muratory used to do a podcast called the Jeff and Casey show where they'd occationally discuss software products shipped by RAD.

One such episode details the maintenance of a garbage collector RAD shipped, which Jeff denounces as way too complicated and (IIRC) not worth the developer time or CPU cycles.

Complexity bad.

recursive8• 4 years ago

I want to see a company deliver high-quality products with very few bugs at a fast cadence, and continue to make major changes long into the future without slowing down.

I think maybe Reaper fits the bill. http://reaper.fm/

As far as I can tell, it's two people.

asddubs• 4 years ago

few people touching the code is easy mode IMO. much easier to not introduce bugs if you've designed half the system and are deeply familiar with its various idiosyncrasies. good architecture is not a must here, although fewer people obviously also make it easier to stay consistent and make larger refactors at once without stepping on anyones toes.

sometimes that bug free thing that just works and was written all by one guy is just a real pig behind the scenes, but hey, that guy always knew what not to do, no matter how messy the APIs.

0des• 4 years ago

Yeah but one of those people is the winamp guy. His cape is easily two extra people woven into a simple cloth fabric.

andmis• 4 years ago

https://www.wave.com/en/blog/simple-architecture/

cwoolfe• 4 years ago

Doesn't Apple "deliver high-quality products with very few bugs at a fast cadence, and continue to make major changes long into the future without slowing down" ? I'm not sure how they do it; but I like their products. It seems like they do it by saying no to a lot of complexity; while embracing necessary complexity.

twhitmore• 4 years ago

Microservices

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

That made me laugh. The microservices madness of the past decade is now starting to settle down to more mature understandings, but there are still a lot people biting off large testing, operational, and data transactionality/ reporting costs.

People often don't recognise beforehand the magnitude of extra complexity & associated productivity costs.

I've seen companies architecting 50 microservices with 50 separate datastores when they actually needed 5 midi services.. Then lose half their productivity trying to work with all this.

strix_varius4• 4 years ago

I don't know if this is universal, but in my circles "microfrontends" are now all the rage.

How do you bring up concerns with that in good faith? It's so obviously terrible that I've no idea where to begin.

ryanmcbride4• 4 years ago

GOD I hate microfrontends. Had a client that had a single, relatively simple application that they wanted as 3 separate angular apps. The reasoning was that they wanted to be able to autoscale them separately? Was unable to convince them that the gains from that would be negligible, especially for an internal tool, and that scaling the whole frontend instead of a single part of it would have virtually no downside since each app was basically a single form, but tons of upsides like less code complexity, easier data persistence, and fewer versioning issues, faster build time. But they didn't care. To this day I don't know what manager was sold so firmly on building 3 apps when one would do, but not my problem anymore.

pixelrevision2• 4 years ago

Sounds like a big brained term for web pages. I’d lean into that.

codethief• 4 years ago

Oh lawd, at our client people recently pushed that idea, too. Unfortunately, managers were all on board ("Every team will be able to release autonomously and much faster!!!11") and it became politically impossible to argue for alternatives that won't result in dependency and infrastructure hell. So here we are now, splitting off every single page of a god damn legacy web shop into a separate micro frontend, each of which will be running on a completely different stack (some SPA, some traditional SSR with jQuery), living in a separate repository and with a separate microservice in the backend. But how does one share common UI components, you ask? Well, obviously by enabling Server-Side Includes on the ingress server. Duh.

strikelaserclaw2• 4 years ago

microfront ends work well for self contained components that need to be used in multiple pages, they don't even need to have a "separate" backend, as long as there is an area or code file for the backend code that deals with whatever data the microfront end needs.

3np3• 4 years ago

First time I encounter the term, immediate reaction "hmm, maybe we're already kind of doing this?", thinking about mapping a dozen or so services to different HTTP endpoints/prefixes under the same root.

Then I did a search. Oh lord. One of the top results[0] is an illustrative guide on how to split out a Button component into an independent deployment... I can only hope that applying this on a Button is not supposed to be taken literally but I can also only assume that thousands of professional have now made it their calling to split out every component into its own "microfrontend"...

EDIT: Nope, looks idiomatic. [1]

[0] https://levelup.gitconnected.com/micro-frontends-step-by-ste...

[1] https://microfrontends.info/microfrontends/

dc-programmer• 4 years ago

I must run in different circles because I had to Google it. Probably the only thing that made me laugh audibly today.

ngc248• 4 years ago

MicroFrontEnds (MFE) solve an actual problem, but it becomes a problem if developers do it for the sake of RDD (Resume Driven Development) or just because.

My Company has a Cloud platform which is kinda like a marketplace and users can install and uninstall apps/services. In our case MFEs are a perfect fit.

greatpostman• 4 years ago

I actually disagree. I think people disparaging micro services are working at companies or on problems that are too small for that solution

hrayn3• 4 years ago

Agreed. My company has a (relatively) mature MFE platform, and it rocks. The MFE team handles builds, deployment, and can build features like experimentation into the platform, so the teams can focus on the MFEs. The MFEs are not arbitrarily small - they are related to specific experiences. A single MFE might be a collection of pages in a flow, for example. It means less work for devs, more consistency across a big company, and much safer deployments - the worst thing that can happen if you ship a bug is to tank your MFE because they're all isolated. At a big company, being able to change something small on your MFE and push to prod without worrying about every other page in the site is awesome.

collyw10• 4 years ago

I disparage them, because most companies including my own don't need them. My team are keen, but I can only see it adding complexity. If your company genuinely operates at that scale go for it. But remember that Stack overflow runs on a pretty classical architecture.

https://stackexchange.com/performance

geekbird2• 4 years ago

This. Premature and excessive fragmenting into unmaintainable and operationally microse5rvices is the bane of my existence. It's often done by zealots, who see microservice architecture as a matter of religious faith, not operability convenience.

Sure, some monoliths are harder to debug if there are multiple distinct packages that need to operate together if they are all in the same container. But fragmenting a simple set of services into a dozen microservices each in their own disconnected container is excessive too. If any of those fragments depend too closely on other fragments to operate (like, say, a timer service and a session renewal service that depends on the timer) it will easily fall over and be nearly impossible to tell why.

If you are going to shard up your application into microservices, be sure to split out your functions conservatively, so that like goes with like. It's easier to split stuff out more later than to try to split every little jot and tittle into its own dinky container. That way you don't end up with little containers of nothing wasting processor and I/O just for the sake of dogma.

wildrhythms3• 4 years ago

i can't tell you how many teams I've seen spend months and months engineering some vast microservice system only to end up serving maybe 500 DAU. It could have been a single executable on a $5 VPS

BlargMcLarg• 4 years ago

The microservices madness of the past decade is now starting to settle down

Meanwhile, I feel it has just started outside SV. Is the remainder of the world just perpetually 5-10 years behind?

porker2• 4 years ago

Yes.

It's why keeping up with the latest on HN isn't essential for most of us - we've got 5 years to see if it's worth adopting :)

rovek• 4 years ago

Depends what you mean by "the remainder of the world". Most mid-tier companies I've worked at or know people who work at in London started moving on from microservices some time ago. So I guess, unsurprisingly, no.

Tabular-Iceberg• 4 years ago

Also my biggest worry when a client wants to transition to microservices what the state of their current monolith is. An out-of-control monolith doesn't inspire confidence that they will be much better at building a distributed system.

tragomaskhalos• 4 years ago

Wise fellow, that grug.

dugmartin• 4 years ago

Grug no talk of estimation spirit demon.

beaker52• 4 years ago

Grug feel related, make grub happy. And not know why but grug notice that grug style make easier leave club resting. Grug think practice talk grug to inside grug, make club battle few.

Also, grug not know if big brained or grug. Grug think grug but not see big brained. Big brained think big brained stop big brain and become grug. When stop think grug big brain, big brain grug return. Hard, and bore. Life such.

Now sleep, soon shiny rocks collect.

charlie02• 4 years ago

Never before have I read such wisdom. Young grug impressed.

bpicolo2• 4 years ago

Grug and I have essentially identical software development philosophies. I appreciate you Grug. This, especially, was where I felt kindred spirits colliding.

type systems most value when grug hit dot on keyboard and list of things grug can do pop up magic

strix_varius4• 4 years ago

For me, that's 50% of it. The other 50% would be:

type systems other most value when grug make wrong, but no user see because big red arrow point to first.

bpicolo2• 4 years ago

The other big one is I think Rust style enums (especially to enable null-safe types) are amazing. Lots of real world problems are solved well by really darn good enums.

arthurcolle3• 4 years ago

test shaman have good point on importance of test, even if test shaman often sometimes not complete useful feature in life and talk only about test all time, deserve of club but heart in right place
also, test shaman often talk unit test very much, but grug not find so useful. grug experience that ideal tests are not unit test or either end-to-end test, but in-between test

amazing

arthurcolle3• 4 years ago

These literally just get better and better.

big brain type system shaman often say type correctness main point type system, but grug note big brain type system shaman not often ship code. grug suppose code never shipped is correct, in some sense, but not really what grug mean when say correct!

grug need start shiney rock deposit ritual for grug similar program shaman so grug has more club. maybe some club have spike or some club have more big size. me no idea what grug need but me know grug need more.

me is mere artoo not big brain like grug but me has big sympathy for grug. like grug test shaman make artoo skeptical. like grug artoo wish spread word of grug. grug too is shaman. artoo most good disciple grug.

arthurcolle3• 4 years ago

grug warn closures like salt, type systems and generics: small amount go long way, but easy spoil things too much use give heart attack

resters• 4 years ago

I can't tell who this article is making fun of.

SonOfLilit2• 4 years ago

not who, what. grug make fun spirit of complexity, but many time grug git blame who summon spirit, see grug summon spirit. grug humility. everyone complexity sometime. grug make fun frontend, put grug write frontend sometime.

bauble• 4 years ago

People who think simple, easy-to-understand systems are beneath them.

phailhaus• 4 years ago

Love this. Always keep it simple, because future me is dumb. I will say though that frontend dev gets a bad rap, and the tooling is complex because the problem is. UI's are incredibly stateful by nature, and you're not going to get anywhere unless you use a mature framework that lets you reason about it effectively. No, I'm not talking about using React to make a static site, but anything with a modicum of complexity gets out of hand pretty quick.

galaxyLogic7• 4 years ago

Nice article but a bit tedious to read improper English. It is fun for paragraph or two but wears out rather quickly. If you got something important to say why not just say it as clearly as possible?

jbreckmckye6• 4 years ago

grugspeak imply that message self-evident and that complexity is not really in world but invented by badspeakpeople

but world is complex, and babytalk is denial

galaxyLogic7• 4 years ago

I am groot

5cott0• 4 years ago

sometime grugbrain sometime complexitybrain

abecedarius• 4 years ago

cf. 'Grunk' in the very funny Lost Pig: https://pr-if.org/play/lostpig/

I skipped most of this post, but the combo of name and writing style seems like a homage.

User23• 4 years ago

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

This is a big part of the general career skills I teach interns when I'm mentoring. Learn how to not lose the game of musical chairs. When a project is clearly going to immanently collapse under its own weight, change teams before it happens.

jessemcbride• 4 years ago

chef kiss

lwansbrough• 4 years ago

also danger abstraction too high, and big brain code become astral projection of platonic generic turing model of computation into code base. grug confused and agree some level very elegant but also very hard do anything like record number of club inventory for Grug Inc. task at hand

My favourite part.

throwaway8922385• 4 years ago

2 more point grug want make.

1. big brain write code when no idea big picture. later problem make grug have to rewrite many code, make grug want break keyboard on desk! (no idea where club, maybe left bathroom stall)

grug now make diagram first, tell purpose code. maybe take long time and grug no happy. but diagram tell many story from tiny picture. all see picture, all grok. junior grug see problem, ask question, all work together solve problem. many pat on back for junior grug, maybe give bonus shiny rock. then grug make code. less waste time throw away code not make sense, more grugs make code from picture same time. think of artist make mural with grid. grug happy when think code like art.

2. grug also told to refactor sometime, not happy. executive vp say refactor whole app, grug raise club very high. grug boss say "Ok, we'll do Embrace, Extend, Extinguish", grug lower club a little.

grug put up app facade, make feature flag and new feature, push feature to prod, test new feature with little real traffic using flag. test more and more traffic. when new feature use 100% traffic in prod, then remove old code and flag. do again until all old code replace. refactor slow but not make grug work overtime from bad deadline crunch, waste less money when refactor no work, less smash boss when no stand up to executive vp.

rukuu001• 4 years ago

How long until you see the first 'grug-brain' t-shirt at your workplace?

shmde• 4 years ago

Never maybe. People will identify its a modified version of 4chan wojak and cancel Grug.

JetAlone2• 4 years ago

More likely, the creator might recognize that a lot of people who like this kind of stuff have a habit of "hiding their power level" by not buying it and displaying it on their chest. Going ahead and buying that shirt is something like what we used to call the "Silk Screen Goku Shirt" phenomenon, but the newer generation tends to refer to it as "Ahegao hoodie" Syndrome.

pvillano6• 4 years ago

small (optionally 3d printed) caveman on desk, with removable club for small bonks

osigurdson• 4 years ago

> over time grug learn this hard debug, learn prefer write like so:...

I thought grug would say, "grug used to use debugger but now grug stare at code until grug understand code - debugger bad brain drug for grug".

skykooler• 4 years ago

This is like if Code Monkey[1] wrote a whole manifesto.

[1] https://www.youtube.com/watch?v=v4Wy7gRGgeA

throwaway8922385• 4 years ago

https://pst.klgrth.io/paste/449sp

alexashka• 4 years ago

This is a long winded way of saying we don't know how to write software, so we opt for 'ha ha, funny' instead.

maxfurman• 4 years ago

This might be the best text on programming I've read since Why's Poignant Guide

recursivedoubts2• 4 years ago

this might be the highest complement ever received in the history of hacker news, thank you

barrysteve• 4 years ago

grug brain developer not very smart, but grug brain developer program many long year and learn some things although mostly still confused

grug admit confusion is puzzle. grug blame complexity for confusion. grug make better relation to grug's target. grug reduce complexity and confusion. grug win woman and shiny rock.

coalpha• 4 years ago

This is wonderful. I feel myself thoroughly agreeing (but also somehow intensely disagreeing at the same time) with things that are written, especially when it comes to type systems. At some sort of deep level, I seem to like the idea that stuff is proven to work, regardless of how complex the type system overhead is. Maybe it's just two sides of the same coin. Some sort of primitive hatred of complexity and a primitive desire for safety and control will forever be at war inside me.

virtualwhys• 4 years ago

Good stuff, reminds me of PLT Hulk [0], although obviously Grug isn't a fan of powerful type systems.

[0] https://twitter.com/plt_hulk

lynguist• 4 years ago

The writing style has the same cadence as the speech of “Uncle Roger” of egg-fried rice fame: https://youtube.com/c/mrnigelng

dangerface2• 4 years ago

Holy shit this is the best learning I have read on hackernews, funny and so very true.

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

Tade03• 4 years ago

grug brain developer try collect learns into small, easily digestible and funny page, not only for you, the young grug, but also for him because as grug brain developer get older he forget important things, like what had for breakfast or if put pants on

grug relate. other day grug forget Angular have pipes even though grug use async pipe in same PR.

This is particularly concerning for me because not being too strong in the klaka klaka klaka 600LoC daily department I always relied heavily on my knowledge. Is it a coincidence that this started happening after exactly ten years of commercial experience?

TremendousJudge• 4 years ago

grug brain like pokemon brain: have to forget thing to learn new thing. sometimes old thing useless, sometime old thing very important like bank password

pvillano6• 4 years ago

grug brain tip: password manager. grug only remember one password. even on other computer, grug look up password on phone

grug brain tip 2: use grug-brain-compatible password generation algorithm. Grug only need remember algorithm

Example: f("hacker news") = "GRUG<3CLUB" + "hand" + "neck"

grug invent first part with number and symbol one time. rest change depending on site

pvillano6• 4 years ago

think hard ==> always need think hard

think hard about think soft ==> no need think hard all time

collyw10• 4 years ago

Can we get this idea as popular as Joel's rockstar developer? See it in job ads? I think I would prefer to work with guys like this.

JonathanAquino• 4 years ago

For your enjoyment, here is a part of the article being read in a Yoda voice by a pretty good speech synthesizer:

https://jonaquino.blogspot.com/2022/06/grug-brained-develope...

jnash• 4 years ago

Developers talk about reducing/avoiding complexity all the time. And yet the very same developers keep making things more complex. I am starting to realize that most developers don't understand what complexity is. So they say crazy things like "microservices are less complex than monoliths". And they actually believe it! When I then step by step show them that microservices are actually objectively more complex than a well designed monolith they agree with every step of my explanation but somehow still don't get it. Very strange.

The Grug Brained Developer

Related Stories