Me arriving on a Monday morning at the University of Washington for #PyCascades sprints just after the end of a class.
Some of them even gave me a deferential nod; presumably because they suspected I’m their new professor or something. Almost fell to dust.
Things I’ve been thinking about a lot lately:
- code design pressure (good: testability, bad: coupling business code with validation and/or storage – interestingly there’s been a #PyCascades talk about just that, framed using an obscure German mathematician)
- type state pattern, or: why I don't use state machines. This has nothing to do with static types but a continuation of “make illegal state unrepresentable”. Practically, this means that you’ll rarely see an `| None` in my class fields.
If you want _my_ serious take: I’m heading to #PyCascades rn and you better bring booze.
My output both in code & blog posts & videos would be A FRACTION of it, if it weren’t for @tidelift & the amazing folks on https://github.com/sponsors/hynek. Heck, I wouldn’t be on a plane to #PyCascades right now!
So, if you like my work, don’t listen to OSSF smartasses that money doesn’t solve anything. They paid me for a year and I’m confident they got their money’s worth. (2/8)
Those asking about the #PyCascades talk: I don't know whether they'll be posted, but the speaker has put a text version online: https://github.com/madrury/the-rising-sea
My key point is “model the problem in fine enough detail that the solution is self evident” vs “The Darkness”. It is the same problem when you allow the structure of your web API or the idiosyncracies of your data storage create pressure on the design of your business code.