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 … Continue reading Code minutiae, October 23, 2017

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 … Continue reading You must be this tall to ride the 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 … Continue reading How methodical and quality might keep up with fast and loose

One step closer to a good pipeline operator for Ruby

I’ve previously yearned for something like Elm and Elixir’s |> operator in Ruby. Turns out, this clever bit of concision is in Ruby 2.5: object.yield_self {|x| block } → an_object # Yields self to the block and returns the result of the block. class Object def yield_self yield(self) end end I would prefer then or … Continue reading One step closer to a good pipeline operator for Ruby

Generalization and specialization: more of column A, a little less of column B

Now, I attempt to write in the style of a tweetstorm. But about code. For my website. Not for tweets. For a long time, we have been embracing specialization. It's taken for granted even more than capitalism. But maybe not as much as the sun rising in the morning From specialization comes modularization, inheritance, microservices, … Continue reading Generalization and specialization: more of column A, a little less of column B

Categorizing and understanding magical code

Sometimes, programmers like to disparage “magical code”. They say magical code is causing their bugs, magical code is offensive to use, magical code is harder to understand, we should try to write “less magical” code. “Wait, what’s magic?”, I hear you say. That’s what I’m here to talk about! (Warning: this post contains an above-average … Continue reading Categorizing and understanding magical code

On Code Review: Bias to small, digestible review requests. When possible, try to break down your large refactor into smaller, easier to reason about changes, which can be reviewed in sequence (or better still, orthogonally). When your review request gets bigger than about 400 lines of code, ask yourself if it can be compartmentalized. If everyone … Continue reading

Fewer changes are faster to deploy than fewer changes

Itamar Turner-Trauring, Incremental results: how to succeed at large software projects: Faster feedback... Less unnecessary features... Less cancellation risk... Less deployment risk... 👏 👏 👏 👏 👏  read the whole thing, Itamar's tale is well told. Consider: incremental approaches consist of taking a large scope and finding smaller, still-valuable scopes inside of it. Risk is 100% proportional to scope. … Continue reading Fewer changes are faster to deploy than fewer changes