You have to learn the big concepts in computing. These include low-level details like how a Von Neumann architecture works, memory and pointers, I/O, how the OS, network, and file system work, etc. But it also includes useful abstractions such as data structures and ADTs, algorithm efficiency, objects, functional programming and lambda calculus, design patterns, and big-picture questions of what kind of system should I be building in the first place. (Should I build one big monolith? Should I break it down into pieces? How should they communicate? and so forth)
This will necessarily require familiarity with a variety of languages and ways of thinking about code. When you find a particular style of building software that suits you well, you can invest a lot of time in becoming expert at building that kind of system, making it run fast, and making it clean and maintainable. But you will also have a deep well of knowledge to draw from because you've looked at the computing field from a variety of perspectives.
In other words, both Hickey and Norvig are right, to an extent.
This will necessarily require familiarity with a variety of languages and ways of thinking about code. When you find a particular style of building software that suits you well, you can invest a lot of time in becoming expert at building that kind of system, making it run fast, and making it clean and maintainable. But you will also have a deep well of knowledge to draw from because you've looked at the computing field from a variety of perspectives.
In other words, both Hickey and Norvig are right, to an extent.