5 ms·

Computing isn't too easy, it's too hard, and modern systems aren't contributing a solution, they are just glossing it over with their crippled tools. Not just c

Computing isn't too easy, it's too hard, and modern systems aren't contributing a solution, they are just glossing it over with their crippled tools. Not just crippled tools for office workers, also crippled tools for programmers and artists. Some things might not be possible to fix. Teaching people to RTFM, for instance. No search engine will be able to replace consistent and comprehensive documentation written by the people who know the system intimately, but it's hard to convince most users, many developers, even, that this is actually worth the effort it takes, both to read and write. Being able to model data and reason about complexity, even for non-programmers, is a something else you can't really get around. Ever had people in your organization with outlandish ideas that just don't compute, right up there with "why don't you just write a program that writes programs". I've had to explain that yes, I can write a program that does what you want, but it's not going to finish before the heat death of the universe. During all of this arguing a whole bunch of computers are sitting idle when they could be doing useful work if only their operators knew how to tell them to. I too cut my teeth on HyperCard, and the best thing about it really focused on doing things people really needed. Organizing and reasoning about people's data, whether it was appointments, contacts, orders, stock, notes, things that are hard to do on paper, but easy for a machine to handle. It went straight to the core of the issue. How to best tell the computer to do useful work. Of course it failed in many respects, but the real tragedy is that they seemed to stop trying after that.

Swizec 12y ago
> Some things might not be possible to fix. Teaching people to RTFM, for instance. No search engine will be able to replace consistent and comprehensive documentation written by the people who know the system intimately, but it's hard to convince most users, many developers, even, that this is actually worth the effort it takes, both to read and write. People will RTFM if it isn't boring, dry, and useless. There's a fine balance to be struck between nice-to-read prose and giving people exactly what they need, quickly enough for them to actually read your stuff. But the thing is, if your documentation is difficult to read and doesn't flow well, it might as well not have been written. Everybody will give up before they learn. And vice-versa, if your documentation is TOO nice to read and does too much hand-holding. People will gloss it over and miss important details. Teaching is hard. Much harder than people give it credit. And because there are no unicorns who can both intimiately understand the system and be good at documenting it, you should do the next best thing - have a person with enough technical background to be able to talk to the experts, but is also good at writing about it write your docs. This seems to be the approach taken by most self-published tech writers these days. They're good enough to understand the system, but also decent enough at writing about it.
- agumonkey 12y ago
  I really RTFM when back against the wall, otherwise I only SkimTFM. I wish embedded manuals, instead of disconnected words, having a REPL, a failing test suite to see how the pieces work together. Brett Victor style. Maybe it's an overly lazy desire, and nothing will replace the fact that you're willing to focus on reading what people wanted to express about a program. Also, embedded/repl would avoid outdated documentation drift.
jeremysmyth 12y ago
Some things might not be possible to fix. Teaching people to RTFM, for instance. No search engine will be able to replace consistent and comprehensive documentation written by the people who know the system intimately, but it's hard to convince most users, many developers, even, that this is actually worth the effort it takes, both to read and write." This is compounded by the trend toward instant gratification in pretty much everything. - In your normal day-to-day work, you're likely to have productivity pressures that limit your ability to do freeform thinking and learning, so you're pressured to solve small problems in a local way. - Search engines make it possible to find the answer to almost any question you might think of, and that makes it feel less necessary to do a deep dive into some topic. - ...and trends in technology make it far easier for consumers (and yes, even producers are consumers) to treat every problem with a "single-serving solution" However, the larger problem is that we naturally do not know what we do not yet know. A deep R into TFM is quite likely to teach something necessary that I didn't already know. Think, for example, of a beginning programmer who quite successfully builds all the functional requirements of a simple web app, but fails to consider the non-functional requirements because he didn't know that he had to. SQL injection is something orthogonal to the application's actual purpose, so I won't actually think about it until either I'm stung by it, or someone else tells me about it. I wouldn't know to ask otherwise.
- philbarr 12y ago
  The problem is: there's too many manuals. We don't have time to read them all. In fact, I think one of the skills you learn as you gain experience in software development is choosing your moments. When you can just google it, and when you need to get a cup of coffee and RTFM.
  - jeremysmyth 12y ago
    ...which suggests that computing is not too easy at all, as per grandparent comment. See also http://www.joelonsoftware.com/articles/LeakyAbstractions.html http://www.joelonsoftware.com/articles/LeakyAbstractions.htm... : During my first Microsoft internship, I wrote string libraries to run on the Macintosh... Everything I did was right from K&R -- one thin book about the C programming language. Today, to work on CityDesk, I need to know Visual Basic, COM, ATL, C++, InnoSetup, Internet Explorer internals, regular expressions, DOM, HTML, CSS, and XML. All high level tools compared to the old K&R stuff, but I still have to know the K&R stuff or I'm toast.
