Pursuit of Technical Excellence

Posted: 31 March 2017

I try and do as many coding problems as possible as I believe this will hone my technical skills. Therefore, I solve Project Euler questions in my free time. It is very tempting to finish as many Project Euler questions as possible and then wear it as a badge of honour. I must say I have fallen into that trap. In retrospect, it is a very bad idea. I am reminded of the book, Art and Fear, which I read in 2017. The quote goes:

The underlying problem with this is not that the pursuit of technical excellence is wrong, exactly, but simply that making it the primary goal puts the cart before the horse.

I sort of understand this better now. What I should really be pursuing is a better understanding of problems, not just solving them. For example, I recently solved Project Euler 81, 82, 83. They were all dynamic programming problems as I wanted to practice that. In the past, I would just hack out some code and get the correct answer. Now, I think about the various approaches to solving it. Should I use a top down or bottom up DP? What about the space saving trick? What’s the complexity of each method? Is there enough space on the recursion stack? What if we need to output the path as well? If one thinks thoroughly about all possible variants of the problem, then that’s true mastery. It’s not about facing as many DP problems as possible and then achieving mastery. It’s about thinking deeply into a few canonical DP problems.

This also brings me to a post that I read about recently. The answer by Leo Polovets was very good. It’s a simple question, but it really tests the candidate.

Remember: Quality, not quantity.