Solution architect here. Having to grok some new tech quickly and put it to use ASAP is almost a weekly occurrence. The most important thing (to me) when learn

Solution architect here. Having to grok some new tech quickly and put it to use ASAP is almost a weekly occurrence. The most important thing (to me) when learning a new technology is learning what it _can do_ in the most complete way possible. Reason: when I invest into learning a technology, afterwards I want to be able to quickly pick the feature that is most suitable for a particular need without the risk to reinvent some kind of wheel in a dumb and costly way. And for that I must have a mental map of all the features, at least superficially. Everything else you an look up. (The same principle goes for the total of all the technologies I have learnt before). In practice I make sure I scan _all_ the documentation for the product and build a cheat sheet of the features, concepts, configuration flags, best practices etc. I will consult the sheet later, but the process of building it helps immensely to construct the map of _what's possible_ with this thing. A recent example - I had to design a GCP solution while not having much experience in GCP. I sat down and browsed the introductory docs of all the hundred plus (?) products that GCP offers, and built a cheat sheet categorizing the features and intents of each and every one. This took me around two days, and ultimately of in the solution I only used a handful services out of the hundred. But these were exactly the ones that solved the problem, including a couple of exotic ones that I wouldn't have guessed even existed. For the cheat sheets I use Obsidian which is excellent for this.