Is there a book somewhere that tries to set out all of the things that experts know about computing that they don't remember learning?
(In Zed Shaw's conception, this might correspond to "learn computing the hard way".)
I see his examples and other examples here in this discussion, and it makes me wonder about the value (or existence) of a very thorough reference.
I've also encountered this when working with lawyers who wanted to have a reference to cite to courts about very basic facts about computing and the Internet. In some cases, when we looked at the specifications for particular technologies or protocols, they didn't actually assert the facts that the lawyers wanted to cite to, because the authors thought they were obvious. I remember this happening with the BitTorrent spec, for example -- there was something or other that a lawyer wanted to claim about BitTorrent, and Bram didn't specifically say it was true in the BitTorrent spec because no BitTorrent implementer would have had any doubt or confusion about it. It would have been taken for granted by everyone. But the result is that you couldn't say "the BitTorrent spec says that" this is true.
Another example might be "if a field is included in a protocol and neither that layer nor a lower layer is encrypted with a key that you don't know, you can see the contents of the field by sniffing packets on the network segment". It might be challenging to find a citation for this claim!
So we could also wish for a "all our tacit knowledge about computing, programming, and computer networking, made explicit" kind of reference. (I'm not sure what kind of structure for this would be most helpful pedagogically.)
I would find some resource of assumed knowledge useful in my career field of chemistry and biology, but what really resonated with me from zedshaw's piece was something even more basic to the field. The biggest hurdle I had to learning to code was finding a text editor. The next big hurdle I had was finding somewhere to host my one-page HTML site. I ended up asking a friend who suggested Sublime Text and Amazon AWS. At that point I'd been reading HN for two years and had heard of these things, but not understood their central utility (or the utility of similar such general services) to doing anything with code. This is the level of beginner that I would hope zedshaw's efforts would target, someone like me from last year.
I want to emphasize that while learning abstract functions, and understanding that code syntax is an abstraction for electrons moving through logic gates are fundamental concepts for an early programmer, learning those concepts was less frustrating for me than finding somewhere to write the text I had learned from codecademy. I am a chemist by formal training, I took an extremely abstract multivariable calc course in college that taught me Big and Little O, and functionalized concepts most people learn by rote "drills," and I consider learning new concepts my strongest career skill. I don't mean to humblebrag here, but rather to refute the only-somewhat-popular sentiment I've seen on HN that non-coders "can't get shit done." No. I am a non-coder that does shit. In moving from chemistry to neurobiology and biophysics, there are basic skills that can't be found in a textbook, like _this is a pipette_, and _this is a flask to grow cells_, and if you don't know those things you won't be able to do experiments, and you'll fail the informal subtext of an interview. The best resource I've found in (three years of reading HN anonymously) for analogous tool-teaching in code has been Michael Hartl's book on learning Rails, so thanks again mhartl! The first two chapters of that resource were more treacherous (but ultimately well-guided and successful) than teaching myself d3.js. A true, zero-level, adult beginner's guide to some code---manipulating an excel sheet in Python, writing an API-interacting tweet bot---would be a great boon to people like me.
Charles Petzold's book 'Code' has a lot of this very basic, low-level information. It basically builds up from basic information theory to computers. It's not going to have everything you're looking for but I was surprised how much of it I "knew" without recalling where I learned it or how it connected to other things.
I had a similar experience with Code Complete (I know most of what's in it but I have no idea when I learned it). I don't know if it's as basic as @schoen wanted but it might be close.
You will likely have seen advanced developers recommending it. But it is meant to teach routine daily stuff like how to name variables, lay out functions, why we want abstraction layers, and the like. And it really is aimed at people who may know nothing about code construction.
Okay, thanks. I read it cover-to-cover before I interviewed at Microsoft my senior year in college. But - like the developer in Zed's article - I must have forgotten. :)
> Another example might be "if a field is included in a protocol and neither that layer nor a lower layer is encrypted with a key that you don't know, you can see the contents of the field by sniffing packets on the network segment". It might be challenging to find a citation for this claim!
The term of art here (as used in patent law, for instance) would be "person having ordinary skill in the art". Something like that (if you don't encrypt something in a network protocol, it can be sniffed) is "obvious to a person having ordinary skill in the art".
But yeah, that does make it difficult to cite sources for them. And in particular, it's difficult to throw the book at someone who doesn't take those things as obvious when there's no such book.
Another "obvious" thing that I don't know a citation for: it's impossible to store a piece of information in a binary such that it cannot be read by a person who has a copy of that binary. (Practical corollary: there's no such thing as a piece of information that's too secret to include in an Open Source driver, but that can be included in a binary driver.)
Patent cases are definitely going to include expert testimony on what someone with ordinary skill in the art knows or believes, but other kinds of court cases (or types of participation in a case) don't always have a simple opportunity to introduce expert testimony -- like writing an amicus brief.
So it would be pretty awesome to have the Book of Tacit Computing Knowledge somewhere.
I don't know of such a book that's targeted to experts, but you can get a good idea of those things by skimming the first 2 or 3 chapters of Zed's [Learn Python the Hard Way](http://learnpythonthehardway.org/book/ex0.html), and Appendix A.
I was recently working on a case and I need a definition of software library. Couldn't find one anywhere. So many of the basics of programming are undefined it makes arguing about programming incredibly difficult -- see every discussion of what a functional language is or strong vs weak typing.
Wikipedia has an article on libraries, which includes the following definition:
"In computer science, a library is a collection of implementations of behavior, written in terms of a language, that has a well-defined interface by which the behavior is invoked."
> things that experts know about computing that they don't remember learning?
After a certain point, you can learn a lot about something by teaching it, because doing so forces you to re-evaluate things which you've internalized and forgotten.
(In Zed Shaw's conception, this might correspond to "learn computing the hard way".)
I see his examples and other examples here in this discussion, and it makes me wonder about the value (or existence) of a very thorough reference.
I've also encountered this when working with lawyers who wanted to have a reference to cite to courts about very basic facts about computing and the Internet. In some cases, when we looked at the specifications for particular technologies or protocols, they didn't actually assert the facts that the lawyers wanted to cite to, because the authors thought they were obvious. I remember this happening with the BitTorrent spec, for example -- there was something or other that a lawyer wanted to claim about BitTorrent, and Bram didn't specifically say it was true in the BitTorrent spec because no BitTorrent implementer would have had any doubt or confusion about it. It would have been taken for granted by everyone. But the result is that you couldn't say "the BitTorrent spec says that" this is true.
Another example might be "if a field is included in a protocol and neither that layer nor a lower layer is encrypted with a key that you don't know, you can see the contents of the field by sniffing packets on the network segment". It might be challenging to find a citation for this claim!
So we could also wish for a "all our tacit knowledge about computing, programming, and computer networking, made explicit" kind of reference. (I'm not sure what kind of structure for this would be most helpful pedagogically.)