In keeping with my previous post, I’ve been going back to basics, by brushing up on one of the most fundamental parts of computer science, namely algorithms and data structures. My primary guide through this is “The Algorithm Design Manual”, which I find to be a more pragmatic/useful-to-the-practicing-engineer treatment of the subject than the famed “CLR” tome. I’ve also been working my way through “Cracking the coding interview”, which is even more focused on nuts-and-bolts, industry-type questions and techniques of data structure and algorithm construction.

In general, after a couple of years of being out of college, software engineers tend to have a somewhat complicated relationship with algorithms and data structures. We remember that there are smart/efficient ways of solving various kinds of computational problems, and think they’re pretty neat, but since 99% of the time we spend working on production software has nothing to do with solving those sorts of problems, our knowledge of the details gradually fades. This makes it somewhat discomfiting when a situation arises where you need to know the details of how to, say, implement a priority queue, because then you have to reacquire all that knowledge (and, in the process, realize how much you forgot). Maybe one way of avoiding this cycle is to always keep the knowledge fresh, by participating in things like the TopCoder programming competitions, or continuously working through books like “Elements of Programming Interviews”, the aforementioned “Cracking the coding interview” etc.