My non-technical co-founder decided to teach himself coding in the past couple of years.

He can write quite complex logic but he tries to make everything as generic and flexible as it can possibly be and so his code is very hard to read as it invents a lot of concepts. He had to refactor it many times due to bugs or unforeseen technical limitations. Took him months to write. On the other hand, I wrote a script which does a similar thing as his but for a different environment (over a network with added latency, bandwidth limits, network instability) and only covers the essential cases but it only took me about a day to write and has been working without significant flaws since the beginning. Only had like 1 bug for a minor edge case. Also, my code is very short relative to his.

This experience reinforces a rule for coding that I've had since the past 5 years or so. It's basically:

"If you can't explain what your code does, from start to finish, in simple language to a non-technical person (who has the required business domain knowledge), and in a way which answers all questions they might have, then your code is not optimal."

Abstractions should always move you closer to the business domain, not towards some technical domain which you invented and only exists in your head.

The part about "start to finish" is important but doesn't mean "every line". You should have abstractions which may be beyond the non-technical person's understanding but you should be able to explain what each abstraction does at a high level without jumping into each function. You should be able to walk through any major feature by walking through your code, without having to jump around many files and without having to pause constantly to explain abstractions as