For me, the joy of engineering is problem solving. If you can solve a problem at hand with skills you have, don't stress over knowledge you don't have -- we are all necessarily ignorant in areas because there isn't enough time to become an expert in everything.
That said, some things _do_ need heavy algorithmic lifting; recognizing that your problem falls into this category saves time. Maybe you can reuse code that does X instead of rederiving and reimplementing it. Maybe the client's performance requirements are asymptotically impossible to achieve. Knowing this lets you confront the issue sooner and gives you a stronger claim than "I can't do this" if they push back.
Algorithms can be a force multiplier for your skill. A recent project required a key-value associative array. Unfortunately we don't yet know what the key strings will look like (long? short? self-similar?), the number of keys (5? 100? 8000000000?) or the expected use (lots of inserts and deletes? mainly lookups?), and the best approach depends on these variables.
Now, any single approach would be easy to implement, but maybe not so easy to adapt if (when...) requirements change. Instead, I'm using STL containers and algorithms as modular building blocks. Changing from a set to a trie? Changing from a vector to a list? A few lines of changes (and sometimes none).
Now, would you call this algorithmic knowledge or programming (C++) knowledge? Well, I'd say somewhere in between... in a sense I'm punting to a library that's been written and tested by smarter people than me, just like I might use any other framework. On the other hand, if I don't know what it means when the framework says "lists take O(n) for lookups", or "vectors offer constant time random access", then even when requirements are clear I might not be able to map them back to the best implementation.
Algorithms are just abstracted solutions to common problems. A binary search doesn't (mostly) care if you are dealing with integers or widgets or FoobarConfigurationManagers. It just says "follow these steps to find an element." Programming is full of common problems: iterating over a list; multiplying the result of two functions; adding a set of numbers. Simple, right? But combine these simple tasks in the right way and you have an algorithm to calculate convolutions.
Likewise, combining simple algorithms can solve a more complex problem.
That said, some things _do_ need heavy algorithmic lifting; recognizing that your problem falls into this category saves time. Maybe you can reuse code that does X instead of rederiving and reimplementing it. Maybe the client's performance requirements are asymptotically impossible to achieve. Knowing this lets you confront the issue sooner and gives you a stronger claim than "I can't do this" if they push back.
Algorithms can be a force multiplier for your skill. A recent project required a key-value associative array. Unfortunately we don't yet know what the key strings will look like (long? short? self-similar?), the number of keys (5? 100? 8000000000?) or the expected use (lots of inserts and deletes? mainly lookups?), and the best approach depends on these variables.
Now, any single approach would be easy to implement, but maybe not so easy to adapt if (when...) requirements change. Instead, I'm using STL containers and algorithms as modular building blocks. Changing from a set to a trie? Changing from a vector to a list? A few lines of changes (and sometimes none).
Now, would you call this algorithmic knowledge or programming (C++) knowledge? Well, I'd say somewhere in between... in a sense I'm punting to a library that's been written and tested by smarter people than me, just like I might use any other framework. On the other hand, if I don't know what it means when the framework says "lists take O(n) for lookups", or "vectors offer constant time random access", then even when requirements are clear I might not be able to map them back to the best implementation.
Algorithms are just abstracted solutions to common problems. A binary search doesn't (mostly) care if you are dealing with integers or widgets or FoobarConfigurationManagers. It just says "follow these steps to find an element." Programming is full of common problems: iterating over a list; multiplying the result of two functions; adding a set of numbers. Simple, right? But combine these simple tasks in the right way and you have an algorithm to calculate convolutions. Likewise, combining simple algorithms can solve a more complex problem.