Agreed. I’ve also gone into a codebase and seen the most boring code ever. It looked like examples from an intro to web programming class. The backend did simple parameteried SQL queries. It was a pleasure to work with.

My conclusion is that the real “star” developers will, most of the time, write code that’s so simple, it looks like anyone could have written it. They ship a project on time, with good performance and availability, and then they move on. Anyone can come in and maintain it because the code is so obvious.

So much this. I feel that many developers have some fear of writing simple code. Probably because that is the way newbies do it, i.e. straight forward big functions that do stuff.

Reading function pointer dispatch code, disguised as whatever it is called when not C, can be hopeless.

I think your parent comment was making a good point. The "just write the code" and "don't try to be smart" mentality is good only up to a certain point.

Too much "just write the code" ends up creating huge unmaintainable monstrosities.

When you have a lot of time in front of you and a large team, it's okay to just put two junior developers at work for two weeks, and get a big CRUD REST api in the end.

But when you are trying to iterate quickly with a small team, exposing your database is not as stupid an idea as it sounds. And that's why things like Firebase, Hasura, Apollo, Postgraphile, etc. are so popular.

The post is not trying to convince people to build custom DSLs just for querying their database (sorry you had to work with that). It is saying that there are things that exist today, that dramatically reduce the complexity of full stack applications. And that whether or not we like it, this is probably the direction the industry is taking.

The end goal is to minimize software TCO. In addition to being semantically less clear, repeated plumbing code tends to diverge over time, which makes it difficult to refactor and more bug prone if people assume behavior is homogenous.

The best way to handle cases that will be almost the same but may diverge over time is to create a functional mini DSL that describes the domain behavior, and create a template implementation that can be used if desired. Then everything is using a common language, and a non-template implementation indicates the presence of non-standard logic.

> The best way to handle cases that will be almost the same but may diverge over time is to create a functional mini DSL that describes the domain behavior, and create a template implementation that can be used if desired. Then everything is using a common language, and a non-template implementation indicates the presence of non-standard logic.

I mean yeah, I'm a big fan of DSLs. The problem occurs when someone writes the DSL, doesn't document it and leaves. Then it becomes super, super painful to maintain and extend.

Basically I'm coming round to the conclusion that (assuming reasonably competent colleagues), the least experienced person should be able to maintain and extend the code if it's to have any hope of remaining useful over time.

And good tests, for gods sake test the crap out of anything complicated with well-chosen names so that people can read the tests and understand how the code should be used.

If the functions are all clearly named and reasonably small-ish DSLs can be mostly self-documenting. Plus you can always ctrl click in your IDE of choice to view function source. I'm talking something like this:

f(base data) .validate() .domainAction1() .domainAction2() .log() .describe() .sendHtmlResponse()