3 ms·
> never make the mistake of coding directly against the host platform's APIs to begin with I regularly read this advice and I think it's bad in general. If you
by pvorb 5y ago
> never make the mistake of coding directly against the host platform's APIs to begin with
I regularly read this advice and I think it's bad in general. If you only ever work against an abstraction, you lose time and might get a worse end result than the one without the abstraction. And in the end, you might throw it away, if it doesn't prove successful. So move the cost for working with an abstraction into the future as much as possible, when you know the alternatives you have to abstract over.
- eyelidlessness 5y agoI’m not exactly 50-50 on this, but fairly close. It depends! People talk about ‘premature abstraction’ as if spending any time abstracting up front is premature; others talk about abstractions they find generally useful in such an abstract way that it’s easy to mistake those general findings for rules. There’s a distinct set of skills and instincts involved in recognizing a generalization of a problem, and a narrower one in recognizing matching solutions which are actually suited to the specific problem. It’s not a skill/instinct everyone has, but it’s not one that should be immediately dismissed either. And one’s recognition of both can grow and be refined over time. I also think this kind of balanced flexibility should be something we demand as a baseline assumption of the craft: - We’re going to have instincts no matter what, and we should be encouraged to explore them - Some of those instincts will prove right, some wrong; often “wrong” will be grey and murky and temporally separated from trying - When we’ve recognized the error, we should allocate time to correct it with what we’ve learned - As this process recurses, we should assess whether our predictive senses are getting closer to reality, and adjust our risk impulse accordingly