4 ms·
Pretty easy to give generic advice without examples. “Write more tests, but not too many” “Use good abstractions where appropriate?” “The next time you reach
by noodletheworld 2y ago
Pretty easy to give generic advice without examples.
“Write more tests, but not too many”
“Use good abstractions where appropriate?”
“The next time you reach for an abstraction, ask yourself: Is this truly simplifying the system? Or is it just another layer of indirection?”
It’s easy to create a strawman here (the FactoryAdaptorMapper or whatever) but in reality this kind of generic advice doesn’t help anyone.
Of course people want to use good abstractions.
That’s not the problem.
The problem is being able to tell the difference between generic arbitrary advice (like this post) and how your specific code base needs to use abstractions.
…and bluntly, the only way to know, is to either a) get experience in the code base or b) read the code that others have left there before you.
If it’s a new project, and you’re not familiar with the domain you’ll do it wrong.
Every. Single. Time.
So, picking “good” abstractions is a fools game.
You’ll pick the wrong ones. You’ll have to refactor.
That’s the skill; the advice to take away; how to peel back the wrong abstraction and replace it with your next best guess at a good one. How to read what’s there and understand what the smart folk before did and why.
…so, I find this kind of article sort of arrogant.
Oh, you want to be a great programmer?
Just program good code.
Use good abstractions. Don’t leave any technical debt. Job done!
…a few concrete examples would go a long way here…
- jchmbrln 2y agoI can see the value of examples, but in this case I appreciate the post largely for its universality and lack of examples. On reading it, examples from past and present experience spring immediately to mind, and I'm tucking this away as a succinct description of the problem. Maybe I can share it with others when more concrete examples come up in future code review. A principle takes skill the apply, but it's still worth stating and pondering.
- noodletheworld 2y ago> examples from past and present experience spring immediately to mind Examples of what? Picking the wrong abstraction? Regretting your mistakes? I can certainly think of many examples of that. How you unwrapped an abstraction and made things better by removing it? I have dozens of battle stories. Choosing not to use an abstraction because it was indirection? Which is what the article says to do? I’m skeptical. I suspect you’ll find most examples of that are extremely open to debate. After all, you didn't use the abstraction so you don’t know if it was good or not, and you can only speculate that the decision you made was actually a good one. So, sharing that experience with others would be armchair architecture wouldn't it? That’s why this article is arrogant; because it says to make decisions based on gut feel without actually justifying it. “Is this truly simplifying the system?” Well, is it? It’s an enormously difficult question to answer. Did it simplify the system after doing it is a much easier one, and again that should be the advice to people; Not: magically do the right thing somehow. Rather: here is how to undo a mistake. …because fixing things is a more important skill and (always) magically doing the right thing from the start is impossible; so it’s meaningless advice. That’s the problem with universal advice; it’s impossible to apply.
- deleted 2y ago[deleted]
- mrkeen 2y agoIt might not give enough examples to show you how to do something right, but I think it's enough to warn against doing something wrong, namely introducing an indirection that doesn't provide any of the benefits of abstraction. My colleagues invariably refer to indirections as abstractions, and it's a frustrating sort of name-squatting, because you can't usefully discuss the tradeoffs of abstractions if they're actually talking about indirections. That said, the article does drop the ball by seeming to use the terms interchangeably.