> How do you understand maintainability and architectural concerns without understanding algorithmic underpinnings? > At the base level, leetcode problems and

> How do you understand maintainability and architectural concerns without understanding algorithmic underpinnings? > At the base level, leetcode problems and maintaining a complex system in practice requires key understandings: what your problem is, which tool to use, and how your tool works/tradeoffs. It follows what (I hope is) a universal truth: if you want to be a good coder, you need to know code. I don't buy this at all. Orthogonal things are orthogonal. I work with developers who probably have no idea what a red–black tree is but I'd trust them to advise on how to structure a complex project based on user requirements. I'd rather they spent their time getting better at the latter and I don't see how getting good at puzzles is especially helpful in doing that. Programming in the large is usually about managing complexity over time. It has more akin to designing a large factory than it is to understanding how a pocket watch works. There's a huge human factor as well - complexity arises where people meet code and understanding how to keep that complexity in check is the key to being a good programmer.