blog: Overlooked Essentials for Optimizing Code

[dsimcha]

== Quote from Bruno Medeiros (brunodomedeiros+spam at com.gmail)'s
> Also, the notion that an intrinsic part of algorithm design is to
> understand what kind of data you are going to work was also mentioned in
> one of the core curricula courses in my degree (although with less
> detail than with case 1, above).
> I don't mean to offend anyone, but if you CS degree (at least for the
> last decade or so), doesn't teach about points 1 and 2 above as part of
> core curricula, then it's a pretty crappy CS degree. The same is
> probably also true for other related degrees (*-engineering, maths), at
> least with regards to point 1.

You have a point to some degree, but I've noticed two related themes from my
experience with my Ph.D. research and with the D community.  Both of these are
things Walter seems to understand and exploit exceptionally well.

1.  There's a big difference between "it was covered" and "most people actually
understood it".  Of course the first is a necessary condition for the second, but
it's not a sufficient condition.  Of course any CS/software engineering program
worth its salt will recommend using a profiler, but the question is, does it sink
in for most students or was it mentioned in maybe one lecture on a Friday morning
when half the class was hung over and the other half was still sleeping?

2.  "It's been done before" is not a good reason not to do something if you're
going to up-level it.  If something's been done before at a proof-of-concept
level, it's often rewarding to tweak/improve it to the point where it's practical.
 If it's practical, it's often rewarding to try to tweak/improve it so it's usable
by mere mortals and is well integrated into whatever other stuff might be related.
 If it's usable by mere mortals, it's often rewarding to figure out what
improvements need to be made to break barriers to widespread adoption.