One really cool trick I’ve discovered over the years is gamifying the learning process. Instead of doing a linear pass through some learning material I approach it in a non-linear fashion and take various detours by asking dumb questions and taking them to their logical conclusion. The downside is that it’s somewhat more time intensive than a linear pass but the upside is it’s more fun and I seem to retain the information better.
If you look at a build process abstractly then it is basically a function that uses some files as inputs and creates some files as outputs. We can peek into this input/output process with
strace by invoking the build script with
strace and then asking it to log all file operations. After we recover the inputs and outputs we can retrofit a caching mechanism on top of the build process by hashing the inputs and using that as a key to save the outputs.
To make things more concrete I’m going to use a simple script as a stand-in for a build processContinue reading
Most people agree that code is a liability. The more code you have the worse things get because more code means more entropy and more problems from emergent and unanticipated behavior. So most people agree that the less code you have the better. In this sense TDD is doing the wrong thing because TDD is just more code. Formal methods on the other hand are not code and they de-risk the code portfolio by offloading parts that would be code into something that is not code and hence not a liability.
So really what I’m saying is that if you want to reduce risk associated with code then invest some time in learning formal methods and how to utilize formal methods instead of code to specify and validate systems.
Here’s a heretical claim: most programming is a zeroeth order approximation of rigorous thinking. That’s probably the thing I miss most from math, I miss higher order rigorous thinking.