anyway I chanced on this article on the gliffy blog on optimization for programmer time which led me to a recorded talk by Jonathon Blow on programming. It's an interesting talk, general enough to offer casual programmers useful nuggets of info and the anecdote on the asset loading in Doom (the video game) was like a blast to the past omg ...
stuff that I took away from the talk was that the
"industry average" for programmers is to generate ~ 3,250 lines of code / year
Optimization is not ALWAYS bad.
It is good when you are optimizing things that actually matter.
It is only bad when you are optimizing for the wrong thing.
Hence when you optimize for Speed and Space don't forget to optimize for "years of my life
per program implementation (life) "I am so guilty of this, fixating on how to 'efficiently' max out the nodes/cores of our shared cluster that I forget that I can actually use the time 'wasted' to continue on another side project/ catch up on emails / or even that coffee / toilet break I have been postphoning.
trying to see my time as a limited resource for which I need to fit everything within 3250 lines of code that I can generate in a year should be an interesting paradigm shift.
Jonathan makes the rather daring claim that "almost all applied CS research papers are bad" and "this isn't fooling anyone any more ... "
the reason for this is that the papers
propose adding a lot of complexity for a very marginal benefit
doesn't work in all cases (limited inputs, robustness) "supported" by bogus numbers, unfair comparisons
Hmm sounds like some papers I have seen lately ...
his list of criteria for someone he would like to hire is something that I feel should exist in all job descriptions :
- gets things done quickly
- gets things done robustly
- makes things simple
- finishes what he writes (for real)
- broad knowledge of advanced ideas and techniques (but only uses them when genuinely helpful)
No comments:
Post a Comment