On decision tables and conditionals

Over the years, I’ve heard a few times about something like Decision Tables (Hillel Wayne):

A decision table is a means of concisely representing branching and conditional computations. In the most basic form, you have some columns that represent the “inputs” as booleans and some columns that represent outputs and effects.

It was usually some variation of teams using something like a truth table to define the logic of their application without using a mess of conditionals. It also turned out that there was a compiler optimization where these tables could be laid out such that figuring out which behavior was appropriate to all the inputs was faster than conditionals would have been.

Wayne doesn’t mention anything like this. But, there is mention of using decision tables with an RSpec macro to verify code behavior with less boilerplate assertion logic. So that’s neat!

If I had to sum up my style of coding, I’d say probably a third of it is about reducing the time I spend reading or writing conditional code. That’s where most of the bugs and frustration are. Pushing them down into the compiler, runtime, or database is a fun exercise too.

My favorite question is “why?”

At some point in elementary or junior high school, we were taught all our essays should answer one of five questions: who, what, where, why, or how. These were, at the time, “the five W’s” of writing.

Why is my favorite because it provides context. Asking why usually gets me to the bottom of the situation. It often encapsulates the who/what/where/how/when. It’s the most open ended, which is probably the best part. Asking why almost always makes the next most important question obvious.

I still like the other ones too. When often yields interesting histories or chronologies. Who can lead to a nice bit of biographical or character background. How is great when I care most about progress over deep context. Where can give me a little bit of backstory about why a certain location or geography is important.

Asking why wraps up all of those. Why are shipping containers a standard size? Who decided it should be that way. How did that drastically change global shipping? When did this occur and what changes can we observe from it?

One word, one question. So much to learn!

The systemic sublime makes our world more legible

My new favorite category on Kottke.org is the systemic sublime, wherein our networked, often inscrutable world is made more legible. The connections between ideas and and their instantiations are not always obvious. The history, and often the path dependence, of how we got here make it a little easier to understand our world.

Other fine purveyors of system sublime include Alexis MadrigalMatt WebbTom ArmitageRibbonfarmSteven Johnson, and Michael Lewis. My favorite thing about these authors is, they are answering “why?” by connecting the dots between “how”, “who”, and “what”. It’s my favorite kind of thinking!

Advocacy = empathy + speaking to someone else’s conceptual framework. When I’m trying to convey an idea from my head to someone else’s head, the biggest challenge is converting from my conceptual framework and values to theirs. Hence, The words that work:

For example, one partner in a conversation might use concepts like power and tradition and authority to make a case, while the other might rely on science, statistics or fairness. One person might argue with tons of emotional insight, while someone else might bring up studies and peer reviews.

Rare is the success of advocacy that doesn’t involve a lot of empathy, understanding your conversation partner, and letting go of the little details to reach a new local maximum of mutual understanding.

It’s dangerous to go alone, take dotfiles

Yesterday I was handed a fresh, nifty new laptop. This is, for me, mildly terrifying. Last time I did a clean operating system install was seven years ago. I’ve carried an idiomatic mixtape of dotfiles, macOS preferences, files, and cruft with me on my personal laptop ever since.

A brand-new, stock laptop is a shock to my highly acclimated and particular system.

I started contemplating how exactly I could get setup relatively quickly. At the same time, I want to pay down a little bit of automation debt. By the next time I’m faced with this situation (when I buy my own computer, if a disk is struck by lightning, etc.) I shouldn’t feel so much like a deer in headlights.

At first I thought I’d attempt to transmogrify my current lightsaber into something like Gina Tripani’s dotfiles. I like how this is structured, and that the initial setup of apps and Unix-y things is bootstrapped by Homebrew. But, then I remembered Thoughtbot’s laptop and dotfiles and convinced myself this was the way to go.

Indeed, laptop helped me cut the Gordian knot of setting up my new machine so I can write code and feel at home on it. I highly recommend it if you have the means.

New dotfile repo forthcoming!

I’m starting a new job tomorrow. I decided to take a week off in-between jobs, mostly to make a quick trip to Disney Land.

I hid most social media apps away, stopped paying attention to news, and caught up on reading. I gave myself a 3-day weekend before our trip to decompress, we went to Disney Land for 3 days, and had a 3-day weekend to relax before I start the next thing. I’ve done a fair bit of writing, watching movies, tinkering with Ableton, and playing games too. A great vacation sandwiched between two stay-cations, in the lexicon of our times.

My mind feels like it’s had a chance to reset and get back to a neutral state. I’m hoping this will help me keep my frame-of-mind looking forward as I start the next job. This was a great decision and I highly recommend you do something like this (granted, Disney Land isn’t everyone’s thing) yourself, if you have the means.

Scribbling through TensorFlow.js

I’ve been trying to wrap my head around machine learning lately. Today I worked through the TensorFlow.js tutorial on recognizing handwritten numbers with a neural network. Herein, my notes and scribbles.

