[samsquire]

I understand software better from words and diagrams than reading the code.

Complexity is aided by having sturdy mental models - what you intuitively understand. And to see the truth clearly.

To have humility: my code is probably ugly to other people, but I understand my code faster than reading yours.

I can't pretend to know that the system I build would be better than yours.

Be wary of pride.

[mbivert]

> Be wary of pride.

It's a good habit in and on itself, but there still are objective heuristics to evaluate software quality.

Simplicity for example: if to solve the exact same problem, with no (impacting) performance penalty, one solution is considerably simpler (meaning, more straightforward) than another, then there's a clear winner.

The amount of automated tests is another objective way of gauging software quality.

[samsquire]

Thanks for your reply.

I think I am contradictory when it comes to software : I don't enjoy maintaining something that breaks all the time: dependencies, system upgrades, deployment scripts and things that aren't 100% working reliably every time.

So my ideal system is to run a simple binary against a file or SQLite database and have it work reliably everytime. Not a complicated micro service architecture with lots of indirection and keep things running on network.

But balancing this with my hobby of designing multithreaded software.

[mbivert]

Life would be so boring if we made everything flawless, we must find ways to spice it up whenever we feel like it's going too well.

I have a friend like that: loves pure functional programming languages; day job? jack of all trades doing buses communication systems ¯\_(ツ)_/¯

[lelanthran]

> Simplicity for example: if to solve the exact same problem, with no (impacting) performance penalty, one solution is considerably simpler (meaning, more straightforward) than another, then there's a clear winner.

Not so clear: some people say `foreach` on arrays is simpler than single line map/reduce/comprehensions. Others say the opposite.

Some people say a monolith is simpler than microservices. Others say the opposite.

Some people say Python is simpler. Others say Java is simpler.

I mean, an earlier response to an earlier comment of mine on a different story was from someone who thinks ORMs are simpler than SQL. I think the opposite.

Until we can get everyone to agree on what 'simple' means, it's not that useful a metric.

[mbivert]

I should have emphasized considerably, my bad: the goal was to cover the foreach vs. map type of issues, both being essentially equivalent, and more of a matter of style.

What I had in mind was things like removing 20/30 lines of literally useless code, or avoiding sophisticated OOP patterns when a few bare functions on ``struct``s are sufficient. I've saw both cases in practice (eh, I'm guilty of it myself as well): they're often the result of overthinking, or "trying to make code reusable."

For the micro-service vs. monolith, I don't think they are comparable as-is, with respect to complexity. Once the factual requirements are known, and once the usage of each pattern to fulfill those requirements is known, then we can compare. But before, it's kind of a "C++ vs. Rust" type of debate: what is the real situation?

Regarding ORMs vs. SQL, I tend to agree with you: we often can't pretend ORMs are perfect ("non-leaky abstraction") black box: in some use-cases, it's true, but as soon as you shy away from toys, you tend to have to understand both how SQL and the ORM work. Way more work than just dealing with SQL.

Same goes for dependencies in general. But they are also essentially mandatory dependencies (e.g. a TCP stack, disk driver, an HTTP lib, etc.).