Knowing and Programming Languages

by
published on

This isn't about knowing this or that programming language. It's about applying this to programming.

There are 4 states of knowing:

  • Things we know we know
  • Things we know we don't know
  • Things we don't know we don't know
  • Things we know that just ain't so

In life, and in software, clearly understanding what bit of information lies in which category is extremely important.

Some examples:

  • Things we know we know (Constant Values)
  • Things we know we don't know (IO)
  • Things we don't know we don't know (Variable Values)
  • Things we know that just ain't so (Infrastructure/Networking, memory overwriting, ???)

We can solve number 3 with Immutability, we can solve number 2 with nomads, we haven't figured out number 4 yet.

Haskell and others strict functional languages can help a lot, but as software engineers we often forget that there's an entire dimension of our app that's out of our control.

Even systems built with distributed resiliance in mind fail sometimes.

DevOps get's us a step closer, if only because it encourages developers to think like operators... to consider the real, unhappy world where network partitions happen, and servers go offline.

Try to think which category your code falls into, and build checks and error handling into the known unknowns. If you ever solve the last issue, you'll be very rich.