Counter-point: I am the technical lead on a team of 8. We ship a new data science product (or major enhancement to an existing product) about every 9 months, fr

Counter-point: I am the technical lead on a team of 8. We ship a new data science product (or major enhancement to an existing product) about every 9 months, from inception through putting it in maintenance mode. Our products generate double-digit multiples of my team's costs in revenue and have a reputation for being the easiest to implement and most stable for our customers. We have one CS guy, who is a junior engineer, and he doesn't even have a Master's degree. I can't remember the last time an in-depth discussion about which data structures or algorithms to use actually came up in a design, or even mattered too much in the end. The reason, as I see it, is simple: the engineering work the Principal Engineer and myself, with our juniors we mentor, do, is far more important than data structures and algorithms trivia. Once it gets to the point of deciding which of these to use the real problems have been solved already. Now, these choices aren't unimportant: the choice of a bad algorithm or data structure might cause problems, but they're choices that are in the main easy to understand and make when compared to the thought that goes in to the rest of the system.