3 ms·
You and I would think the platitudes are obvious but I've been at tables with people where stating those made people blink with that unnamed dread that hits you
by pdimitar 3y ago
You and I would think the platitudes are obvious but I've been at tables with people where stating those made people blink with that unnamed dread that hits you when you realize you haven't understood something super simple for a very long time and are just now getting it for the first time. That happened... a number of times in my life and career.
Truth is, much less things are as obvious as you and I think.
> "as simple as possible, but not simpler" is always right. Messy solution? You should have made it simpler. Primitive solution causing problems? You weren't supposed to make it too simple. Why didn't you think about making it just perfect?
Nah, that's obviously (heh) a non-sequitur; iteration always beats planning. We know it by practice.
> In reality, it's very hard to even get people to agree what is simple, when solutions have various trade-offs.
That's why you don't ask for permission, you ask for forgiveness. :) Another law of our profession, if not in many others too.
- pornel 3y ago> That's why you don't ask for permission I didn't mean agreement as permission, but as having the same judgement. One person may say bash is the simplest, another that Makefile is even better, and third person will say they'll both become a mess, and it's simplest to use Python from the start, and so on. Reasonable people may disagree where is the line of "but not simpler". Something that is "simple" to one person, is "primitive" to another. If someone says they have a simple and elegant solution, but it requires their skills, is it really simpler than a "dumb" solution that more people can understand? (e.g. DB vs Excel? C vs JS?). Everyone may be in agreement that things should be super simple, but there may be a choice between simplifying implementation vs simplifying operations. Or people may disagree about future requirements and argue that a solution that is the simplest now will hit a complex scaling problem later, and the total-lifetime-complexity of the product will be minimized by another solution instead.