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.

    I don't know if it's as basic as @schoen wanted
    but it might be close.

I remember Code Complete as being a guide for advanced developers on how to take their craft to the next level.

Does my memory deceive me?

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. :)

I have that book and was impressed by it. I'll take a look over it again and see how I think it does on this stuff.

> 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.

Polite spelling correction: "tacit", not "tactic".

Thank you, that was simply a muscle memory problem.

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."

https://en.wikipedia.org/wiki/Library_%28computing%29

> 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.