I've written before about how I struggle with algorithm problems. I'm finally, eight months after diagnosing the problem, sitting down to figure out what it is about algorithms that I find difficult.

I'm doing two things differently. The first is that I'm using a textbook, specifically Skiena's Algorithm Design Manual. The second is that I'm doing them without time pressure. By comparison, the last time that I sat down to Learn Algorithms, around 5 years ago, it was during my time at the Recurse Center (nee Hacker School). I took an online class from Stanford taught by Tim Roughgarden; assignments were due weekly and the learning material was presented via video lectures.

I'm still going with them with a friend; for the Roughgarden course I found a study buddy among my batchmates. Now, I'm pairing with my sister on them.

I think the biggest thing that's changed is my perspective on programming. The first time around I was in awe of algorithms. They were this thing that separated the Real Programmers from the rest of us that merely toyed around at programming.

This time, I'm less intimidated by the concept, and far more awed by the awesome power of an O(lg n) equation.

I've realized a few things in the few short weeks since I started going thrugh Skiena's very well written book. The first is that, as always, the presentation style matters. Skiena's book is far and away the best work on algorithms for experienced programmers that I've yet encountered. The discussion is accessible, the progression is sensible. All of the homework sections for the chapters are relevant outgrowths of the foregoing discussion. The exercises are hard enough that completing them feels like an accomplishment, but they're not so difficult as to be discouraging. It's definitely not the best book for everyone, but it certainly feels as though I came across it at the right time.

Secondly, Big O thinking is incredibly practical. Writing a naive algorithm in n² and then tweaking it until it runs is n-something time is both incredibly satisfying as well as useful. Writing inefficient programs is incredibly impractical, both from a machine and energy standpoint as well as a human time cost. With this new lens of practicality, understanding how to evaluate routines seems like a common sense to programming. Why not learn how to make better use of your machine?

Another big realization that Skiena's book helped me with, greatly, is understanding what my role is in the realm of algorithms. It sounds ridiculous, but, at some level, I think that I had this notion that being 'good at algorithms' meant that I'd be expected to produce the next shortest path algorithm, a Neigut's answer to Djikstra if you will. Skiena does a great job of couching algorithmic thinking as a framework for problem solving. Given a problem, what tools in your toolset are the best ones to try and solve the problem.