# 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
(<u>not</u> 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.