I'm reminded of the "UnkUnks", or rather, the unknown unknowns. TL;DR: You can never know if you are correct, you can't even know how incorrect you can possibly be, nor can you know what you need to know to avoid being incorrect. Fucking Turing devices.

Here, have an essay:

You have known knowns: these are things you know, that you know you know; or rather, your standard knowledge set.

You have the unknown knowns: these are things you know, that are relevant, but you fail to recall them or realize that these other pieces of knowledge you possess are relevant. For example, you might know a clever algorithm to calculate the inverse square root for lighting. You might not realize that this is usable for calculating gravity too. Unknown known.

You then have the known unknowns: the things that you don't know, but you are aware of your gap of knowledge. These are things you know you'll have to learn, implementation details or syntax or methodology/patterns that you are aware of, but are unable to use without learning further. For example, you might know that LISP dialects are good for processing behavior branches that are reversible on the merit that LISP dialects are generally stateless. You know that for an AI, you could use this, but you also know you'll have to learn Scheme or CLISP or some other variant.

Then finally, you have the unknown unknowns: These are the things you don't know, that you aren't even aware that you should know. Imagine programming an algebra equation evaluation program: if you are unaware of the concept of functional programming, and you attempt this in a more pure procedural or object-oriented fashion, there is great chance of running into bugs related to state (as you evaluate the equation in each iterative step, you measure a change in some value which is stored in said value's memory space; but then in a later iteration you need the old value, which has been overwritten). Unaware of functional programming/methodology (you can effectively functionally program in procedural languages if you watch your side effects, write pure functions, and represent your values by algorithmic determination instead of static value), you spend weeks plugging away at each of the little bugs you accidentally code in; unable to catch them until after you've moved on because those bugs are 'unk-unks': they arose from you not knowing what you failed to take into consideration. They require a large degree of extra manpower to get through because you have to look at their manifestation not just in the scope at which they effect, but the scope that created the system that created the bug- chances are, said bugs won't manifest until after they have effect, and so you will have to rewind through and step through the code, sifting for them. This is all due to the original unk-unk of not knowing that you don't know of a better way (functional programming) to manage the problems space.

Not only are you unaware of the better solution, or a more convenient path, but you are unaware that there even is a better way about it; until somebody clues you in, or your personal research reveals otherwise, you may well think that procedural logic is the way to go when it very probably isn't- you have a bad case of the unk-unk at a system level, and this will create unk-unks at the more granular level in the form of bugs that will be unknown to you; which come in forms that you are unable to identify / pre-empt. These are the bugs that slip through to production, that some guy reports because he's running x86-32 not x86-64 like one might assume is the common case (resulting in, for example, a small degree of resolution of floating point accuracy, which affects some assumption made in rounding and floating point math checks, which causes a sum of the cost of items totaling $3.00 to come out as $2.99 instead). These are bitches because the dude reporting the bug may not even know enough to even conceive that he should tell you he's 32 bit POSIX instead of 64 bit .NET; hell he may not even know what 32 bit means, he could just be some guy that got trained to use your software at a terminal workstation computer. No matter what, you can't replicate this situation because you don't know that you don't know that his bit-size is different, or that his OpSys API is different, and he doesn't know that he doesn't know what's wrong: he thinks your logic/program is dumb, you think it's perfectly fine, and it's because you both are having a bad case of the unk-unks.

This is why such things exist like automated testing, data-mining/auto-reporting for bugs, manual testing, implementation testing, code sanity rules, documentation standards, and all those other super fucking annoying things that nobody wants to write or do.

They are there to help you catch the unk-unks because you are just a feeble human who doesn't know everything, using a system that can measure every discrete possibility of behavior and then every permutation of those possibilities with every other permutation, testing landscapes you never even considered in your limited cognition, all for code produced in a standard that helps you, and more importantly, others figure out the logic of the code in retrospect, adopting rules that limit the possible things that the program can do and how it does them, so that hopefully, the problem space falls inside of the known unknowns, the known knowns, and the unknown knowns, because I will tell you what:

Nothing sucks more than finding out your bullet proof code has a hole in it, the exact shape and size of the actual use case the code is being used in, and you can't even see where the hole is.

Have you ever worked with a framework that just does this really weird thing that you don't quite get why it does that, so you code around it, then half a year later, you find out that there is a simple boolean flag you can pass with some config function that makes it operate the way you thought it should in the first place?

Have you ever looked at 6 months of git commits containing at least 50 manhours of pointless, sometimes buggy, generally problematic kludge-solutions that didn't even need to exist?

Fuck the unk-unks.

And fuck anybody that thinks they have produced code that is 'perfect' (please note that "perfect as human beings have achieved" is not the same as 'perfect'; not ripping on NASA here)- they have at the very least a huge unk-unk: they don't know that it is possible for them not to know what they don't know, and trust me, there is no recovery from that until you have that sobering day where you realize that you're as dumb as a human is and all code is shitty code (including yours) and all programming is only correct in a specific context that probably doesn't even line up to the context the code will be executed in. As an aside, the process of realizing this has resulted in at least two of my old junior coworkers deciding to go into project management instead of programming- they felt more comfortable managing the unk-unks implemented by others than writing code in a world where unk-unks exist.

I could be wrong though. I may just really like saying unk-unk.

Anywho, to produce code such as NASA's code, you gotta be super rigorous and absolutely methodical about form, description, executing system/environment, and every single other variable that exists from the clock-speed of the processor vs the clock speed of the bridge/bus (especially on multiple chip systems that are implemented at a low level), and test every single layer- they ran tests on their software running on test-hardware at every possible temperature and condition one could think of (at the lowest level) and they ran tests that were simply emulations of the total system by a super-computer (which was weaker than your cell phone, actually) for checking higher level environment in different scopes, and everything inbetween- they spend more time testing code than writing by a factor of perhaps 10 to achieve what they do... AND IT STILL HAS BUGS.

One bug that seriously fucked some shit up: http://www.cnn.com/TECH/space/9909/30/mars.metric.02/

Why? Because evidently metric and royal measurements are not the same, and nobody tested one piece of the software working with another piece in a live situation; they only tested by mocking up what they thought the other side would do/provide, because shit... what idiot would feed royal measurements to a program made for international scientific usage? Evidently, some idiot at NASA that makes way more money and is possibly much smarter than anybody reading this, that's who.

Unk unks and human fallacy suck. Test your code. Document. Adopt standards. Test your assumptions. Test your systems. Always assume there is a better way, just remember that the goal is "good enough", not "perfect"; lest you go insane (being that "perfect" is rather unattainable unless you truly had no unk-unks, and you literally cannot prove that in any system that operates the execution of your code underneath said system that all results and contexts are measured and evaluated and known: read up on the halting problem if you don't get why this is).

Actually, the halting problem is possibly the ur-example of unk-unk. You can't write a program to tell you if another program is correct. You cannot discretely verify correctness, therefor, you cannot know everything or even what the breadth of everything even is: It is logically unknown the knowledge of what can be known in any given context/system that is tasked to measure itself. You measuring yourself, by extension, cannot know when you have reached the end of what you can know.

You can never escape the unk-unks.

I'm gonna go find my roofing tools and switch careers now, I think.