Hand-written notes on machine learning
TensorFlow: it’s about turning linear algebra into models built of layers built of math

My previous forays into machine learning left me a little frustrated: I could tell there was language, pattern, and notations to this, but I couldn’t see them from the novelty of new-to-me words like sigmoids, convolution, and hidden layers. Turns out those are part of the language.

But the really handy idioms are encoded in TensorFlow’s high-level model-and-layer API. A model encapsulates a chunk of machine learning that can be trained to classify inputs (images, texts, etc.) based on a mess of training data (pre-classified stuff). Every model is built from a network of layers; layers use linear algebra to transform numbers into classifications.

Once you’ve built a model, you feed it a bunch of training data so that it can learn the coefficients and other number-stuff that goes inside the math-y network. You also provide it with an optimizer and loss function so that as the model is trained, it can know whether its getting better or worse at classifying data.

A really cool thing is you run this training process on your computer’s GPU. GPUs, like machine learning models, are big networks of fast math-y stuff. Beautiful symmetry! On the other hand, you usually can’t fit your training data set into GPU memory, so you end up batching your test data and submitting it to the GPU in loops.

Once all this runs, you’ve got a trained model that can take image inputs (in this case, hand-written digits) and classify them to decimal numbers (0-9). Magic!

Code minutiae, October 23, 2017

For some reason, identifier schemes that are global unique, coordination-free, somewhat humanely-representable, and efficiently indexed by databases are a thing I really like. Universally Unique Lexicographically Sortable Identifier (ulid, for humans) is one of those things. Implementations available for dozens of languages! They look like this: 01ARZ3NDEKTSV4RRFFQ69G5FAV.

Paul Ford’s website is twenty years old. For maybe half that time I’ve been extremely jealous of how well he writes about technology without being dry and technical. When I grow up, I’ll write like that!

How Awesome Engineers Ask For Help. So much good stuff there, I can’t quote it. There’s something in there for new and experienced engineers alike. In particular: don’t give up, actively participate in the process of getting unstuck, take and share notes, give thanks afterwards.

The best time to work on your dotfiles is on weekends between high-intensity project pushes at work. No better time to do some lateral thinking and improving of your workflow. Feels good, man.

You must be this tall to ride the services

If I were trying to convince myself to extract a (micro)service, today, I’d do it like this. First I’d have a conversation with myself:

  • you are making tactical changes slightly easier at the expense of making strategic changes quite hard; is that really the trade-off you’re after?
  • you must have the operational acumen to provision and deploy new services in less than a week
  • you must have the operational acumen to instrument, monitor, and debug how your applications interact with each other over unreliable datacenter networks
  • you must have the design and refactoring acumen to patiently encapsulate the service you want to build inside your current application until you get the boundaries just right and only then does it make sense to start thinking about pulling a service out

I would reflect upon how most of the required acumen is operational and wonder if I’m trying to solve a design problem with operational complexity. If I still thought that operational complexity was worthwhile, I’d then reflect upon how close the code in question was to the necessary design. If it wasn’t, I would again kick the can down the road; if I can’t refactor the code when it’s objects and methods, there’s little hope I can refactor it once its spread across two codebases and interacting via network calls as API endpoints, clients, data formats, etc.

If, upon all that reflection, I was sure in my heart that I was ready to extract a service, it’d go something like this:

  • try to encapsulate the service in question inside the current app
  • spike out an internal API just for that service; this API will become the client contract
  • wrap an HTTP API around the encapsulation
  • make sure I have an ops buddy who can help me at every provisioning and deployment step, especially if this sort of thing is new and a monolith is the status quo
  • test the monolith calling itself with the new API
  • trial deploy the service and make some cross-cutting changes (client and server) to make sure I know the change process
  • start transferring traffic from the monolith to the service

In short, I still don’t think service extraction is as awesome as it sounds on paper. But, if you can get to the point of making a Modular Monolith, and if you can level up your operations to deal with the demands of multiple services, you might successfully pull off (micro)services.

How methodical and quality might keep up with fast and loose

I’ve previously thought that a developer moving fast and coding loose will always outpace a developer moving methodically and intentionally. Cynically stated, someone making a mess will always make more mess than someone else can clean up or produce offsetting code of The Quality.

I’ve recently had luck changing my mindset to “make The Quality by making the quantity”. That is, I’m trying to make more stuff that express some aspect of The Quality I’m going for. Notably, I’m not worrying too much if I have An Eternal Quality or A Complete Expression of the Quality. I’m a lot less perfectionist and doing more experiments with my own style to match the code around me.

I now suspect that given the first two developers, its possible to make noticeably more Quality by putting little bits of thoughtfulness throughout the code. Unless the person moving fast and loose is actively undermining the quality of the system, they will notice the Quality practices or idioms and adopt them. Code review is the first line of defense to pump the brakes and inform someone moving a little too fast/loose that there’s a Quality way to do what they’re after without slowing down too much.

Sometimes, I’m an optimist.