It's good to first know what you're asking for. A "software architect" position usually refers to the job in an enterprise setting. This clarification may be useful.
What you're describing as examples is more about people who are actively engaged with the programming community, present and past, with a very specific set of questions:
So once you have been through this many times you look at a new library, framework, or language, and can quickly categorize most of it. Usually you can categorize all of it, in which case it's interesting only insofar as you may have to use it to get paying work done. Sometimes it remains interesting because of interactions that you haven't seen tried before (e.g., Scala trying to wed the Java type system with Hindley-Milner type systems, and experiment that I feel was a failure). Occasionally there's an interesting piece of something and you spend a few hours or a few days beating on it, trying to find what's there.
When you're just starting out, you can flail at the usual suspects and get a lot of mileage. A short list of things that I guarantee will not be a waste of your time:
SICP is a wonderful book. If you enjoy it, go to it. Branch prediction is worth understanding. If you know probability, it should take you about half an hour to understand how it's supposed to work. There's no reason to understand it at a silicon level unless you're designing chips or fighting with truly bizarre performance problems. Likewise, Types and Programming Languages is more machinery than you probably need right now. If you find yourself building type systems or programming languages, then you will read it cover to cover and it will seem like the most wonderful, applied advice ever. If you aren't in that game, you're better off getting the basics down so you can understand how various type systems differ and what the experts mean when they argue about them, and then moving on to something else. Remember, your time is finite.
Yeah, I guess title is confusing, that is why I also wrote extended body to explain the question. I wasn't able to pick better title, like "how to gain deep insight in development" or "how to become @hillelogram". So I decided to name those people architects and explain question in the text.
I like your explanation (of my question) you got it right. And thanks for suggestions 🦄
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.