4 Comments

xkcd nails it :-

I find when someone's taking the time to the right in the present, they're a perfectionist with no ability to prioritize, whereas when someone took the time to do something right in the past, they're a master artisan of great foresight.

I find when someone's taking the time to the right in the present, they're a perfectionist with no ability to prioritize, whereas when someone took the time to do something right in the past, they're a master artisan of great foresight.

It’s the classic dilemma, isn’t it.

Faced with coding a new bit of functionality, do you write the version that solves only your immediate problem or do you think ahead and try cater for future, more varied, uses too?

Perhaps you want to find that middle ground; lay it out enough that the opportunity for future generalisation is documented well enough and sufficiently in place so that you can move on in peace, having noted the opportunity and laid the tracks for future development without having expended too much effort.

At least that’s what I generally aim for. (Initially.)

I see it as a professional coder’s challenge. Or just a productive coder’s challenge. To remember to code for the client, or your objective, and to push distractions aside, interesting as they might be. Interesting sidelines can turn into a form of procrastination otherwise.

Put it another way: not on their dime, unless you care confident you can deliver ‘something extra’ that they’ll appreciate without ruffling feathers. It’d be like the cartoon otherwise.

Footnotes

Don’t get me wrong. I love the idea of giving more than was asked for but a reality, for independent developers like me at least, is that you have to be careful of overhead time. By only briefly sketching it these out in documentation, etc., in the main run of things elaboration is pushed to overhead time, where you’re more likely to be critical about implementing it or not.


Other articles on Code for life:

Research project coding v. end-user application coding

Life sciences want bioinformatics, but not so much e-infrastructure?

How algorithms shape our world

Literate and test-driven programming (in bioinformatics)

Developing bioinformatics methods: by who and how