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 pull 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.