sp332 12y ago
The problem is sweeping all the complexity (and power) under the rug in pursuit of "easy". Modern computing hides all the cool stuff. We should expose the difficult and powerful side, even if it's less easy.

Swizec 12y ago

> Some things might not be possible to fix. Teaching people to RTFM, for instance. No search engine will be able to replace consistent and comprehensive documentation written by the people who know the system intimately, but it's hard to convince most users, many developers, even, that this is actually worth the effort it takes, both to read and write. People will RTFM if it isn't boring, dry, and useless. There's a fine balance to be struck between nice-to-read prose and giving people exactly what they need, quickly enough for them to actually read your stuff. But the thing is, if your documentation is difficult to read and doesn't flow well, it might as well not have been written. Everybody will give up before they learn. And vice-versa, if your documentation is TOO nice to read and does too much hand-holding. People will gloss it over and miss important details. Teaching is hard. Much harder than people give it credit. And because there are no unicorns who can both intimiately understand the system and be good at documenting it, you should do the next best thing - have a person with enough technical background to be able to talk to the experts, but is also good at writing about it write your docs. This seems to be the approach taken by most self-published tech writers these days. They're good enough to understand the system, but also decent enough at writing about it.

agumonkey 12y ago
I really RTFM when back against the wall, otherwise I only SkimTFM. I wish embedded manuals, instead of disconnected words, having a REPL, a failing test suite to see how the pieces work together. Brett Victor style. Maybe it's an overly lazy desire, and nothing will replace the fact that you're willing to focus on reading what people wanted to express about a program. Also, embedded/repl would avoid outdated documentation drift.

jeremysmyth 12y ago

Some things might not be possible to fix. Teaching people to RTFM, for instance. No search engine will be able to replace consistent and comprehensive documentation written by the people who know the system intimately, but it's hard to convince most users, many developers, even, that this is actually worth the effort it takes, both to read and write." This is compounded by the trend toward instant gratification in pretty much everything. - In your normal day-to-day work, you're likely to have productivity pressures that limit your ability to do freeform thinking and learning, so you're pressured to solve small problems in a local way. - Search engines make it possible to find the answer to almost any question you might think of, and that makes it feel less necessary to do a deep dive into some topic. - ...and trends in technology make it far easier for consumers (and yes, even producers are consumers) to treat every problem with a "single-serving solution" However, the larger problem is that we naturally do not know what we do not yet know. A deep R into TFM is quite likely to teach something necessary that I didn't already know. Think, for example, of a beginning programmer who quite successfully builds all the functional requirements of a simple web app, but fails to consider the non-functional requirements because he didn't know that he had to. SQL injection is something orthogonal to the application's actual purpose, so I won't actually think about it until either I'm stung by it, or someone else tells me about it. I wouldn't know to ask otherwise.

philbarr 12y ago
The problem is: there's too many manuals. We don't have time to read them all. In fact, I think one of the skills you learn as you gain experience in software development is choosing your moments. When you can just google it, and when you need to get a cup of coffee and RTFM.
- jeremysmyth 12y ago
  ...which suggests that computing is not too easy at all, as per grandparent comment. See also http://www.joelonsoftware.com/articles/LeakyAbstractions.html http://www.joelonsoftware.com/articles/LeakyAbstractions.htm... : During my first Microsoft internship, I wrote string libraries to run on the Macintosh... Everything I did was right from K&R -- one thin book about the C programming language. Today, to work on CityDesk, I need to know Visual Basic, COM, ATL, C++, InnoSetup, Internet Explorer internals, regular expressions, DOM, HTML, CSS, and XML. All high level tools compared to the old K&R stuff, but I still have to know the K&R stuff or I'm toast.

sp332 12y ago

The problem is sweeping all the complexity (and power) under the rug in pursuit of "easy". Modern computing hides all the cool stuff. We should expose the difficult and powerful side, even if it's less easy.