Reaction To Grugbrain.dev

Grug is writing down advice for others and his future self gathered over a long career of software development.

Many programmers are smart, and those are outnumbered by many more who are not as smart as they think. The author used to be one of the latter but has become more humble.

Complexity is the hardest problem programmers face. It is an invisible property that makes it impossible to work. It creates confusing effects where changing any part of a codebase may break any other part of the codebase. It is frustrating, but Grug loves programming rather than retiring to live off investments like his father. Programmers often introduce complexity themselves.

The best defense against complexity is saying "no". Refuse to do things that are too complex. That is tough because the key to career advancement and making more money is saying yes to everything and many people want to say yes not to disappoint others.

Sometimes compromises must be made to keep your job and feed your family. A good compromise is to build a Pareto solution that accomplishes 80% of the results with 20% of the effort. This holds complexity back.

Grug recommends not always telling the project manager you are doing it this way. It's easier to get forgiveness than permission, and project managers are busy with other things and probably won't remember everything they asked for anyway or leave the project before it completes.

The next best defense against complexity is organizing the codebase well through abstractions and interfaces. It is tempting to do this early, but waiting is required to learn enough about the problem domain to make good abstractions. Good abstraction doesn't have firm rules and is a matter of taste.

It is especially tempting for smart programmers to abstract too early. Grug heads them off by forcing them to write down their ideas in something other than code first which is easier to change or throw away later. Grug also demands prototypes so smart programmers are forced to do a simpler thing to make it work early.

An effective team lead can harness many smart programmers to produce good abstractions, which means successful big projects and lots of money.

Testing is good and saves a lot of time, but some idolize it. Tests are most effective when written after enough code has been written to understand the problem domain. This takes discipline because it is easy to create programs that only work where they were developed.

Unit tests are often too specific and need to be replaced when code changes. End-to-end tests are often too general to debug when something breaks. Integration tests provide a balance.

Use mock objects sparingly.

Refactoring is good practice but holds the danger of creating too many bad abstractions and introducing complexity again. Keep refactors small and make sure the codebase works at every step.

Only replace something once you understand why it was there.

Good tooling maximizes productivity, especially code completion and debuggers. New programmers should learn their tools and they will learn more about computers than a university class.

Grug believes the primary value of type systems is making code completion easier. Correctness is of some value too but it's easy to get too abstract turning programs into math at the expense of practical work. Generic types are very tempting but introduce complexity and should be used sparingly.

It's fine to minimize lines of code written with complex expressions, but assigning sub-expressions to variables is easier to debug. Young programmers don't like this, but come to see reason eventually.

Don't repeat yourself is good practice, but repetition is better than a bad abstraction.

Separation of concerns is usually bad. It splits up strongly associated things and makes behavior harder to understand.

Like type systems and generics, good but use sparingly.

Logging is so important it deserves the attention of the best programmers at a company. All major branches should be logged with consistent request IDs across machines. Log levels should be dynamically controllable and attachable to specific users to make debugging easier.

Grug is afraid of concurrency and sticks to proven models.

Always have a profile showing the problem before optimizing. Grug is often surprised what the bottleneck is. Don't be too CPU focused because network requests take a long time.

APIs are great but often made too abstract. An example is the Java API where you can only filter streams but the data structure people use is lists, so filtering always requires converting to and from a stream.

Grug finds recursive descent parsers most practical and is disappointed schools focus on parser generators which generate unreadable code.

bad (It's funny there is special ire for the visitor pattern that it deserves a special mention to be dismissed in one word)

Front end developers love using complex new libraries

Most fads are dumb because most bad ideas have already been tried, so most fads are recycled bad ideas.

Many are afraid of looking dumb. It's brave for senior developers to admit something is too complex for them even though they might be criticized for it. The examples make it easier for juniors to admit it too.

It's common, even for Grug, to have no idea what he's doing, but it's still possible to succeed despite that.