There are only two hard things in Computer Science: cache invalidation and to know when not to use abstraction.

I liked this article about "semantic compression"[0] by Casey Muratori very much. He also posted some video lectures fairly recently about what he calls "non pessimisation" (a term that I personally didn't read anywhere else so far), which is mostly concerned with performance, but the idea is to simply avoid and isolate abstraction and indirection and programming in a style that adheres to what some people describe as mechanical sympathy.

It basically comes down to:

1. Write the code that makes the computer do what it needs to do to achieve a specific goal. No more and no less.

2. Refactor ("compress") the code by deriving re-used (implicit) structures and functions.

He puts a lot of emphasis on those steps being done in order and on deferring the second step

Note that this is from someone who writes games/engines/tooling so there is a large, real pressure to write simple and reasonably performant, optimizable code. He would also prefer that most of programming would be done in this way.

[0] https://caseymuratori.com/blog_0015

I cost myself a position recently arguing about this.

I had a first round interview that went well, and was given a take home and the problem was very simple, dead simple. In turn I tried to keep the code as simple as possible, with only necessary abstractions.

The second interview was with an entirely different person who seemed displeased I didn’t bloat the solution with all sorts of enterprise patterns, dependencies and conventions. I was kinda backed into a wall and while attempting to explain my reasons I ended up in an argument with the interviewer and it was clear we did not see eye to eye. He would later challenge my ability to perform in a patronizing tone and I was sure the opportunity was dead

It wasn’t the only thing that went wrong with that interview, but I feel that disagreement was the biggest killer.