This is a translation of grugbrain.dev into clear English. All props to the original author.
This is a collection of thoughts on software development, originally written by an pseudonymous author styling themselves the "grug brain developer," but then translated into clear English by Raph Levien.
I am not an extremely smart developer, but I have many years of experience and have learned some things, although still don't know everything.
I've tried to collect what I've learned into an easy to read page. The original was funny, but this version values clarity over humor. I expect young developers to appreciate this wisdom, but I am also writing for my self, so I don't forget these lessons (or other important life lessons like putting pants on).
There are many clever developers out there, and some will not appreciate this essay. Too bad.
There are also a lot more people who think they are clever, and those people will very likely not enjoy this essay. I thought I was clever when I was younger, but have learned from experience it's not a good approach to software development. And it's fine to be less clever.
At the end of the day, this is just some opinions from one person, and I hope you have fun reading it and maybe learn from the mistakes I've made over my long career.
The biggest enemy I've faced is complexity. Complexity is bad. I cannot emphasize this enough: complexity is very bad. Very, very bad.
Given a choice between facing complexity or a scary dinosaur, I'd prefer the dinosoaur: at least I can see the enemy.
Complexity is a spirit demon that enters the codebase when well-meaning but ultimately foolish developers and project managers fail to adequately fear it, or are unaware of its dangers.
One project I was on had an clear and understandable code base, and I was happy that I could efficiently get my work done. But in a short span of time the code became more complex, and that was a dangerous situation. I couldn't directly see the complexity, but I could sense its presence in the code base.
It felt like the spirit of the complexity demon was mocking me, because even when I made simple changes, things would break randomly in unrelated areas. This was painful because I love programming, and would rather do that than trying to make money through financial speculation, like my manager advised.
Sadly, even though I'm aware of the dangers of complexity, I myself done things to make code more complex.
So I remind myself often: complexity is very, very bad.
The best weapon against the complexity spirit demon is to say the magic word, "no."
You can say, "no, I'm not going to build that feature," or "no, I'm not going to build that abstraction," or even "no, I'm not going to shower every day or drink less coffee, so please stop asking me to do that now."
This might be good engineering advice but bad career advice. Sometimes it's possible to advance your career by saying "yes" even when it's the not the best choice. Saying "yes" is a way for managers to grow ever-larger teams. And a dishonest way to get ahead is to say "yes" but then blame other people when things go wrong.
But I try to be honest and say "no" when it's the right thing. That's hard at first, especially if you don't want to disappoint people, but it gets easier over time. And being true to myself is more important than making lots of money.
Sometimes your job requires compromise. As my wife reminds me, no amount of ranting against the complexity spirit demon helps to feed and clothe our children.
In this situation, I recommend saying, "ok," as in "ok, I will build that feature." Then I try to think of an 80/20 solution to the problem and build that instead. An 80/20 solution solves 80% of the problem with 20% of the code. Such a solution may not have all the fancy features that the project manager wanted, and maybe it's a bit ugly, but it works, delivers solid business value, and keeps the complexity spirit demon at bay for the most part.
Sometimes it might be best not to tell the project manager, but do it the 80/20 way. As they say, it is easier to ask for forgiveness than permision, and project managers might not even notice because they are so overworked and dealing with many developers. Sometimes they forget what the feature is supposed to do, or move on to a different role before the feature ships. I've seen many such cases.
In any case, such an approach is usually in the project manager's best interests, so I don't feel too bad about it.