No Clojure experience actually required for this deep dive into what software “simplicity” really means and the hazardous semantic mistakes we constantly make with terms like “simple,” “easy,” “complex,” “hard,” when discussing our software preferences.
How to win. How to lose.
Being precise with our language when describing software is key to maintaining a steady notion of the world we are working in. “Complicated” and “complex” may first appear isomorphic, but the distinction jessitron offers contours a necessary taxonomic boundary for types of big software systems; and thereby encourages us to conscript more correct approaches to understanding and constructing software systems.
Why is so much writing about code so unhelpful? Here’s one insightful investigation as to why.
Explorations of program interruptions – logging, exceptions – that Feathers terms “edges” and Haskell-inspired strategies for mitigation. Mainly, how do we discover and handle invalid input at the farthest boundaries in our application in order that we can feel free to parse and process and data confidently deeper down. In other words, pushing edges to the edge. Beware production code examples in Java and Ruby. You may stumble across other developers coming across Feathers’ work and being profoundly touched. Here’s a strong endorsement from Peter Podgorski, which was also the article that led me to Alexis King’s deep think Parse, don’t validate:
One of the most intellectually challenging talks I’ve seen so far, at least when it comes to programming (we’ll get to other areas soon). What Michael Feathers talks about here is the kind of thinking outside the box that really flips your programming up side down. Or maybe “the right side up”, depending on how you think about it…
This was my initial intro into finite state automata in UI, thus marking a non-trivial evolution in my thinking for getting a handle on complex UI state for web clients.
It’s like the Gang of Four but for React, and written with less an air of thought-leadery importance. I wrote React for almost two years without finding this site and I el great saudade for that time.
Developing this instinct really takes time. But this article from Kent is an erudite praxis to help you wrangle your test code to focus on the end user experience. It’s also effectively an advertisement for principles that drove the design of React Testing Library, and how it saves you from the kind of gun-footing allowed by Enzyme. A great companion piece to Avoid the Test User.
This is a good one for TypeScript developers who normally think about typing as a way of applying constraints. As King notes, TS influences this since the language intends for you to apply annotations alongside dynamically typed JS. But what if we thought about types another way: not as constraints, but as axiom schemas. King invites us to shift from a predictive to a constructive approach. Considering a similar post from Hillel Wayne, this post feels squarely located in the software scholarship domain that cheers the data modeling as a skill to be cultivated.
A companion piece for Michael Feathers’ Edge-Free Programing – (or is it the other way around) – that will introduce to the dangers of shotgun parsing and how to avoid them by shifting your mindset from validation to parse: an effort best pursued closest to the hard candy shell of your apps. Welcome to the world of Language-theoretic Security (LANGSEC)!