3 ms·
> either god-tier ninja programmers, or rose-tinted specs False dichotomy. Removing some of the many, many layers of crud that hobbles our incredibly powerful
by mpweiher 6y ago
> either god-tier ninja programmers, or rose-tinted specs
False dichotomy.
Removing some of the many, many layers of crud that hobbles our incredibly powerful machines does not take ninja-skills. It does however take the knowledge of what is possible, which is why it is often older developers who bring it up.
Tools that "manage" complexity very often beget more complexity that begets more tools that beget more complexity. Because each layer always turns out to be somewhat less good (and more leaky) at managing complexity than hoped for, and always turns out to add more complexity itself than initially anticipated.
This is not a new trend. We had "middleware abstraction layers" in the 90s. That kept me amused for longer than I care to admit.
So instead of trying to "manage" complexity, and usually failing, reduce complexity where you can. And as I wrote, it actually isn't that hard once you convince yourself that it's actually possible.
"You'll be amazed"
- exdsq 6y agoSay you're starting a new project, how would you keep the complexity down? It's a hard subject and I'll admit I'm prone to follow the interesting tech.
- mpweiher 6y agoUse TDD and hexagonal architecture. That is, start with pure model and build outward from there. Discipline yourself to build only what you really need using TDD: only write production code for a failing test case. Only write enough production code to just barely make the test pass. This will lead to silly code. Refactor this to sensible code when all the tests are green and you sense duplication. Avoid starting with environmental things: infrastructure, frameworks, databases, etc. Don't mock.