Software Design
Throughout my experience of reading about software (yes, reading and not writing :) ), I have come about to really like and admire the design decisions that take place, that eventually get implemented and either make or break entire codebases, especially when writing libraries and/or complex tools. This aspect of writing software not only comes from someone with experience, but also from someone with a purpose, and hence a vision they want to accomplish: which is fairly uncommon nowadays due to the career-driven nature and popularity of software engineering jobs.
Such decision processes and "philosophies" are prevalent in almost every widely used software product out there. No piece of software, used by millions, is mediocre. This provides for an extremely interesting and valuable source of information in order to learn from such examples. I am personally fascinated to read about the thought processes and design decisions taken by the architects of large codebases and software products utilised by generations of developers.
One subtle aspect of trying to read through these essays/blogs/walkthroughs is, it is not important to understand the technicalities and the inner workings of such massive projects, even professionals would take years! The best lesson, at least for me, is to look at the what, why and how of a particular decision and understand how similar situations and problems can arrive when I myself venture out to writing designing a project. The architects (most of the times) explain how they came about a problem, why they implemented (or didn't) a particular feature and other semantic decisions, which provide for a rich source of context and rationale behind the system's design.
All that being said, I think personally I am too inexperienced in order to learn a substantial amount from some of the blogs I have read, but nonetheless, it is often exhilarating to find common design patterns in unexpected places. Apart from that, it is often inspiring to read about certain codebases which are decades old. Others ? They offer valuable and quite intriguing examples of how/what problems certain developers faced, and how they came about the solutions. There are many other examples that are good, but due to being highly technical and niche, aren't pragmatic for the average developer. I nonetheless read through these blogs to at least understand their problem solving approaches (though to actually solve problems of that calibre, one needs to be an expert in the field).
I believe the want of designing any software comes from having a deep passion and appreciation of code, both as a tool to solve real life problems and an art. I personally tend to be more on the artistic side, but lately, I am trying to design some real life problem solutions as well.