There is some serious programming wisdom in this video! For that reason, it is worth re-watching in the future. What follows is a highly abridged list of some of the relevant takeaways from various time points in the video:<p>06:54 Don't try to make one language look like another<p>07:34 Don't reinvent bool<p>10:36 Code flows from left to right, top to bottom<p>13:31 Reduce conditionals<p>14:59 Avoid negation<p>19:31 Simplify compound if conditionals<p>21:39 Reduce the number of casts<p>22:57 Use self-documenting language features<p>25:56 Pass an abstract sink for a function's output<p>27:58 Pass files as buffers rather than filenames to be read<p>30:34 The caller, not the callee, should call the environment<p>31:45 Callee writes to buffer, caller writes to file<p>32:30 Use function pointers (or templates)<p>34:10 Functions should be in one of two categories, not both<p>35:48 Line things up<p>36:43 Use ref instead of *<p>Of these, I think I find:<p><i>"25:56 Pass an abstract sink for a function's output"</i> -- the most potentially interesting...<p>Why? Because it can almost be thought of as borderline functional programming -- within an Imperative and/or Object-Oriented programming language... at least as far as the function using this method goes... it also has a wide variety of applications, i.e., instead of having a function do memory allocation (requiring that memory to be freed somewhere else in the program), why not pass such a function an additional memory allocator function pointer or object -- where the allocation (and subsequent deallocation) of memory -- is managed in some other well-defined place in the code...<p>Anyway, it's a great video! Well worth watching!