A corollary: it is better (and harder) to have simple solution to complex problems than to have complex solutions to simple problems.

IMO, code - along with anything it may be dependent on - needs to be clean. Not spotless, but structured and blatantly obvious, without cluttering it with things that may not be understood by a colleague.

Now, having said that...

This relates to my honest opinion about Imperative mood vs Past tense, and why I do what I do on personal projects (or projects that aren't strict about how to communicate.)

Fowler wrote the bible on refactoring. And, I really have been fascinated about the subject matter of the above post for the last couple of days - because we're not talking to a computer about work that it needs to do. It now does that work, because we've instructed it to do so. It's also not a todo list, but a list of checkpoints that pertains to completed tasks.

However, the thing that interests me most about this subject is human interaction - something often overlooked by designers and developers. We interact much more today, using commands that demand action beyond handling something you've prepared for it (like "Send", after an email has been written.)

"What is [this]?" = "Define [this].", "I like it!" = "Like", etc. But, imo, the coup de grâce of traditional communication and interaction was when most people started using their voices to control mobile devices. It went from a one-click command, to a verbal command. And to understand how deep this has gotten; If the device doesn't understand what a person has commanded it to do, and god forbid it repeats the same pattern, the human will get angry - and sometimes insulting.

User: "Alexa. Define Git."

Echo: "Get could mean coming into the possession of something concrete or abstract."

User: "Alexa. (slowly) Define GIT."

Echo: "Get could mean coming into the possession of something concrete or abstract."

User: "Alexa. Go ** yourself."

Echo: "I'm sorry, I could not find that in your library."

But, in most cases, another human would understand immediately since we have the king of transpilers built inside of us. This is also why, simply through tone and gestures, any human can communicate to another without using the same language.

well I will not go for the fools, but she's right. Code that should be maintained should be understandable for a normal person within the problem domain it gets explained to.

But it's one of the basic rules @ highlevel languages. You should write as declarative as possible.

in 97 things a programmer should know. Chapter 58: by Linda Rising

Maybe it’s because most of them are smart people, but in all the years I’ve taught and worked side by side with programmers, it seems that most of them thought that since the problems they were struggling with were difficult, the solutions should be just as difficult for everyone (maybe even for themselves a few months after the code was written) to understand and maintain.

It's maintainability 1 on 1 in the end.

Totally agree to this! When writing code in teams, keeping the codebase understandable for everyone (not even just on a line-by-line level but more on an architectural level) is a challenge that should be kept in mind at all times. Keep your colleagues informed and also invested in the patterns and standards you want to pursue, review and discuss code to achieve this. My company has a weekly meeting with all devs for this exact purpose.

In a way this also relates to this 3-step process I've read somewhere on Twitter (and I unfortunately can't find the source anymore) — it goes something like this:

• junior devs write simple solutions (because they don't know better)
• mid-level devs write overly-complex solutions (because they can)
• senior devs write simple solutions (because they learned)