with all these fancy 80/20 implementations there's still an inevitable tacit knowledge aquisition phase where you stop giving it what it tells you it wants and start giving it what you know works for getting the information that you want.
it is for this reason that consistency of, and thorough/feature rich design are all that's needed.
treat it like an API. You can add in the fluff later but stop trying to fluff over the rough bits. Fix the rough bits, and you might find you don't even need the fluff.
I see this attitude among the elitist CS majors who can talk to you about how great the CLR is but are completely divorced from reality evidenced by their use of per-byte event-driven serialization routines instead of, you know, just copying the whole buffer contents at once to their processing buffer. The attitude then manifests as 'well it's only a few thousand bytes a second during communications'.
So I guess I need to come up with a way to market my no-nonsense design principles.
Comments
with all these fancy 80/20 implementations there's still an inevitable tacit knowledge aquisition phase where you stop giving it what it tells you it wants and start giving it what you know works for getting the information that you want.
it is for this reason that consistency of, and thorough/feature rich design are all that's needed.
treat it like an API. You can add in the fluff later but stop trying to fluff over the rough bits. Fix the rough bits, and you might find you don't even need the fluff.
I see this attitude among the elitist CS majors who can talk to you about how great the CLR is but are completely divorced from reality evidenced by their use of per-byte event-driven serialization routines instead of, you know, just copying the whole buffer contents at once to their processing buffer. The attitude then manifests as 'well it's only a few thousand bytes a second during communications'.
So I guess I need to come up with a way to market my no-nonsense design principles.