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.