First thing I thought about when reading this was the classic tree swing picture set of what the user wanted, what the developer did etc etc. The type of documentation your on about, ie the devlopers logic and resoning behind the software, ie the mentality/mind-set folled at the time is a fasicnating insight. Sadly with commercial software we have historicly been shut of from any insight and beyond the devlopers names hidden in some easter-egg crits page burried deep in the software we never realy knew. One of the main reasons is companies wanted to hide there developers and code secrets to maintain there advantage in the market. Now todays market is more open, more about the product being good and not how it is marketed as much (though that still plays out). So we can read up from individual developers in there blogs and thankfully for many companies encourage that aspect more as it is seen as good PR marketing and gains sales/face with the public.
In the past we did also have alot of tue computer magazines with technical articles that would still cut it today. This entailed quality interviews and some good insighful questions. Then computer magazines all started turning into wanabe Which magazines and targeted people wanting to learn about computers but still fail to operate a VCR. This turned magazines today into something the hacker mentality geeks would not touch. But we had the web then, so with that many more quality articles direct from the developers started to appear. We all have heard about John McCormack of Doom fame, not as much due to Doom, but in that he gave alot of good interviews with technical knowledge that allowed you to more closely follow his mindset.
Another aspect of note is alot of software years ago was all optimised for size and speed as it was more a limitation than we have today and with that many short-cuts impacting how the user intereacted had more chance of going thru than not. Nowadays it is more design driven by customer feedback than not, but it is often a balance of work/effort (heck I see American English as a option in so many software packages and no British English, not as bad today but still noticable shortcut in design).
There is also the case that say finger in the air that every developer in the World working on a commercial project has at some stage in the life, had to make a design change not based on time. Be it a cut-off date, release date/target. Many cases and for some software you notice it as they have more bugs and this is why many people prefer to not touch intitial X.0 releases and wait until a few sub relesaes have passed, 3 being popular given there was no service pack 3 for vista and win7 yet was for windows XP but that is a bad example yet valid for many.
So with all those factors many developers don't have the time to dig in and also the type of code documentation has not evolved in a way that mandates it beyond standards and in that the most readable computer language we have in use today would safly be COBOL. So from developers point of view, unless they solely work on a area of code then they have a hard time documenting it for there own use let alone doing a blog about it.
Sadly some of the best ones would be the reminise type story's from developers of years gone by and by this I mean they seem to tell things with a hint of hindsight thrown in and are able to say back then we did this, and I still shudder today why given we know this and that now.
You don't get that level of insight that you get with a ongoing blog from developers, so you miss out on them being able to talk about the code and what they did and why as a complete application perspective and will never get that retrospective viewpoint that is often: we did this, it seemed all the trend back then and nowadays we would be taken out and shot for even mentining that approach.
So in short things are better than they once was for developer insights but the best developer insights are the retrospective ones when they can admit to this approach to being wrong and that being ahead of its time etc.
As for manuals and missing out on all that handy hardcopy I agree it is a sad loss, though at least today you can get it updated and corrected much quicker and are able to use search to find that page you want without playing index lookups manualy with ...paper.
Though the market for books(physical and ebook format) for learn X in 24 hours or a dummies guide that explain the software from a fixed mindset instead of the generalised approach taken by formal documentation. You also have advanced guides and tricks and tips style books for those wanting something more at there level. That has always been the case but the feild is somewhat larger than it was and always growing.
But I did like the nice foot_ pile of manuals with some software, made paying XXX amount seem more palatable as apposed to today paying XXX amount and being pointed to a URL which you download the software and for XX more you get a copy on a disc and still no manual to swat flies with.
Still another aspect about today is that you can usualy twitter the developer team or failing that get enough friend emoing on facebook and the developers not only talk to you but have to listern to recoup PR. But users bullying developers is and always has been a two way process.
In the past we did also have alot of tue computer magazines with technical articles that would still cut it today. This entailed quality interviews and some good insighful questions. Then computer magazines all started turning into wanabe Which magazines and targeted people wanting to learn about computers but still fail to operate a VCR. This turned magazines today into something the hacker mentality geeks would not touch. But we had the web then, so with that many more quality articles direct from the developers started to appear. We all have heard about John McCormack of Doom fame, not as much due to Doom, but in that he gave alot of good interviews with technical knowledge that allowed you to more closely follow his mindset.
Another aspect of note is alot of software years ago was all optimised for size and speed as it was more a limitation than we have today and with that many short-cuts impacting how the user intereacted had more chance of going thru than not. Nowadays it is more design driven by customer feedback than not, but it is often a balance of work/effort (heck I see American English as a option in so many software packages and no British English, not as bad today but still noticable shortcut in design).
There is also the case that say finger in the air that every developer in the World working on a commercial project has at some stage in the life, had to make a design change not based on time. Be it a cut-off date, release date/target. Many cases and for some software you notice it as they have more bugs and this is why many people prefer to not touch intitial X.0 releases and wait until a few sub relesaes have passed, 3 being popular given there was no service pack 3 for vista and win7 yet was for windows XP but that is a bad example yet valid for many.
So with all those factors many developers don't have the time to dig in and also the type of code documentation has not evolved in a way that mandates it beyond standards and in that the most readable computer language we have in use today would safly be COBOL. So from developers point of view, unless they solely work on a area of code then they have a hard time documenting it for there own use let alone doing a blog about it.
Sadly some of the best ones would be the reminise type story's from developers of years gone by and by this I mean they seem to tell things with a hint of hindsight thrown in and are able to say back then we did this, and I still shudder today why given we know this and that now. You don't get that level of insight that you get with a ongoing blog from developers, so you miss out on them being able to talk about the code and what they did and why as a complete application perspective and will never get that retrospective viewpoint that is often: we did this, it seemed all the trend back then and nowadays we would be taken out and shot for even mentining that approach.
So in short things are better than they once was for developer insights but the best developer insights are the retrospective ones when they can admit to this approach to being wrong and that being ahead of its time etc.
As for manuals and missing out on all that handy hardcopy I agree it is a sad loss, though at least today you can get it updated and corrected much quicker and are able to use search to find that page you want without playing index lookups manualy with ...paper.
Though the market for books(physical and ebook format) for learn X in 24 hours or a dummies guide that explain the software from a fixed mindset instead of the generalised approach taken by formal documentation. You also have advanced guides and tricks and tips style books for those wanting something more at there level. That has always been the case but the feild is somewhat larger than it was and always growing.
But I did like the nice foot_ pile of manuals with some software, made paying XXX amount seem more palatable as apposed to today paying XXX amount and being pointed to a URL which you download the software and for XX more you get a copy on a disc and still no manual to swat flies with.
Still another aspect about today is that you can usualy twitter the developer team or failing that get enough friend emoing on facebook and the developers not only talk to you but have to listern to recoup PR. But users bullying developers is and always has been a two way process.