2021-10-23
good reads from today
http://www.galaxykate.com/ https://v21.io/
you already know formal methods!
https://galois.com/blog/2021/10/you-already-know-formal-methods/
formal methods is just a matter of reasoning about programs!
don't crash
always check error codes
always fill a field with a value
being incredibly confident in these code invariants is incredibly difficult and incredibly valuable; building a complete picture of this in your mind and being able to both apply this to new code and broadcast to others is incredibly important
has strong endorsement of `software foundations` - check the tool out!
starting with invariants: start with a blank document and specify what you think a program should do. describe why you think it should have that behavior, documenting everything you have to assume about why your program works the way you think it does; it will have more assumptions and fewer strong invariants than you think it does.
often correctness will depend on inputs in ways the type system can't specify - this is hard and bad! you should encode things in your language.
good to take time to document everything beforehand
why i am not a maker
https://www.theatlantic.com/technology/archive/2015/01/why-i-am-not-a-maker/384767/
wonderful essay on the beauty of maintenance vs making. there's something romantic about preservation; ensuring stability is, in many cases, far more difficult than some sort of creation or innovation.
"what do i make?" -> "why should my identity be defined by what i make?" prescriptive technologies: the factory; descriptive: where the creator controls the process as it happens behind every creation is an entire, invisible infrastructure making is symptomatic of our reward systems: creation is coding: provides high salary, prestiege, stock options, with little regard for the quality of the product being developed. reminds me of conversations with gus about engineering time and qa - much longer time scales, much more work, much more care, and a better appreciation for the longetivityof the final product. code is making because we sell it! maintenance is teaching, communicating (not_ preserving) tradition, and ensuring everything works and moves smoothly. when everything "just works", it's been perfectly and wonderfully maintained.
https://en.wikipedia.org/wiki/Baumol%27s_cost_disease cost disease: rise in salaries of jobs producing little to no increase of labor productivity. it's insane!
teaching is about learning - not making students and lesson plans, but encouraging relationships with students that will occur time and time again.
i used to think 'maintainer' label on open source software was ugly - now i think it's probably the most noble goal of all.