This weekend I picked up some recent Batman comics from the Baltimore County Public Library in Towson, MD after reading this thoughtful review by Tim Carmody, and I was blown away by Tom King’s writing. Phenomenal!
Generative testing (property testing) with clojure.spec is kicking my ass. So exciting!
NYC geeks! I’m speaking next week at Clojure/NYC on “Specifying Other People’s Data Structures with Spec: an Experience Report” — would love to see you there. Tell me what I missed as I ramped up on clojure.spec!
RSVP here: www.meetup.com/Clojure-n…
I just installed the iOS 12 beta on my iPad and I’m glad to see that it unifies the quick-switching interactions of the iPad and iPhone X (maybe all iPhones, I don’t know). Using both devices with their inconsistent interactions on iOS 11 was consistently annoying.
Someone mentioned Groovy (the programming system) in my team’s chat channel today, and being the gray-neck-beard that I am, I waxed nostalgic:
I’m fond of Groovy, it was the little language that could … helped introduce me to some functional patterns, duck typing, more. Sort-of-maybe a predecessor to e.g. Kotlin in some ways… certainly helped prove the viability of alternate JVM languages, even if it’s since been eclipsed…
Interesting: Groovy had a bunch of early releases between 2004 and 2006, then 1.0 was released in January 2007. Clojure’s initial public release was October 2007. JetBrains started creating Kotlin in mid 2010 and announced it in mid 2011.
Not claiming any of these things are directly connected, but the broader timeline is still interesting.
In Oct 2016, Strachan [the creator of Groovy] stated “I still love groovy (jenkins pipelines are so groovy!), java, go, typescript and kotlin”. (Wikipedia)
Following up on my prior post, I just realized (while in a 1:1 with a friend) that this failure mode of mine really has two forms — and I stumble into both all too often.
Both forms involve omitting a crucial step when defining and pursuing a course of work/action.
The prior form omits the breaking of an ambitious, compelling vision into small, incremental, safe, achievable steps, and deploying them independently.
In the other form, I’ll propose or pursue a course of work comprising only small, incremental, safe, achievable steps, while omitting the crucial vision. This violates the adage “Make no little plans; they have no magic to stir men’s blood and probably will not themselves be realized.” (Daniel Burnham)
I wonder if the fundamental error in both cases is impatience.
Either way, I’m going to try hard to reduce the frequency of my failures in both forms of this mode.
Yet another painful reminder today that changes to complex systems — those made of code and those made of people — must be broken down into the smallest, most incremental steps possible, and deployed independently, or much pain will ensue.
I’ve been doing this work — designing, building, documenting, operating, and maintaining systems made out of code and/or people — for over 20 years now, and I have yet to learn this lesson deeply enough to have it be ingrained and automatic. I don’t know if I ever will. It’s clearly hard for me to resist the power and drama of big changes. I’m not going to give up though — not yet.
Update: I posted a follow-up about an hour later: Another form of the same failure mode