Re:Reading, Writing, Arithmetic, and Lately, Coding
by graycat on Sunday May 11, 2014 @01:40PM
(#7729273)
Easy enough, but the bottlenecks remain:
(1) What real world problem to solve.
(2) For a challenging problem, how the heck to
solve it.
(3) How to cut through by far consistently the worst
writing anywhere in civilization -- documentation in
computing.
E.g., I'm still mud wrestling trying to
figure out why: (A) In program A, serialize an instance of a class. The result of the serialization is a byte array. (2) To check, in program A, deserialize the byte array and observe that do get the original instance back. (C) In program A, printout the byte array as hex. Transmit the byte array to program B. In program B, print out the
byte array in hex and observe that it is just the same
as it was in program A. (D) Deserialize the byte array
in program B and observe that the operation ends with
and exceptional condition. Why? Documentation clear
as mud.
Just for my basic work, I have about two cubic feet of books, nearly all badly written, and 5000+ Web pages of documentation illustrating much of the worst
mistakes in technical writing.
The bad documentation is by far the worst bottleneck.
The whole thing, the industry and the science, needs to
take Technical Writing 101. First lesson: A word used
with a meaning not in a standard dictionary is a 'term', and
never but never ever, not even once, use a term without a prior clear definition with motivation and likely examples. And, for such definitions, sure, use hyperlinks.
(5) Organization and management of
computing projects involving teams
larger that, say, half a dozen people.
(6) Computer system construction, installation,
configuration, backup and recovery, monitoring,
management, and administration.
(1) What real world problem to solve.
(2) For a challenging problem, how the heck to solve it.
(3) How to cut through by far consistently the worst writing anywhere in civilization -- documentation in computing.
E.g., I'm still mud wrestling trying to figure out why: (A) In program A, serialize an instance of a class. The result of the serialization is a byte array. (2) To check, in program A, deserialize the byte array and observe that do get the original instance back. (C) In program A, printout the byte array as hex. Transmit the byte array to program B. In program B, print out the byte array in hex and observe that it is just the same as it was in program A. (D) Deserialize the byte array in program B and observe that the operation ends with and exceptional condition. Why? Documentation clear as mud.
Just for my basic work, I have about two cubic feet of books, nearly all badly written, and 5000+ Web pages of documentation illustrating much of the worst mistakes in technical writing.
The bad documentation is by far the worst bottleneck.
The whole thing, the industry and the science, needs to take Technical Writing 101. First lesson: A word used with a meaning not in a standard dictionary is a 'term', and never but never ever, not even once, use a term without a prior clear definition with motivation and likely examples. And, for such definitions, sure, use hyperlinks.
(5) Organization and management of computing projects involving teams larger that, say, half a dozen people.
(6) Computer system construction, installation, configuration, backup and recovery, monitoring, management, and administration.
(7) Security.