I was a CS major in college, and went on to become an Enterprise Security Architect at a moderately sized and well-known financial services company. I've spent

I was a CS major in college, and went on to become an Enterprise Security Architect at a moderately sized and well-known financial services company. I've spent a good bit of my time writing or analyzing code, both for enterprise systems, as well as mobile devices (that, in turn, called those backend enterprise systems). Have I ever once had to implement a B-Tree? Has the specific knowledge of how to write an effective sorting algorithm ever been directly applied during my work day? No. Not even once. However, it's often important to understand these topics. These days, the tools are already there for you. Java, .Net, and nearly every other modern programming language already has the most common data structures and algorithms available to you, either in the language itself or via a well-respected 3rd party library. So, while you may not ever find yourself actually writing the code for these items yourself, it's important to understand how they work and the implications of choosing one over the other. Given a piece of data, how do you best store it in memory? On disk? Is a linked list sufficient? Perhaps. But what if your piece of data grows to billions of records? What about scalability? What about performance? Memory usage? Lookup and seek times? This is where an understanding of these principles comes into play. I've never had to write an encryption algorithm from scratch (nor should you. EVER.) but I can tell you there have been numerous times where I needed to know the difference between ECB, CBC, and other cipher modes and why the difference was important for a given scenario. Learning data structures and algorithms is not about the destination. It's about the journey. It's about understanding the deeper reasons and rationale behind how these items operate, so that you can gain a better understanding of computing in general.