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:
Will this change in how I think improve some aspect of how I write software?
Will it break some other aspect?
What led the people who did this to do so?
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:
Ullman's Elements of Standard ML. Then go look at the ML language family and read the papers of people who designed the various members and what drove them.
Leo Brodie's Starting Forth and Thinking Forth, then go mess with Pygmy Forth and read about what Charles Moore has done with colorForth.
Spend some time working with Pharo or Self, and learn what it's like not to have a separation of a system into programs, shell, etc. Then go read the literature of people who worked on these systems and find out about the problems with them.
Learn to write Prolog.
Read a bunch of Dijkstra's EWDs, especially the late ones, and get into his ideas on calculational mathematics. And read a bunch of Alan Kay's work. These two couldn't stand each other's work, and being able to switch back and forth between their perspectives is a diabolically valuable ability.
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 🦄
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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 🦄