Regarding the technical writing, that is indeed one of the very best examples when conveying an idea with a mindset or process on how that came to be (to varyin

Regarding the technical writing, that is indeed one of the very best examples when conveying an idea with a mindset or process on how that came to be (to varying degrees). It's not just a summary of facts or a list of tasks, but when well written it contains the core, the context, and how the core out of that context came to be. If the reader then reads it, they will not only learn the subject, but often also how that information was obtained in the first place and get a sense as to how the information was optimised for the subject, what was dismissed (and why) and often gives you a transfer of thought that allows you to continue to build on that instead of having to do the same exact learning process over again to get (and this is a lucky pun) on the same page. Conveying an idea is hard enough as it is with the languages we have, but writing it down and having to think ahead of time what the reader might think, might already know, and might want to do afterwards, or ponder about upon finishing the work, that is a very underestimated specialism. It enables not only knowledge transfer but practically brings the level of understanding of the reader(s) to a new minimum level (being a higher level than before but not everyone might get the same out of it). I work with a group of people in tech with varying backgrounds, ages and plans for the future, but when we need to make sure everyone has at least some equal foundation to start off from, we have at least one technical writeup (some chapters in a book, or a series of well written articles) combined with exercises to make sure that that base layer is there. You cannot really do that effectively if you were to try that with... tweets. Or just videos. Or a simple workshop. Getting somewhere still requires real work and real (time/attention) investment. Well written and researched information is at the center of this. Every now and then I read a technical book on a subject I am not familiar with or never had a real-life purpose for. For example, a lot of projects never had to use a custom data format with custom parsers, or a new domain-specific language. Yet reading a well written book on GNU Bison can be fantastic. (i.e. the Flex & Bison one from O'Reilly) Even if you end up never writing a .y file or having a need for a custom syntax parsing system. Strangely enough, while the subject is different, and the goal is different, it can be just as entertaining or maybe even enriching as reading The Gargoyle (by Andrew Davidson) 15 years ago. No relation in content or context except that both are books.