![\"Jorge](\"https://internetross.space/uploads/2023/3f903ee582.png\")
\n ![\"comic](\"https://internetross.space/uploads/2023/batman-year-one-im-fine.png\" "\\"batman-year-one-im-fine.png\\"")
\n![\"keyboard](\"https://internetross.space/uploads/2023/programming-pearls.png\" "\\"programming-pearls.png\\"")
\nIn 2015 I bought this book. \n7, or 8 years ago. \nYear one into my software career. \nThis book is canon. \nI've had little use for its studies of algorithms. # thus far, see below \nI don't think Bentley would be offended. \nFirst sentence: "Computer programming has many faces." \nI’m sure I glanced at its pages before entering the corporate interview gauntlet to get in the vigilante mood. To shake out the shoulders, find some relaxment, whilst staring down a twenty two minute treadmill run or pile of laundry Sunday evening. You must to armor up for the algos in the kingdom of men.
\nWhile Bentley’s pearls are the type of polished wisdom earned through real life experience we get on the job, this book never became the vade mecum for my quotidian affairs. Is it for others? What comes after Part I was too metallic for an early-career front-end Rails dev.
\nYet, the book can be pragmatic for all ages – see 3.2 Form-Letter Programming!. The fantastic headings are pedagogically caring. It is sensually satiated with geeked thoroughness. The cases are actually well-situated within the real-world: Bentley spoils you with further readings and sidebars, journalistic first-hand-accounts that remind you of how the metal has been worked over by a person’s hands.
\nIt reminds you that software is not lonely, which is important.
\nBut beware: there’s a modest amount of myth-making for his contemporaries and mentors. And yet, they are the most honest plagiarisms. Yes/and: he’s humbler than many. (Perhaps it is worth another pass now that I have more years in the rear view).
\nI am a visual learner and thinker: logical word-problems were always a pain. In recent years I tend to reach for Bhargava’s Grokking Algorithms for a refresher on binary search or walking trees. It has cute pictures. It’s stacked next to other faves like Land of Lisp and Why’s (Poignant) Guide to Ruby.
\nHmmm (thinking emoji, I will not look you in the eye as I cock my head buried in thoughts). After all, the solstice konmari of my bookshelf – which I thought would elicit a reflection on some forgotten paper taking up space – has become the discovery of lost treasure. And yet, I’m still tickled by the scant amount of notes taken. I can’t read without a pen. Perhaps we’re time-traveling, then.
\nIt's year one. \nYoung Rails dev. \nHe makes only two liner notes in a book considered staple grocery. \nI don't remember if I even read the whole thing. \nI bet I got through Part 1's wider lens, then started to gloss over.\nOne note is an exaggerated check mark next to this principle listed on p29 (Second Edition, published 2000):
\n> Rework repeated code into arrays. A long stretch of similar code is often best expressed by the simplest of data structures, the array.
\nWith “the array” also underlined from the outer left edge of the “t” to the outer right edge of the last “a.”
\nThis one has stuck. Arrays, especially maps, can be more durable when staring down change. Before long any thoughtful software developer will realize that the components of a software system will become ordered and/or multiple.
\nThere is no lonely software.
\nData, whether as scalar, “bags” of properties, even subroutines and processes, even the manual lever pulling human tasks must be sequenced, serial, bound, reversed, indexed, sorted. The maintenance cost of housing data in ordered collections is generally low.
\n[<anything>, <anything>] \nWhole ass languages, like Clojure, were designed to favor ordered, associative arrays. As I learned after finding Hickey’s seminal talk Simple Made Easy. Richly simple and luxurious as Hockney’s bathers.
\n![\"hockney's](\"https://internetross.space/uploads/2023/hockney-sunbather.jpg\" "\\"hockney-sunbather.jpg\\"")
\nA second mark: a vertical line next to the opener for section 12.2 One Solution. This was (yet another moment in my lifetime) I learned that we never have to go it alone when staring down the void of what we’re building next:
\n> As soon as we settled on the problem to be solved, I ran to my nearest copy of Knuth’s Seminumerical Algorithms (having copies of Knuth’s three volumes both at home and at work has been well worth the investment).
\nThis has also stuck, reified after seasons.
\n", "date_published": "2023-12-22T19:53:23-07:00", "url": "https://softlydeveloping.micro.blog/2023/12/22/my-sparse-margin-note-couplet.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2023/11/20/but-night-software-is-not.html", "content_html": "> But night software is not like that. It’s not written for the day job. It’s not written to see the light of day at all. It’s not written to be looked at and scrutinized by anybody. It’s intimate and personal, it’s messy and buggy. To take a look is to transgress.
\nBoundary cross. Sex.
\nFrom a small heap software that helps make software. By way of Devine Lu Linvega
\n", "date_published": "2023-11-20T22:18:04-07:00", "url": "https://softlydeveloping.micro.blog/2023/11/20/but-night-software-is-not.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2023/11/20/dei-grieving-and-ai-skepticism.html", "title": "DEI Grieving and AI Skepticism", "content_html": "IYKYK DEI in tech is all but dead. If you’re an outsider, it’s important to understand that employee-led efforts to make workplaces less racist – which began in earnest at the onset of the Obama years – have been steadily blotted out since Trump. The Tech aristocracy has decided to abandon DEI budgets along with other workplace perks. As @betsythemuffin notes (in the thread I’ll be referencing below):
\n> DEI is seen by a sizable chunk of the funder class as an allowable luxury to keep the peons happy.
\nIt has been tragically hard to swallow this defeat. @betsythemuffin again:
\n>Regret that we didn’t do more to build material power when we had the chance.
\nAnd yet, as the movement has regrouped and recentered to reposition the struggle, some have begun to take note of a problematic adaptation in the techy left’s rhetoric. @danilo started a thread on Mastodon that points out a new-born form of absolutist skepticism for emerging technologies – notably AI (of course). Regardless of why the left slips into what @glyph calls a problem of “semasiology” around the term “AI”, point is, the hurt seems to be cutting so deep that the movement has retreated into an unproductive preservationism.
\n> The abject and understandably heartbreaking defeat of DEI-type progress in tech has moved most leftist critique of the space into a technological conservatism built on denialist, magical thinking.
\n> You can’t successfully advocate for a dead end when the other side is investing in roads that lead to helpful places.
\n> You can’t win against technologies people find useful by pretending they aren’t useful.
\nCheck out the rest of the conversation. There are smart people in here thinking through this “AI” moment. The underlying question seems to be how we can continue the fight without completely disavowing what might be practical revolutions borne out by this albeit early phase of “AI” that is “finally bearing serious fruit.”
\nIf you’re wondering on what side of the line I fall, my major beef with the LLMs is their wanton extractive consumption of human labor without citation or, god forbid, recompense. Of course, a time honored tradition of slave traders and capitalists. Here is Marc Andreesen with a recent plea written to the US copyright office, hopeful we can just all ignore this blatant theft for the common good of the funder class. This is class warfare:
\n> Imposing the cost of actual or potential copyright liability on the creators of AI models will either kill or significantly hamper their development.
\nI hold that citation is feminist since it combats the authoritative mansplain that obscures collaboration, hardens selfhood, and hoards ideas. Ergo I consider the de-linkified, referent vacuum of effluvium produced by ChatGPT et al as patriarchal in its presentation of “knowledge” and preoccupation with mastery. I’m scare quoting because philosophically I’m confused about what this content even is, so unhinged. Although I recognize that the interplay of this text with the reader and their investigative context does produce meaning.
\nUPDATE (minutes after the writing the above): heh, Danilo actually expounds generously about the left’s false critique of AI in a long-form piece on his blog.
\n", "date_published": "2023-11-20T21:32:12-07:00", "url": "https://softlydeveloping.micro.blog/2023/11/20/dei-grieving-and-ai-skepticism.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2023/11/10/lament-for-tafteria-sailing-the.html", "title": "Lament for Tafteria: sailing the Apollo's docs", "content_html": "![\"The](\"https://internetross.space/uploads/2023/the-hospital-ship-martin-bax.png\" "\\"the-hospital-ship-martin-bax.png\\"")
\nDocumentation, naming things. Hard. Let’s see this hardness compound at the intersection of these two phenomena in the real world.
\nI’m casually scanning the Apollo docs, reading up on subscriptions because my wife is writing graphql client code at work. (I had vague memories of how we worked with distributed event streaming at my last job. NestJS + Kafka. We had consolidated apis into a graphql layer, but worked with Kafka event streams through Nest with the kafka-js lib as a bridge. Point is, I wanted a light refreshment of how this stuff works.).
It’s a frustrating moment to jump between these two pieces of the documentation. (This is supposed to be a mature framework (sobbing, why can’t we have nice things)). From 2. Initialize a GraphQLWsLink to Enabling subscriptions.
\nThe former section, which walks us through client setup, provides a callout with a detour into the server docs for grabbing the connection url we need for configuring and instantiating our web socket linkage.
\n> Replace the value of the url option with your GraphQL server’s subscription-specific WebSocket endpoint. If you’re using Apollo Server, see Setting a subscription endpoint.
\nIf we are using Apollo’s server, then we must pass a url property when creating and instantiating the GraphQLWsLink object .
const wsLink = new GraphQLWsLink(createClient({\n url: 'ws://localhost:4000/subscriptions',\n}));\nHOWEVER, once we hyperlink to the server docs one simply cannot find – throughout the entire web document – a mention of “endpoint.” We’re dropped into a section called “Enabliing subscriptions” – instruction for setting up the server side bits.
\nLet down. Expectations missed. Problematic asymmetry, lack of consistency!
\nRepletely kerfuffled, my synapses delivering a reminiscence of Tom Benner’s big bird bound Naming Things, and his chapter on Consistency. (This so happens to be one of my favorite dogmas of Better Naming™️.) Well, the Apollo docs demonstrate a similar symptom of bad naming, just like the kinds of bad examples we oft find in code. Join me in considering disparate, hyperlinked documents as analogs to components of a software program that exchange messages. Readers of these texts suffer the bad naming with familiar symptoms: frustration. Capitalists lose the most with anemic productivity.
\nIf the hyperlink is a documentation document-as-component api/interface, us readers should be allowed to charismatically move back and forth without being flung out from our flow state like starships intercepted in warp. Perhaps the doc could send me to a subsection of “Enabling Subscriptions” titled/anchored with “Server endpoint” (or the like). My instinct is that there’s a deeper scoop here.
\nOf course, there’s an imperfect system to blame. When Trevor Scheer removed all mention of “endpoint” in the docs update preparing users for Apollo Server version 3 back in 2021 – Apollo Server would no longer include inherent support for websocket protocols – how closely did he collaborate with Stephen Barlow who initially committed the instructions referencing endpoints a year or so before. Do the people matter? (They do.) And from under whatever constraints they perform these literary efforts. We can wonder, imagine, daydream about the socio-technical system that produces docs for clients and servers, and how the basic capabilities of the web link them together. The bounded contexts. The challenges of producing universal languages, ubiquitous terms across what likely are two disparate teams.
\nThere are some leaky abstractions, but it’s not a total system failure.
\nI’m reading Bax.
\nDispatches, bulletins, papers, pinned up, spewed about The Hospital Ship.
\nPage 15: A chronic shortage of pins to fix up the reports, so that in consequence they blrew away and anyone in the stern of the ship could reach out a hand and collect bulletins from the air as they drifted by in an endless paper-chase over the stern of the boat and on into the sea.\n
\nPage 98: Did the programmers hope to attract some reply? The Hopeful did not know what replay to make so they transmitted their call signal only, but there was no response.
Euan wants to blame Tafteria, too bad.
\n", "date_published": "2023-11-10T13:26:04-07:00", "url": "https://softlydeveloping.micro.blog/2023/11/10/lament-for-tafteria-sailing-the.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2023/10/31/clojure-was-small-typescript-is.html", "title": "Clojure was small, TypeScript is big (thinking w/ Dan Vanderkam)", "content_html": "![\"Midnight](\"https://internetross.space/uploads/2023/midnight-endless-summer.jpg\" "\\"midnight-endless-summer.jpg\\"")
\nThe dangers of premature optimization are well understood among software engineers who’ve been frustrated by the secondary effects of code that end up compounding maintenance cost. (Does this principle play out in other milieu?).
\nNonetheless, there are times when optimizations are demonstrably beneficial but are difficult to implement because of system-wide or social dynamics that can’t or won’t accept the optimizations. Here I’m thinking with Dan Vanderkam’s post from back in September: The Saga of the Closure Compiler, and Why TypeScript Won.
\nSkipping gingerly back through through recent web and computing history, Dan discusses the now obvious demise of Google’s Closure compiler, which at the time enjoyed merits of technical achievements in optimization. During it’s development in the early aughts, the hardware of the time demanded Closure’s designers focus on minification. Dan argues that contemporary typed projects, like Typescript, won’t succeed beyond the range of Closure’s niche usage on advancements in performance. Typescript must be built with consideration ever-increasingly diversifying ecosystem of tool chains and environments within which it can and will be run. Such as right alongside plain ole dynamically-typed JS in mixed types/non-typed codebases. Despite the heroic campaigns of developers to slap types on everything – see the DefinitelyTyped repo – the JavaScript multi-verse offers no real guarantees that imports will be typed or not. TypeScripts declared horizon of
> Be a cross-platform development tool
\nmust be joined by
\n> Emit clean, idiomatic, recognizable JavaScript code
\nand further qualified by the non-goal of
\n> Aggressively optimize the runtime performance of programs. Instead, emit idiomatic JavaScript code that plays well with the performance characteristics of runtime platforms.
\nI wonder how many TypeScript developers have looked at the TypeScript Design Goals? Not to call out/in, just curious.
\nI wonder, the Midnight’s 2016 Endless Summer. Saxophone crying out from the other room.
\n", "date_published": "2023-10-31T11:42:32-07:00", "url": "https://softlydeveloping.micro.blog/2023/10/31/clojure-was-small-typescript-is.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2023/10/30/language-ergonomic-studies-possession-ruby.html", "title": "Language ergonomic studies: Possession: Ruby, JavaScript, D/s, Mycology", "content_html": "![](\"https://internetross.space/uploads/2023/flair-anniston.png\")
\nThere exist happy little clouds of coincidence when studying new languages. And not just across the computer ones, mind you!
\nRuby and Indonesian share a frugal brevity and disinterest in flairs of punctuation when managing possession.
\nItu bukuku.\nvs
\nThat's my book.\nAnd…
\nme = Person.find(my_user_id)\nmy_books = me.books\nvs
\nconst me = await prisma.user.findUnique({ \n\twhere: { \n\t\tid: 99, \n\t}, \n\tinclude: { \n\t\tbooks: true \n\t} \n});\nmyBooks = me.books;\nWell, Rails AR query syntax vs Prisma (NodeJS). (Also, did I do a useful interpretation of linguistic possession in a soft coding expression??)
\nThis isn’t YAOFJS (Yet Another Opprobrium for JS). I don’t have a quarrel with English, either. Although I find it often fairly dull when it’s not rescued by the reticulations of regional and immigrant (forced or free) anastomosis of the tongue and mouth (and whatever other maneuvers contribut to nudging the Queen’s own verbage (I’ve forgotten if there is anything before a body without organs, how is it done???)) that take root in everyday speech.
\nOnly a mere 30 pages (of 250) into Make the Golf Course a Public Sex Forest and you run headlong into Raechel Anne Jolie’s musings on D/s, mushrooms, and mouths. There’s probably something here to dwell on with respect to power, colonialism, oral sex, entangelment, Dulcinea Pitagora’s “subspace” in BDSM play (ohhh, wonderful that this term wasn’t entirely pre-figured by Roddenberry’s universe expanse), etc…
\nCue Butler’s Xenogenesis, ringing in my ears.
\n", "date_published": "2023-10-30T12:40:21-07:00", "url": "https://softlydeveloping.micro.blog/2023/10/30/language-ergonomic-studies-possession-ruby.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2023/10/25/rspec-vs-js-let-vs.html", "title": "Rspec vs js, let vs let", "content_html": "Have you noticed that comprehension arrives more quickly when reading comparison pieces that juxtapose the syntaxes, rules, and shibboleths of two programming languages. Steve Hicks' article What JavaScript Tests Could Learn From RSpec is one such example.
\nMy preference when writing tests is to keep re-assigning and re-using variables to a minimum. Localize them as close to the assertions as possible. Beware of cross-contamination. Pollination. Sexual interops.
\nRecreating a lazy-evaluated let-style block in JS, Hicks performs some clever scoping gymnastics which makes me nervous. The declarations of calculator, first, and second feel visually and temporally far-flung from usage.
describe("Calculator", () => {\n let calculator\n beforeEach(() => { calculator = new Calculator() })\n\n describe(".multiply", () => {\n let first, second\n function getResult() {\n return calculator.multiply(first, second)\n }\n\n describe("when the first value is negative", () => {\n beforeEach(() => { first = -1 })\n\n describe("when the second value is negative", () => {\n beforeEach(() => { second = -3 })\n\n it("returns a positive number", () => {\n expect(getResult()).toEqual(3)\n })\n })\n\n describe("when the second value is positive", () => {\n beforeEach(() => { second = 3 })\n\n it("returns a negative number", () => {\n expect(getResult()).toEqual(-3)\n })\n })\n })\n })\n})\nThis doesn’t really bother me though:
\nlet sharedVar;\n\nbefore(() => {\n sharedVar = ...\n})\n\ndescribe(() => {\n it(() => {\n sharedVar = ...\n })\n})\nIs rspec let better than JS let?
Even rspec maintainers caution us, Hicks notes. Convenience always carries a caveat in programming. This is a substantial pillar of the “readability” discussion: durability of convenience.
\n> Note: let can enhance readability when used sparingly (1,2, or maybe 3 declarations) in any given example group, but that can quickly degrade with overuse. YMMV.
\nCool find: givens. Shoutout to the translators, the transcribers, the interpreters.
\n", "date_published": "2023-10-25T11:57:43-07:00", "url": "https://softlydeveloping.micro.blog/2023/10/25/rspec-vs-js-let-vs.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2023/07/04/with-annemarie-willis-professor-of.html", "title": "With Anne-Marie Willis, professor of design theory at the German University in Cairo.", "content_html": "Another world is possible. But what of worlding? How to world?
\nWhen a Farley’s barista is a strong current; wow the level of shine escaping her mouth. And I loved it. The slightest tickle of maple syrup was a great recommendation!
\nPer usual I sent myself something to read and didn’t cite the source so I’ve been having that weird kind of drifty, but tethered, Pong ball experience. Was it mentioned by someone in a Paper in Systems discussion? Maybe a content of the fediverse’s systems thinkers briefly held in place by my thumb.
\nAs I like to say (with often different verses), I do software development because it’s a phenomenological wonder of people, text, code, time travel, non-determinism – and always pluckily avoids fitting neatly into capitalist fetish.
\nLike, software projects (already “bad” (incomplete, inaccurate) lexicon) of any substantial scope are only delivered on time accidentally.
\nFrederica Frabetti supports this axiomatic chiste of software, noting in her book Software Theory:
\n> “The central problem of software development is thus the impossibility of following a sure path in which a system is completely and exhaustively specified before it can be realized.”
\nand
\n> “Stability is something that happens to the system, rather than being scheduled and worked towards.”
\nLook how software was virtually helpless to build complex systems that are designed to become eventually consistent.
\nFor me, software is philosophical-ing. An ontological milieu. Therefore Willis' essay is soooo good for those of us who are philosophical-ing, but not academically trained – and who can drift into this kind of theoretical reasoning easily, especially in an essay like Ontological Designing which onboards us you into hardcore theory with a ton of grace. Willis doesn’t need to spend her initial breaths on defining “ontological” and and Heidegger’s “being”, and (re)introducing us to the failure of the Western metaphysical tradition. But she is generous; and that’s likely the point. A broader appeal.
\nWhich, in turn, helps the mind Pong around during an essay about pervasive push and pull.
\nI’m reading this essay about how we effect social change but also thinking through the systems reasoning and how it vibrates into software ontology. Well, there are references to IT infrastructure and other “equipment” of our present epoch – though they do not supersede other kinds of equipment. For Willis, our contemporary technologies can function both as examples of any designed material, as well as juxtapose with the immaterial (organizational structures, administrative systems, etc…) to demonstrate how they are equivalent as objects/outcomes of the ontological design circularity/looping, bi-directional reach – Heidegger’s grabbing Cartesian dualism by the shoulders and shaking them.\n(“Ontological designing refuses such one dimensional understandings of (human) being-in-the-world, which are worn-out fragments of enlightenment thinking and Christian morality sloppily stitched together.") As Willis notes, Heidegger themself reaches for the simple household jug to work with in his pursuit of how things, thing.
\n> “The jug gathers and unites these.”
\nThese being: water, wine, sky, earth. Gathered/outpoured.
\nBut she talks about tech in a way that tickles, for sure. Especially it’s excess as it frenetically infinite loops rather than unlocks potential:\n> Rather than inducing us into a world of multiple creative possibilities (as software advertisers would have it), [computers] design us as users into their horizons of possibility – which by the very nature of horizons (in Gadamer’s sense) always have a limit. In fact, the proliferation of options within even a basic operating system or software application becomes a tyranny of choice, a maze of seemingly endless possibilities, a dazzling instrumentation for its own sake, all means with no end in sight.”
\nMaybe free software never will be truly free.
\n![\"\"](\"https://internetross.space/uploads/2023/farley-mug.webp\")
\n",
"date_published": "2023-07-04T15:03:38-07:00",
"url": "https://softlydeveloping.micro.blog/2023/07/04/with-annemarie-willis-professor-of.html",
"tags": ["speculative nonfiction"]
},
{
"id": "http://softlydeveloping.micro.blog/2023/06/08/naur-goodies-years-after-jesus.html",
"title": "Naur, goodies, 1985 years after Jesus Christ",
"content_html": "There are so many goodies in Naur, 1985. Filter, some():
\nThank you ceejbot for further distillations.
\n", "date_published": "2023-06-08T09:29:54-07:00", "url": "https://softlydeveloping.micro.blog/2023/06/08/naur-goodies-years-after-jesus.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2023/06/08/naur-the-optimist-years-after.html", "title": "Naur, the optimist, 1985 years after Jesus Christ", "content_html": "The year is 1985. Certain kinds of optimism abound in programming circles. From Peter Naur’s Programming as Theory Building:
\n\"It may be noted that the need for revival of an entirely dead program probably will rarely arise, since it is hardly conceivable that the revival would be assigned to new programmers without at least some knowledge of the theory had by the original team.\"\n
The infamous “shit mouse” bug that I pushed to production in 2018 – which subsequently became an iconic team joke with its own concomitant laptop sticker swag – was the direct result of software abandoned in the wake of absconding team members. Picking up dust-laden software seems like a common occurrence these days, no?
\nIn their reading-with of Naur, Ceejbot offers a valuable remediation technique for deleterious knowledge vacancies. It’s one that I personally strive for in everyday software practice: gross amounts of maintainer documentation.
\n> Don’t waste time documenting what can be seen through simple reading. Document why that function exists and what purpose it serves in the software. When might I call it? Does it have side effects? Is there anything important about the inputs and outputs that I might not be able to deduce by reading the source of the function? All of those things are clues about the thinking of the original author of the function that can help their successor figure out what that author’s theory of the program was.
\nand
\n> …the program exists to solve a problem, some “affair of the world” that Naur refers to. What was that problem? Is there a concise statement of that problem anywhere? What approach did you take to solving that problem statement? What tradeoffs did you make and why? What values did you hold as you made those tradeoffs? Why did you organize the source code in that particular way? What belongs where?
\n", "date_published": "2023-06-08T08:56:20-07:00", "url": "https://softlydeveloping.micro.blog/2023/06/08/naur-the-optimist-years-after.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2023/06/06/power-moves.html", "title": "Power Moves", "content_html": "During her novel workshop on estate planning, Sarah Deluca of Move Money Shift Power poses the question:
\nIs holding onto control after your death something you want?
\nIf part of our life’s work is to strengthen connection, relinquish power, share power, redistribute, does a Trust actually violate the moves we’ve been making at the speed of small “t” trust? Individualistic posthumous scheming is not the invention of communities, but of corrupted powerfuls. It would seem.
\nA few days later I found myself in the next Paper in Systems discussion led by Dawn Ahukanna and Shauna Gordon-McKeon. On the table was Shauna’s essay Interpretive Labor: Bridging the Gap Between Map and Territory. Wherein you’ll find a rich investigation – and then interrogation – of the lopsided power distribution between those that labor to imagine, construct models, maps, and those that sit with the effects of the implementation – who interpret, navigate, bridge the chasm between theory and material outcomes.
\nI was called in. Software engineers do wield an outsized power from behind the desk. Although the tower isn’t deathly bleached, because 1) we do some interpretive labor at the seam between business requirements and software building (system design, theory of, code/text writing), and 2) failures reverberate back to us pretty hard (midnight pages) – at least more acutely than through the beauracratic layers. (Do the capitalists get to feel much of anything?) Nonetheless, we probably aren’t the ones screaming during the scream test. What do we do with this power?
\n\n No. You can’t. Not yet.
\nIt’s quite possible that my work in computers today is a last ditch to actualize a childhood fantasy of solving neighborhood crimes with my friends in Brooklyn with the help of a friendly ghost that communicates via word processor. You type, then we type, Ghostwriter.
\nThe way she caresses the monitor in this scene: longingly, tenderly, expectant. The arrogant gush of buzzwords. Unalloyed after school cool.
\n![\"\"](\"https://internetross.space/uploads/2023/3b291aa203.jpg\")
\n",
"date_published": "2023-04-29T09:44:02-07:00",
"url": "https://softlydeveloping.micro.blog/2023/04/29/can-you-jam-with-the.html",
"tags": ["speculative nonfiction"]
},
{
"id": "http://softlydeveloping.micro.blog/2022/01/08/redis-poem-set-things-set.html",
"content_html": "set things
\nset them to expire
\nset them to be exclusive
\nset them to expire, be exclusive
(inspired by a chat with mike b)
\n", "date_published": "2022-01-08T00:22:45-07:00", "url": "https://softlydeveloping.micro.blog/2022/01/08/redis-poem-set-things-set.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2021/01/24/wellknown-ways-that-javascript-coerces.html", "title": "Well-known ways that JavaScript coerces objects to strings", "content_html": "One typical practice of your everyday software developer building commercial computer programs is to add logs alongside code at important relay nexuses – where the code does valuable things. Logs are typically composed of data and a message that meaningfully describe a moment in the system’s operation during it’s lifetime. There are a handful of reasons to surface information this way: producing audit trails for legal compliance, gathering product insights, performance profiling, or collecting debug traces for quality monitoring. Generally logs are a benign additive to your running programs, although they are notoriously risky as vectors where private user data may be “leaked” – serialized unencrypted. Perhaps a lesser-known trickiness of composing and handling logs, one that I find compelling enough to write about here, is the unpredictability of what happens when you try to serialize more complex data structures when writing in a dynamically typed language like JavaScript. Because logs are namely messages that need to be formatted for transport across system boundaries, out from your system to other systems, the act of stuffing objects, arrays, maps, sets, etc… into a message string is fraught. Let’s consider this in some depth.
\nLogs capture a Good-Enough Facsimile™️ of the current state of the world for later analysis1. This likely means grabbing the subject of the current operation that might appear like context.currentUser as well as other supporting actors like the session context and properties of the objects being acted upon by the current user – then bundling these properties as an object. Sometimes the object being acted upon is the current user’s own data. Then we have a funky transmigration of Subject/Object.
Why don’t we clasp hands and skip through a hallucination together into a fantasy e-commerce example where we can explore logging and value coercion of a canonical Order class. Let’s start with the following modest invention which terraforms a theoretical backend piece of a prescription drug dispenser. And let’s imagine that, from time to time, orders that come into this shop become stuck during the fulfillment process. Insurance claims may be rejected, the doctor or pharmacist discovers a conflict between the patient’s health attributes and the meds. In such a scenario, this code attempts a fully-automated retry of the unstuck order, and in due course, at important nexuses, passes relevant contextual data to log handlers. From there other bots or real-life persons can take over.
\nconst oldestStuckOrder = await query(orders, { filter: 'oldest_stuck' });\nconst logData = {\n\torder: oldestStuckOrder,\n\tuserInfo: { ... },\n\tsessionInfo: { ... },\n};\nlogger.info(`Start resolving stuck order: ${logData}`);\nconst reason = determineStuckReason(oldestStuckOrder);\n\nif (reason) {\n\tconst result = resolveStuckOrder(oldestStuckOrder, reason);\n\tconst logDataWithResult = {\n\t\t...logData,\n\t\treason,\n\t\tresult,\n\t};\n\tlogger.info(`Finished resolving stuck order: ${logDataWithResult}`);\n} else {\n\tconst logDataWithReason = {\n\t\t...logData,\n\t\treason,\n\t}\n\tlogger.error(`Unable to resolve stuck order: ${logDataWithReason}`);\n}\nThere are three points in this code where I’m sending an aforementioned warned-about complex object into a logger service which only accepts a single string argument. In this scenario, the devs want the logger API as simple and straightforward as can be: unary and stringy. I hope this code reads naturally, that it’s similar to something you’ve seen before. And…hopefully your gears are turning already and you are starting to see with me 𓁿; and you are beginning to feel awkward 🙇🏻♂️ about what representation for oldestStuckOrder or logDataWithReason that this gussied-up console function will likely display. Won’t interpolating complex objects inside a template string implicitly coerce the object into the obstinately churlish [object Object]?
JavaScript is funky-beautiful because it is dynamically typed. It grants you the freedom to smush\nvalues of mismatched types into the same computational context and your program won’t\ncrash, resulting in stuckness on stuckness. JavaScript has loose assumptions loosely held.
\nWe often take this for granted when we write JavaScript. We also often exploit\nit for good. Conscious or not, you are probably already familiar with the types of common\ncomputational contexts where the language affords this failsafe. Here’s a general breakdown:
\nif statements, the second clause of a for loop handler, the first clause of a ternary operator)That last one is case in point. We can send an object into a string context – Finished resolving stuck order: ${logDataWithResult} – and get something workable out the other end:
const logDataWithResult = {\n\tprop: 'prop',\n\tanotherProp: 'anotherProp',\n};\nconsole.log(`Finished resolving stuck order: ${logDataWithResult}`);\n// => Finished resolving stuck order: [object Object]\nAnd there it is. Workable (quite generously). The famed proterozoic, bracketed\nnotation of familiar churlish conceit and “bad parts” motifs. Obviously this not\nthe best guess we hope the engine to make when executing our logging function –\nwe have lost all that rich order and user data! Our compliance trail is\nmeaningless. But we shouldn’t despair quite yet. I’m happy to share that\nJavaScript exposes many an API for developers to control the return value of\ndynamic type conversions. If JavaScript is anything, it’s a fairly “open” language.\nNot necessarily open for expansion to the extent of, say, Clojure’s macros. But\nall things being mutable objects (with a few untouchable properties) and a\nhandful of scalar values, you have a good deal of freedom. For coercing objects\nto string, the most famous method is probably toString(). In fact, JavaScript\ndogfoods its own toString() for object -> string conversion automatically in\nall those common contexts we listed above. Whenever
> the object is to be represented as a text value or when an object is referred to in a manner in which a string is expected\n> – MDN contributors
\nLike between backticks.
\nNow, if a fellow developer in our dream of a drug shop codebase has not already\ncome along and monkey-patched the Order object’s toString() method, the\ndefault conversion algorithm rules defined for Object.prototype.toString()\nfrom the ECMAScript® 2021 spec section 19.1.3.6 will kick in. The algorithm is\nactually pretty easy to understand; though here’s to hoping your browser of\nchoice actually follows these rules. I invite you for a glance:
![\"\"](\"https://internetross.space/uploads/2021/66e3d2ae1b.png\")
Can you see where [object Object] comes from? If the unfamiliar dialect is a bit intimidating for your casual Sunday morning read, here’s what the above algorithm would like if we implemented it in JavaScript4:
import { SecretInternals } from 'secret-internals';\n\nconst internalSlotsToTagMap = {\n ParameterMap: "Arguments",\n Call: "Function",\n ErrorData: "Error",\n BooleanData: "Boolean",\n NumberData: "Number",\n StringData: "String",\n DateValue: "Date",\n RegExpMatcher: "RegExp",\n}\n\nfunction toString(value) {\n if (value === undefined) return '[object Undefined]';\n if (value === null) return `[object Null]`;\n\n let builtinTag;\n const innerValue = innerValue = SecretInternals.Object.box(value);\n const isArray = isArray(innerValue);\n\n if (isArray) {\n builtinTag = 'Array';\n } else {\n for (const [key, value] of Object.entries(internalSlotsToTagMap)) {\n if (SecretInternals.Object.hasInternalSlot(innerValue, key)) {\n builtinTag = value;\n }\n }\n }\n\n if (!builtinTag) {\n builtinTag = 'Object';\n }\n\n const tag = SecretInternals.Object.get(innerValue, '@@toStringTag');\n\n if (tag !== string) {\n tag = builtinTag\n }\n\n return `[object ${tag}]`;\n}\nFor actual objects, not object-like things (Arrays), the algorithm falls through to step 14 where a temporary referent called builtInTag receives the value Object. This built in tag is later used as the second part of the converted argument value.
I had a JavaScript joke but it’s [object Object] — Greg Meyer (@grmeyer)\n
Despite the sarcastic jabs from the peanut gallery, what else would we expect\nthe language to do. JavaScript’s unintentional emissions were designed for a\nplatform that projects them through UIs for consumption by masses of retinas of\nhuman people – it’s Good Enough. The language keeps your program running with a\ntype guess and leaves the contents of your value alone. It doesn’t take drastic\nmeasures and radically\nunpack and/or serialize your contents to JSON (what compute or privacy costs might\nlurk!); or try to set the built in tag to the left-hand side of the\nlast variable assignment statement: what a drastic move, the language doesn’t\nwork this way: variable names are not synonymous with types! Variable assignment\nis void of any tautological binding! JavaScript just lets you take matters into\nyour own hands.
\nUntil very recently I wasn’t aware of any techniques beyond an Object’s built-in toString() property to futz around with type conversions. But apparently there are a few modern well-known Symbols5 that have entered the language to help. I’ve compiled an example with four different APIs I could track down. Any of these would play nicely for logging libraries, though the last only works in node, and there are nuances to each that you must consider for your use case.
// 1. Override toString() (js, node)\nclass Chicken {\n toString() {\n return '🐓';\n }\n}\n\nvar chicken = new Chicken();\nconsole.log(`${chicken}`); // 🐓\n\n// 2. Symbol.toStringTag (js, node)\nclass Chicken {\n get [Symbol.toStringTag]() {\n return '🐓';\n }\n}\n\nlet chicken = new Chicken();\nconsole.log(`${chicken}`); // [object 🐓]\n\n// 3. Symbol.toPrimitive (js, node)\nclass Chicken {\n [Symbol.toPrimitive](hint) {\n switch (hint) {\n case 'number':\n case 'string':\n case 'default':\n return '🐓';\n default:\n return null;\n }\n }\n}\n\nlet chicken = new Chicken();\nconsole.log(`${chicken}`); // 🐓\n\n// 4. util.inspect.custom (node)\nconst inspect = Symbol.for('nodejs.util.inspect.custom');\nconst util = require('util');\n\nclass Chicken {\n [inspect]() {\n return '🐓';\n }\n}\n\nconst chicken = new Chicken();\nconsole.log(chicken); // 🐓\nconsole.log(`${chicken}`); // [object Object]\nutil.inspect(chicken) // 🐓\nI haven’t formally surveyed this, but I can report anecdotally that of my current team of ~25 engineers who work on a universal JavaScript application, overriding toString() is the most commonly preferred strategy. My sneaking suspicion is that many JavaScript developers are not aware of the more contemporary Symbol methods/properties, even though these methods have been available in major browsers/node for ~4-5 years. Or maybe it’s simply a matter of many backend devs coming to backend JS from other languages and server environs. From what I understand, node has just started to finally emerge in the past few years as fit-enough for prod. JavaScript is vast territory, quickly expanding, in multiple runtimes – it takes years.
As for nodejs.util.inspect.custom, I haven’t been around node land long enough to know if its usage is idiomatic.
Still, preference for toString() may not simply be an issue of keeping up with the JS Joneses. As shown above, the outcomes of these different strategies are not identical. What’s more, to layer on the complexity, these options aren’t wholly independent. In fact, JavaScript combines these strategies together under the hood. Did you notice what was going on in step 15 of the conversion algorithm above? The spec requires that Object.prototype.toString looks up the @@toStringTag symbol property on the object – these symbol members are in the DNA sequence now. When we take control back, understanding the spec is quite key: we can avoid mistakes like combining these two options since overriding toString() always take precedence. For example:
class Chicken {\n get [Symbol.toStringTag]() {\n return 'Base 🐓';\n }\n\n toString() {\n return 'This is a 🐓';\n }\n}\n\nclass JungleChicken extends Chicken {\n get [Symbol.toStringTag]() {\n return 'Jungle 🐓';\n }\n}\n\nconst chicky = new Chicken();\nconst jungleChicky = new JungleChicken();\n\nconsole.log(`${chicky}`);\nconsole.log(`${jungleChicky}`);\n// => This is a 🐓\n// => This is a 🐓\nHowever, say I were interested in simply tagging the string representation of my object to protect exposing its value contents, and still present a semantically rich identifier to consumers. This would help us express a desire to maintain the default bracket output – [Object..] – with the prepended “object” type to maintain some consistency with how objects are stringified in our code. In that case, leveraging the well-known Symbol.toStringTag property would be the way to go. For example, the following logger from our e-commerce imaginary might obscure private user data like this:
// .../jsonapi/resources/user.js\nclass User {\n\tget [Symbol.toStringTag]() {\n\t\treturn `User ${this.id}`;\n\t}\n}\n\n// Somewhere else...\nlogger.error(`Unable to resolve stuck order: ${logDataWithReason}`);\n// Unable to resolve stuck order:\n// {\n// \torder: {...},\n//\t\tuserInfo: [object User:123456],\n//\t\tsessionInfo: {...},\n// };\nYour next option, empowering even more fined-grained control, is adding a Symbol.toPrimitive method to your object. Symbol.toPrimitive is a main line into the runtime’s coercion processing. After playing around a bit in a browser and a node repl, I’ve noticed that this Symbol will precede over a provided toString() override.
class Chicken {\n toString() {\n return 'This is a 🐓';\n }\n\n get [Symbol.toStringTag]() {\n return '🐓';\n }\n\n [Symbol.toPrimitive](hint) {\n switch (hint) {\n case 'number':\n case 'string':\n case 'default':\n return 'This is a 🐓 primitive';\n default:\n return null;\n }\n }\n}\n\nconst chicky = new Chicken();\nconsole.log(`${chicky}`)\n// => This is a 🐓 primitive\nBy using Symbol.toPrimitive, you’re basically instructing the runtime to LOOK HERE for all its object coercion preferences. What’s more, beyond Symbol.toStringTag’s mere label augmentation, you get a powerful indirection2 to handle all primitive type coercion scenarios1. You’re also overriding internal language behavior which – I was surprised to learn – effectively resolves how to order the calls for Object.prototype.toString() and Object.prototpye.valueOf(). Flip to section 7.1.1 of the spec to see how the ToPrimitive abstraction is designed to call a further nested OrdinaryToPrimitive abstraction for decision-making:
![\"\"](\"https://internetross.space/uploads/2021/0d11e430d2.png\")
Translated for comfort:
\nimport { SecretInternals } from 'secret-internals';\n\nfunction ordinaryToPrimitive(object, hint) {\n if (SecreteInternals.isObject(object)) {\n throw TypeError;\n }\n\n if (hint !== 'string' || hint !== 'number') {\n throw TypeError;\n }\n\n let methodNames = [];\n\n if (hint === 'string') {\n methodNames = ['toString', 'valueOf'];\n }\n\n if (hint === 'number') {\n methodNames = ['valueOf', 'toString'];\n }\n\n for (methodName of methodNames) {\n if (SecreteInternals.isCallable(methodName)) {\n const result = SecreteInternals.call(object, methodName);\n\n if (SecreteInternals.isNotObject(result)) {\n return result;\n }\n }\n }\n\n throw TypeError;\n}\nI think I like the idea of using these well-known symbols for custom object -> string representations, if for the collision protection alone.3 What would it be like to reach for the powerhouse of Symbol.toPrimitive to hijack the runtime from eventually calling through to Object.prototype.toString(). Furtive, conspiratorial whispers to the interpreter 🤫. Even a partially implemented reducer will do, as I demonstrate above in my chicken example above: the switch statement can gracefully sidestep other type hint cases and only target the string hint case. But is grabbing for Symbol.toPrimitive overkill? toString() is tried and true and a pristine greenfield function block without arrogant “hints” and a naive switch statement without pattern matching 🙄 (are we there yet?). Could there be non-trivial DX cost of confusing other developers if the other primitive case statements are fall throughs?
1: Whenever I think about how software tries to capture its own understanding of the world it creates, I’m brought back to systems thinkers like jessitron:
\n\"We don’t expect the world to have perfect consistency. Yet we wish it did, so we create facsimiles of certainty in our software.\n
It’s impossible to model the entire world. Completeness and consistency are in conflict, sadly. Still, if we limit “complete” to a business domain, and to the boundaries of our company, this is possible. Theoretically.\n\n
2: By “indirection” I really mean to invoke Zachary Tellman’s exegesis of semantic drifts in software industry lexicons from his book Elements of Clojure. His work is a really nice refinement:
\nIndirection provides separation between what and how. It exists wherever \"how does this work?\" is best answered, \"it depends.\" This separation is useful when the underlying implementation is complicated or subject to change. It gives us the freedom to change incidental details in our software while maintaining its essential qualities. It also defines the layers of our software; indirection invites the reader to stop and explore no further. It tells us when we're allowed to be incurious.He goes on to discuss that conditionals are one of two primary devices to achieve successful indirections (the other being references). Conditionals are effective because they contain ordered, \"closed\" decision-making mechanisms that avoid conflicts; in contrast to tables with indivduated keys.\n
Conditionals solve conflicts by making an explicit, fixed decision. Where conflicts are possible, we use conditionals because they are closed.\n\n
3: That’s the primary purpose of these Symbols. For a deeper Support util.inspect.custom as a public symbol #20821 on GitHub.
\n4: Try not to think too hard about the implications of a JS interpreter written in JS. But, ya know, Atwood’s law; you will, not surprisingly, find JS interpreters for JS out there, many built on Acorn, which, is itself, a parser written in JS. Man alive!
\n5: I’m bemused and betwixed by this use of “well-known.” Does anyone know the origin of this qualifier?
\n", "date_published": "2021-01-24T15:57:00-07:00", "url": "https://softlydeveloping.micro.blog/2021/01/24/wellknown-ways-that-javascript-coerces.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2020/11/08/language-ergonomic-studies-summing-ranges.html", "title": "Language ergonomic studies: Summing ranges and most frequent terms", "content_html": "Pennies per day (by day count) in Clojure:
\n(defn pennyPerDay [numDays]\n (reduce + (range 1 (+ numDays 1)))\n)\n\n(pennyPerDay 30)\nPennies per day (by day count) in JS:
\nfunction pennyPerDay(numDays) {\n return Array(++numDays)\n .fill(0)\n .reduce((sum, _, i) => sum + i, 0);\n}\n\npennyPerDay(30);\nMost frequent terms in JS:
\nconst termList = ['term1', 'term2', 'term3', 'term3'];\nfunction mostFrequentTerms(arr) {\n return arr.reduce((result, curr) => {\n result[curr] = ++result[curr] || 1\n return result;\n }, {})\n}\n \nmostFrequentTerms(termList);\nMost frequent terms in a list with Clojure:
\n(def term-list [:term1 :term2 :term3 :term3])\n(defn most-freq-terms \\[terms\\]\n (->> terms\n frequencies\n (sort-by val)\n reverse))\n(most-freq-terms term-list)\nNot a day goes by when I don’t witness the over signifying of “meeting”. “Meeting” invokes a collective sigh for laborers since a better way seems a fairy tale. As a consequence, possibilities for elevated communication are damaged. But a meeting is so much more:
\n> Calling the coordinated exchange of messages or moderated access to shared material (like a blackboard) a conference or meeting seems to neglect a factor that is rather important in meetings. Often the explicit exchange of messages is relatively unimportant compared with the development of social relations in the group of participants that happens simply by the fact that they are close to each other as humans for a while.\n>\n>
\nThus, we may be Zoom doomed. Perhaps. We need to hire facilitators and train our people in facilitation. It’s a technical skill that most technologists lack, profoundly.
\n", "date_published": "2020-09-30T01:00:00-07:00", "url": "https://softlydeveloping.micro.blog/2020/09/30/zoom-doomed.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2020/09/09/not-so-byzantine-algorithm-studies.html", "title": "Not so byzantine algorithm studies: Using math to deliver your medication", "content_html": "Like many commercial software developers, math plays a more sporadic role in my day-to-day work. That said, I certainly wouldn’t blithely demote knowing math below other techs like programming languages, web frameworks, and principles of software design/architecture; which already sets up a false dichotomy, anyway.
\nMath presents a beautiful core proposition to software developers. Through its powers of abstracting and reducing real-world dynamics into expressable, repeatable, sequential logic – which we can be lifted easily into our favorite coding grammars – math can be the companion dynamo we need for achieving levels of faithful verisimilitude for real world complexities (Keep It Savvy Stupid).
\nItalicizing knowing math is totally an intentional problematization to mess with the idea that knowing math is narrowly scoped to demonstrating technical prowess of calculation or proofing. I think software engineers can, and should, consider a relationship with math as knowing enough math; like, an ontological relationship with math’s formalism and general principles. Math The Good Parts, so to speak. Otherwise the bravado of equating math and problem solving or math as “hard” (dick) science of some kind is doomed to engender an axiomatic blur that will gate keep devs who are not deemed fit for lack of educational background or interest in fiddling with greek letters. Keep these gates wide open, por favor!
\n(I also think the focus on calculation in my early schooling, alienated from everyday material uses, made me quite Meursault for it – perhaps why I don’t feel the need to champion for being mathy. It took entering commercial software life much later in life to see how the dynamo helps us make stuff and therefore able to consider embracing math (and being embraced by math) again.)
\nOur praxis: we can coopt knowing math to ramify similar to our desire for Senior Engineers™ to be T-shaped with their knowledge of the stack in order that they can press more heavily on architecture and design. For example, we can desire for React developers to:
\nThis is all just to say that some business problems map really well to higher-order maths and devs should be prepared for it, at least through the design phase. Again, once we sit down to write code, we can easily offload the fastidious implementation details; those few lines of copy|paste from the math deep state.
\nFor example, take a common e-commerce retail problem like Distributed Order Management (DOM). Modern omnichannel selling combined with cloud computing open a broad field of possibilities to achieve low-cost order fulfillment. Affine cost structures – resulting from variable/variadic shipping dynamics – will increase complexity as an ecommerce company scales. We’re talking about quite a bit of real-world complexity to model and adapt to.
\nWhat, then, when we’re tasked to create an algorithm to satisfice a version of this problem where you have these rough requirements:
\nThis kind of thing will break your brain once you start to grasp for a rational boundary to contain the argument ramifications: supplier availability, supplier inventory availability, etc…
\nI was presented with a challenge like this recently and it took me a couple hours just to understand what this problem domain was; like, find my way to DOM through off-by-one google searches; a true StumbleUpon revival. Because I didn’t know the math well-enough yet. Google is pretty fast though, and within minutes I practically broke out in a sweat after discovering multiple long-winded computer science papers written on the topic filled with intimidating mathy notations. Then more OMGs and mon dieus as I careened sharply into Cantor’s theorem and Set Theory. Wait, am I doing math? Oh mersault!
\nMore and more it seemed a fantasy that I’d be capable of solving Amazon within a reasonable amount of time because this gestalt was increasing aggressively. Nonetheless, after some deep breaths and patience recoup and having worked with enough devs without math experience, I began to inculcate to this world and realize any solve was going to be an approximation of some sort and probably wouldn’t require me to crack open a text book; there was no silver bullet or excavation of secret proofs. Rather, this whole class of optimization maximations applied to fulfillment problems is a rigorous academic field, but when it meets the metal it softens and warms for Good Enough™️ programming. Each potential brute force linear assignment or dynamic programming algorithm was discarded. My inputs couldn’t be structured into a decision table or cost matrix amenable to path finding, traversal, or Cartesian production. Which meant I could rule out potentials like Kuhn’s Hungarian algorithm. In fact, the scope was something more akin to a set cover or networking problem – still a brave new world, but less and less unbounded the more I scoured the web. Ulimately, my task was gonna be something toward imagining all probabilities between order items and suppliers, and then reducing these matches against cost constraints. “All probabilities” was a strong clue.
\nSo, a bit surprisingly for someone not used to needing math everyday – and certainly not trying to fuck with this:
\n![\"Fully](\"https://internetross.space/uploads/2020/89e27c7784.png\" "\\"fully_splittable.png\\"")
\nI soon found myself drifting at a comfortable altitude through Probability and Combinatorics with the help of other cow path pavers – we are community-taught developers, after all! – crafting a studied, yet heuristic, approach from where I could thread my inputs through techs like combinations and permutations to make some educated guesses.
\nThe general step-rules of algorithm gradually accreted into something resembling following:
\npowerset([A, B, C]) === [[A], [B], [A, B], [C], [A, C], [B, C], [A, B, C]];powersetBySize(powerset([A, B, C]), 2) ===\n [\n [[\"A\"]],\n [[\"B\"]],\n [[\"A\"], [\"B\"]],\n [[\"A\", \"B\"]],\n [[\"A\"], [\"A\", \"B\"]],\n [[\"B\"], [\"A\", \"B\"]],\n [[\"C\"]],\n [[\"A\"], [\"C\"]],\n [[\"B\"], [\"C\"]],\n [[\"A\", \"B\"], [\"C\"]],\n [[\"A\", \"C\"]],\n [[\"A\"], [\"A\", \"C\"]],\n [[\"B\"], [\"A\", \"C\"]],\n [\n [\"A\", \"B\"],\n [\"A\", \"C\"],\n ],\n [[\"C\"], [\"A\", \"C\"]],\n [[\"B\", \"C\"]],\n [[\"A\"], [\"B\", \"C\"]],\n [[\"B\"], [\"B\", \"C\"]],\n [\n [\"A\", \"B\"],\n [\"B\", \"C\"],\n ],\n [[\"C\"], [\"B\", \"C\"]],\n [\n [\"A\", \"C\"],\n [\"B\", \"C\"],\n ],\n [[\"A\", \"B\", \"C\"]],\n [[\"A\"], [\"A\", \"B\", \"C\"]],\n [[\"B\"], [\"A\", \"B\", \"C\"]],\n [\n [\"A\", \"B\"],\n [\"A\", \"B\", \"C\"],\n ],\n [[\"C\"], [\"A\", \"B\", \"C\"]],\n [\n [\"A\", \"C\"],\n [\"A\", \"B\", \"C\"],\n ],\n [\n [\"B\", \"C\"],\n [\"A\", \"B\", \"C\"],\n ],\n ];\nNow there’s a well-suited mathy modeling!
\nSome other thoughts
\nCombinatoric applications for this algorithm are quite expensive: you can see how the cardinality flourishes pretty fast above, and my example is for a modest 3 order items and 2 suppliers. If those numbers increase by any measure CPU will be tremendously exercised. (I believe the runtimes of these functions may be polynomial?) I can see why optimization becomes an attractively ripe apple for academicians. Quickly glossing, I can imagine optimizing the looping functions to break before completion when satsificing within a range of acceptance criteria; or structuring the data as Iterators and/or piping through transducers to minimize space complexity with lazy or eager techniques.
\nBy the way, JS has pretty underwhelming options for combinatorics. I found one library that I found a bit awkward to use and ended up ditching in favor of a few standalone implementations of powerset and permutations so I could ensure the code would comply with how I was trying to express the above heuristic. Unsurprisingly, Python’s itertools has combinatoric functions built in and even provides recipes for common tooling you can build on primitives like permutations() and combinations(). For example, powerset().
def powerset(iterable):\n \"powerset([1,2,3]) --> () (1,) (2,) (3,) (1,2) (1,3) (2,3) (1,2,3)\"\n s = list(iterable)\n return chain.from_iterable(combinations(s, r) for r in range(len(s)+1))\nOr simply import the blessed more-itertools library. Of course, this is expected for Python which is heavily developed for the data science world.
![\"MV5BN2NhZTg0MDgtMTc5ZC00MGQxLThhNzEtYmE5ZjRiMzI5ZTcyXkEyXkFqcGdeQXVyMjUyNDk2ODc](\"https://internetross.space/uploads/2020/a8f0ecd5f0.jpg\" "\\"MV5BN2NhZTg0MDgtMTc5ZC00MGQxLThhNzEtYmE5ZjRiMzI5ZTcyXkEyXkFqcGdeQXVyMjUyNDk2ODc@._V1_.jpg\\"")
\nBack in February, my entire notion of expertise and how experts make decisions became cracked after listening to episode 169 of the Greater than Code podcast. While the podcast is rolling I’m discovering my socialized construction of expert – like we pump and grow some kind of muscled query power of an expanding brain-database over time. And that combined with a trained analytical rigor gained through extensive tutelage, study, and practice.
\nI’m struck by how neo-classical cyberpunk-capitalist fantasy that notion sounds: a techno-positivist outcome of brain as database; the privileging of expertise as accumulation. The time-value of memory perhaps.
\nIt’s kind of wild: wondering about what sort of instinct decision-making really is in concrete terms. Thankfully we have the >Code crew to help us navigate Decision Theory from the safety of our own home. The podcast panelists offer a different notion attributed to Gary Klein’s work Sources of Power: How People Make Decisions. Rein’s paraphrasing of this more probable notion for quick decision under time pressure situations in our business environs:
\n> Expertise is an act of rapid mental simulation without formal analysis based on previous experience. It’s more akin to “instinct” than a cartesian scientific methodology.
\nGary Klein calls this model “recognition primed decision” or RPD. The key is that over time and through experience we continue to enhance our instincts around familiar problems, and replace outdated versions that don’t make sense in our newer model of the world. No need to increase disk/head space! Then, when facing a quick-decision moment, we can make a strong guesses. Informed guesses, not overly formal; certainly not grooved to dreams of electric sheep or Moore’s law or, by necessity, scholastic architectures of cognition. But not totally informaled, either; we are making smart connections.
\nI find RPD comforting as a way to rethink my role as an expert despite fewer than a decade of years practicing my trade: a sophomoric “mid-level” software engineer. While RPD reveals the distinctions between less experienced and more experienced people – notably the former’s exceeding alacrity to arrive at a first course of action – RPD is about evolving your pattern matching, identifying the least risky choice, mentally modeling/imagining outcomes (see Variations)
\nEmbracing an RPD notion of expertise can ramify more permissions for less skilled SWEs to face spontaneously emerging decision-making moments in the workplace with less imposter syndrome and tougher felicity. Fellow career middlers, if you have an idea, basically just trust your power of . RPD also beseeches us to expel myths like (quickly riffing): Principal and Staff technologists have reached their eminent station by putting in the time to refine their powers of inspection, analysis, interpretation, evaluation; they’ve amassed all the good frameworks, methodologies, and systems into their memory bank; and decisions they make are conclusive (foreclosing, narrowly, the scope of possibility) because of this special toolkit which is wielded though an infallible reason.
\nReason and logic might factor into RPD mental simulation, but there’s a primacy of imagination and knowing deep down. Strength of will even?
\nI am enough. My powers to decide can be totally excellent.
\nOf course, that doesn’t mean my first guess won’t be totally wrong. But hopefully I’m not asked to fix something urgent that far exceeds my bounded rationality of this domain; which might ramify harm on real people if the mark is missed, goddess forbid and forgive.
\nI did some additional reflection with the >Code community in their Slack on why I was feeling relieved by Klein’s ideas (Jessica Kerr hearted this so I’m feeling proud to share!):
\n> Thanks. This really struck me because I think I have internalized some idea that experts have these academically rigorous approaches to problems where they draw on frameworks and data and tools blah blah to come to conclusions.
\nThen Rein chimes in:
\n> Yeah, the analytic decision-making mode is what we are taught, but it’s not what people actually use, especially in high-pressure situations.
\nThe me again:
\n> Oh right that was the other piece. [Making decisions under] high pressure. Which in corporate culture feels like all the time a lot.
\nThen some other folks tried to pivot the conversation to talk about how web tech is not really that high “pressure” because bad decisions don’t kill people or necessarily tank the business immediately. So I continue:
\n> I understand where y’all went with that idea of “high pressure.” But even without the kinds of excess you describe — which I’m grateful not to feel at my (fairly spread out) 1000 person company — I still feel like I’m caught up in a heavy stream; not in a surprising or terribly uncomfortable way; but like a tireless machine of ambient conversation between me and my work and my coworkers that is always humming. So maybe “high pressure” in the sense of constant. Day to day I feel coerced into what feels like quick/on-the-spot decision-making, and always on guard for such; and that’s definitely challenging for me.
\n> Like, I’m a developer, and I have to make a ton of small decisions all day long when coding. Even medium-sized decisions. (Like the other day deciding whether to coordinate on a revision of a standard component with a team in Spain with similar needs, vs plowing ahead myself because I knew that process may take weeks and I needed output in days). And often these decisions have to happen within a matter of minutes because of the above normal buzz. I think I remember there was another episode where folks talked about how developers make more decisions than CEOs on any given day?
\n> I was finding comfort in this idea from Gary Klein because I can consider whatever my instinct draws on in that moment to be a practice of expertise. I can feel like an expert; and without any added insecurity for a lack of analytical rigor, if I had to explain my decision. I usually have confidence in my decisions, but I didn’t have a framing of it as expertness. A framing I was likely lacking, as Rein said, because I’ve been taught a dichotomy between analytical thinking and instinct, where there actually isn’t one; at least as I understand the idea without having read the book yet. But as someone relatively new in the industry — just around 6 years building web — being able to come into expertise or see it forming in my behavior is really nice.
\nEarlier today, delving through Software Development and Reality Construction, I was delighted to discover another rebuke to my previous ideas of expertise as analytical reason qua database. It smacked of Klein and I wonder if Reinhard Keil-Slawik is influenced by Klein – or conversely – or perhaps they swarm with each other in that world of systems thinking, cybernetics, constructivism, etc…
\nFrom Keil-Slawik’s essay Artifacts in Software Design:
\n![\"Reinhard](\"https://internetross.space/uploads/2020/09857ecfae.png\" "\\"reinhard-keil-slawik-insight.png\\"")
\nKeil-Slawik argues that expertise – ie “insight” – is an enrichening of “understanding.” Understanding being a cognitive structure derived from the encounter with our envionrment which mashes up phenomena (physical, etc…) and circumstance. It’s not random access from a brain-as-database that has been populated with arrangements of stuff from “out there” - outside ourself/mind – (previous cognitive structures); as if insight is just a result of recall or trial; that smacks of an easy slippage slide into decision paralysis.
\nRather it’s:
\n![\"Reinhard](\"https://internetross.space/uploads/2020/025a295bb7.png\" "\\"reinhard-keil-slawik-insight-2.png\\"")
\nThis notion seems to gel well with RPD. I wonder if Klein would welcome this cognitive science to explain how we do decisions.
\nI’m tempted to accept this explanation pro-tem since the thought of unbounded accumulation of stuff in the brain, and lookup at exponential runtime, doesn’t satisfactorily explain the reliable guesses of experts under time pressure. This idea finds kinship with Nora Bateson’s characterization of sensemaking as Warm Data collection:
\n“For some reason, you know what it would feel like to put your tongue on the rug — you almost know what it would taste like. You have been gathering the contrasts, comparisons, and differences that give you that sensing since you were born, maybe even through the sense making of prior generations. You have no files for those data.” 🚀
\nKeil-Slawik and kin are proposing the idea of human expertise as an individual construction of meaning, as well as a co-constitutive emergence of our own body/mind wisdom and the “external memory” of symbols and tools we work with. The latter is an important point because it reinserts the importance of mneumonics as Turing machines, algebra, languages, frameworks, etc…. This affords us the benefit of a tradeoff: speed of resolution over perfectness. The example Keil-Slawik gives is of the ape who, if taught once to put sticks together to reach a banana, will subsequently devise similar means of combining objects to get the banana “without any hesitation…and any similar situation.”
\n", "date_published": "2020-09-07T01:00:00-07:00", "url": "https://softlydeveloping.micro.blog/2020/09/07/the-loss-of-logical-purity.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2020/08/06/byzantine-algorithm-studies-using-math.html", "title": "Byzantine algorithm studies: Using math to reverse an integer", "content_html": "Making code do something requires exactness but that doesn’t necessarily mean programmers will express grammars with any particular concision or ease. Code is an outcome of social construction, background, perhaps aesthetic desire. Toy code problems reveal the apparatus, for sure. If you ask me to reverse an integer I’ll build a world of arrays – because I like them. Directionality makes me think of traversal, therefore arrays. I also recall the reverse() convenience immediately. However, as a result, I’m forced to deploy morphological contortions; which might feel icky for someone derived within an algorithmic hermitage, auto-recursively deriving pleasure therein.
Reversal is now nearby:
\n// STEP 2 - traverse, recombine\nlet reversedIntString = intAsArrayOfStrings.reverse().join("");\n}
\nAll that remains is a second transmogrification back to the initial type and signing:
\n// STEP 3 - Sign\nlet result = Number(reversedIntString) * Math.sign(num);\n}
\nBut it has come to my attention that a mathy person prefers preservation, whereby the input is arithmetically recombinated with the help of division and multiplication.
\nwhile (int) {\nremainder = int % 10;\nresult = result * 10 + remainder;\nint = parseInt(int / 10);\n}\nreturn result;\n}
\nreverseInt(12345);
\nBut there’s no translation from integer to array. No shift. Grammar school level maths instead. I guess this solution exalts type consistency. Perhaps belies an obsession with 10? The base binary pair. I can’t imagine the benefit of doing that in a commercial software project so it could only be an academic fancy, benchmarked under extreme conditions. It’s really clever, though.
Also, been thinking about slice a lot today. Never stop dreaming:
> …bugs are interesting and important in themselves: they define the boundary between what is understood and what is not. Hence, they show us where our weaknees are, and provide opportunities for us to learn and grow.\n>\n> \n>
\nThe rush to fix bugs to recoup customer satisfaction is absolutely necessary when writing for capital. I just worry that without the proper retrospection we won’t actually increase our understanding of the software, and therefore the recidivism rate of error will remain constant; or likely increase in the tail wind of growing complexity and entropy.
\n", "date_published": "2020-07-15T01:00:00-07:00", "url": "https://softlydeveloping.micro.blog/2020/07/15/whats-a-bug.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2020/07/11/recursion-is-too-easy-for.html", "title": "Recursion is too easy for writing nested menus in UI", "content_html": "When paired with component-based framework tools and HTML’s unordered lists. Since the rendering is done by the framework, we simply need to progressively stack render calls as we traverse the data. Such brutalist Dada.
\nfunction List({ items }) {\n return items.map((item) => (\n \n - {item.name}
\n {item.children &&
}\n
\n ));\n}\nEach time I implement a recursive function when writing practicalities for commercial software, my notional machine of it’s behavior is refined. A small list of heuristics continues to amass in memory:
\nAfter working on another problem recently that involved deep-diving a nested JavaScript object and executing validations against each level I’m adding:
\n> “Recursion is awkward if you need to break early.”
\nIn my particular case I needed to validate a recursive data structure representing an org chart of Employees and return invalid immediately if the code traversed an Employee with bad data – extra fields, missing required fields, fields of the wrong type, etc….
\nBreaking out from a recursive function is not quite as straightforward as you’d think. Also, historically I was used to seeing recursive code employed for tasks that wanted the call stack to build up all the way through the data.
\nLike, (deep) flattening an array:
\nfunction deepFlatten(nestedArray, result = []) {\n for (let element of nestedArray) {\n if (Array.isArray(element)) {\n deepFlatten(element, result);\n } else {\n result.push(element);\n }\n }\n\n return result;\n}\nOr, fetching a complete set of data from a remote source in chunks:
\nasync function fetchAll(params, all = []) {\n let chunk = await fetch(params);\n let nextPage = chunk.nextPage;\n all = all.concat(chunk.data);\n\n if (nextPage) {\n let nextParams = { ...params, page: nextPage };\n return await fetchAll(nextParams, all);\n }\n\n return all;\n}\nWhat I quickly discovered is that just trying to capture and emit an error from a recursive call stack is already a bit funky. Simply returning false in your function doesn’t work because calls lower on the stack may return true; and since we’re (kind of) “building a value” it only matters what the final call returns. This approach won’t work:
// Will only return false if the last call in the stack returns false\nfunction validate(data, schema) {\n for (let item of data) {\n for (let rule of schema) {\n let field = item[rule.name];\n let required = rule.required;\n\n if (required && !field) return false;\n\n // Recurse\n if (Array.isArray(field)) {\n validate(field, schema);\n }\n }\n }\n\n return true;\n}\nUsing recursion is more like a leap of faith - you are handing over control to the JS engine over an unbounded data set; it’s quite reminiscent to the manner in which higher order functions operate with Array and Object collections. For example, forEach is a powerful and declarative alternative to for and for..of/in loops until you find yourself needing to skip over an iteration or break out of the loop. Keywords like continue and break are unavailable in Array and Object collection methods – these are closed iterators.
Your only recourse in a recursive function is relying on outer calls – since the call stack is LIFO - to set that flag and pass it through each stack layer. So capturing and emitting an error from your recursive function might look like this:
\nfunction validate(data, schema, errors = []) {\n for (let item of data) {\n for (let rule of schema) {\n let field = item[rule.name];\n let required = rule.required;\n\n if (required && !field) {\n errors.push(error);\n }\n\n // Recurse\n if (Array.isArray(field)) {\n validate(field, schema, errors);\n }\n }\n }\n\n return errors;\n}\nIf our program requirements suggest we want to parse the entire org chart for bad data, this function will give us a result array we can further process to report errors. But for my purpose, there’s too big a potential cost of unnecessary runs while a large call stack is cleared for a large org chart.
\nIn order to stop processing the org chart and return an invalid result early, we need a solution that stops execution entirely when the invalid check is entered in the outermost call. Alas, the solution ends up being rather elegant and simple, though counter-intuitive. Rather than returning (false, an error list, etc…), you can throw and thereby forcibly halt the engine’s execution of the code. Here’s an example with throw:
function validate(data, schema) {\n for (let item of data) {\n for (let rule of schema) {\n let field = item[rule.name];\n let required = rule.required;\n\n // It's even one less character to write! 🤣\n // Also now we have total control over the exception content\n if (required && !field) throw new MissingFieldError(item, rule);\n\n // Recurse\n if (Array.isArray(field)) {\n validate(field, schema);\n }\n }\n }\n\n return true;\n}\nDay in, day out we work constantly with client applications that only trhow as a result of unintended bugs in the program. But we can take advantage of this standard JavaScript behavior and erect an appropriate error boundary. Remember:
\n> Execution of the current function will stop (the statements after throw won’t be executed), and control will be passed to the first catch block in the call stack. 🔗
\nTherefore we can rename and wrap our recursive function that throws, and put it inside an error boundary to achieve that early break we want. This approach even comes with the added advantage of declaring the content of our user-defined exception at throw site; eg, utilizing meaningful error constructors or factories like missingFieldError().
function validate(data, schema) {\n try {\n validateInner(data, schema);\n } catch (error) {\n // returns new MissingFieldError()!\n return error;\n }\n return true;\n}\nEven more, the elegance of this design with an outer try/catch allows for separate testing of our validation business logic – the rules against which bad data throw – and error handling – what errors we emit for certain cases.
\n", "date_published": "2020-07-05T15:51:00-07:00", "url": "https://softlydeveloping.micro.blog/2020/07/05/a-recursive-validation-function-with.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2020/06/16/debugging-ts-in-vscode-and.html", "title": "Debugging TS in VSCode and Russel Ackhoff's Problem Treatments", "content_html": "During a global pandemic and massive civil rights upheaval, as I drift between jobs I tease away some time from protest and anti-racist organizing to study programming basics. I plunge below the membranes of web frameworks. The first thing you notice when sitting down to write some code is the brutal lack of the full-featured dev environment you had on the job.
\nI had a serious moment of angst this morning about whether I could achieve debugging for TypeScript files in VSCode within a reasonable amount of time – that is, an amount of time that wouldn’t deplete all my creative energy before I could even write a single little char. To my very pleasant surprise this was much easier than expected. You need two things.
\n{\n "version": "2.0.0",\n "tasks": [\n {\n "type": "typescript",\n "tsconfig": "tsconfig.json",\n "option": "watch",\n "problemMatcher": ["$tsc-watch"],\n "group": "build",\n "label": "tsc: watch - tsconfig.json"\n }\n ]\n}\n{\n // Use IntelliSense to learn about possible attributes.\n // Hover to view descriptions of existing attributes.\n // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387\n "version": "0.2.0",\n "configurations": [\n {\n "name": "Launch server.js via nodemon",\n "type": "node",\n "request": "launch",\n "runtimeExecutable": "nodemon",\n "program": "${file}",\n "restart": true,\n "console": "integratedTerminal",\n "internalConsoleOptions": "neverOpen",\n "runtimeArgs": ["--experimental-modules"],\n "outFiles": ["${workspaceFolder}/out/**/*.js"] // <-- ADD YOUR OUTFILES GLOB HERE\n }\n ]\n}\nAnd voila, here I am pausing on a breakpoint:
\n![](\"https://internetross.space/uploads/2020/d2e47c2f87.gif\")
\nOk new topic…
\nDuring episode 138 of the > Code podcast with guest Vaidehi Joshi of BaseCS podcast fame, amongst many other things, the discussion veers into the topic of problem solving ~20:30. Jamey and Vaidehi riff about that condition we all know and love, and never seem to appreciate enough, whereby solutions come to you while away from the computer. While your brain is “percolating” (Jamey) or in a “mental marinade” (Vaidehi). Jacob Stoebel chimes in describing another common mental turnabout we programmers do: when we catch ourselves down a rabbit hole trying to solve (big “S”) the problem with our first instinct and the increasingly deeper and muddier slog forcing us back up for air, whence we pause, shake off the adrenaline, and climb out of the hole to wonder: how do I just get rid of this problem zone entirely? Rein, per usual, picks up the thread and introduces the panel/listeners to a theorist named Russell Ackoff who minted a classification for approaches to problems called “Problem Treatments,” which includes the concept of “dissolution” that applies to Jacob’s case.
\nTo list and paraphrase them:
\nAbsolution - Ignore the problem and hope it goes away
\nIt’s easy to joke about this one, but Rein provided a compelling case for this. For example, security engineers often make the tradeoff to ignore a security loophole if the threat isn’t great enough.
\nResolution - Doing something something “good enough”
\nThis feels like a pretty standard principle for building products considering some of these typical aspects of commercial software development:
\na) Your team will never have a complete understanding of how your software will express itself once “running” or “used” by customers. Therefore perfection, completeness, wholeness are not desirable or ever, actually, achievable.
b) Deadlines and other external stakeholder pressures will force you to sacrifice however your team defines “great” or “better” software
\nSolution - Finding an optimal solution with experimentation or research
\nThere are touchstone moments in the development of software where this happens. When choosing a framework. When designing a styleguide. When choosing a caching strategy. When designing a migration plan.
\nDissolution - Redesigning the system so that the problem no longer exists
\nThis is what Jacob was hinting at. That pure land you inhabit when refactoring code to circumvent an immediate impasse in the software by reframing the problem.
\nI fondly remember dissolving a particularly tricky conditional statement in a web client by working with a backend engineer to implement an enum for a resource type. This removed a bunch of object introspection (Law of Demeter violations, etc…) in favor of a simple switch statement.
\n", "date_published": "2020-06-16T15:39:00-07:00", "url": "https://softlydeveloping.micro.blog/2020/06/16/debugging-ts-in-vscode-and.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2020/06/16/the-explanation-of-question-of.html", "title": "The explanation of Question 12 of Lydia Hallie's fabulous list of JS interview questions, and others", "content_html": "Lydia Hallie’s list of JS interview questions are extensive and probably one of the most comprehensive resources out there. The laundry list of questions runs the gamut from basic to esoteric language features, each of which progress you though various themes in what seem like meaningful sequences. It appears some modicum of pedagogy is involved, which therefore avoids that oft vacancy of substance typical of a listicle.
\nYesterday I was running through a block of questions with an ex-colleague and we noticed that some of the answers were a bit inchoate. It’s so easy for meaning to drift when talking about language features especially when it comes to JS. Consider navigating the following taxonomy – related to creating objects in JS – for readers of all skill levels without specious reasoning (the kind of short-hand you get the point or close-enough superstitious explanation we sometimes use; which, by the way, I think greatly hindered my early career development): object, constructor, function, class, prototype, instance, static, method, new, this. It’s quite hard but really worth being as correct as interpreting ECMAScript affords us.
I decided to open up some discussion on Question 12 which tests one’s knowledge of the differentiated effects of using the new operator before a function call:
https://github.com/lydiahallie/javascript-questions/issues/82#issuecomment-645022140
\nDefinitely called for a little revisit of YDKJS, no doubt.
\nI also feel like I need some clarification on Question 14. What do we call the very root object in JS that all objects delegate to?
\nhttps://github.com/lydiahallie/javascript-questions/issues/26#issuecomment-645058195
\nComing up with examples is hard. I think Question 11 could use a bit of rework too because there is a this scope issue that somewhat overloads the focus of the problem. Here I go again:
https://github.com/lydiahallie/javascript-questions/issues/355#issuecomment-645066354
\n", "date_published": "2020-06-16T01:00:00-07:00", "url": "https://softlydeveloping.micro.blog/2020/06/16/the-explanation-of-question-of.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2020/06/08/book-quotes-and-commentary-software.html", "title": "Book quotes and commentary: _Software Theory_ by Federica Frabetti", "content_html": "In which Frederica Frabetti locates the “points of opacity” – malfunction – in/of software through study of the Garmisch (Germany) report – a foundational text of software from the first Conference on Software Engineering in 1968 organized by the NATO Science Committee. (Also careful you don’t mince the word “Garmisch” into Gramsci.)
\n> “…these two aspects…the necessity of calculating incalculable risks, and of attributing responsibility for them…is a point where software engineering ‘undoes itself’ precisely at the moment of its constitution.” -p75
\nAs in discovering responsibility outside of the software: in the likeness of user demands, society’s problems, ever-increasing demands on existing software from users.
\n> “…there are problems out there that software helps to solve.” -p79
\n> “…the system and it’s development are never clearly separated” -78
\n> “…they must acknowledge that such a process is not in fact linear, but at the same time they have to avoid backward steps at all cost.” -p78
\nAnd how professionalization, as in the planning and management of software development over time – or formalism, or “linearization”; where we literally write many things to organize time (external and internal design specs, JIRA stories, prototypes, then finally the code (I guess) etc…) – relegates software to the realm of instrumentality and further destabilizes what software is; albeit by attempting to create an interiorized structure that skirts isolation. Thus the evergreen frustrations of the business side.
\n> “…this appeal to the lineraization of time is part of the general attempt to ‘control’ software – that is, to think of software in instrumental terms.”
\n> “…software is both a problem and a solution – indeed, it emerges at the point where the distinction between the two becomes undone and it exists only as the precarious stabilization of this distinction.” -p81
\nSoftware development is a fleeting discipline. I guess a line of flight in the rhizome. So maybe we’re hearding rats not cats. This partly explains, for me, why I can iterate again and again over a simple “implementation.” Because we’re never done, we’re always undone.
\nHence our continued, common problematic to characterize when commercial software development happens. Is it when you change all var to let? The moment your brain begins to mull over a requirement presented by your PM in sprint planning? The final inscription of the company’s mission statement? During a whiteboarding design exercise? The moments of realization you have in the shower, during a lunch conversation? The isncription of an idea you copy/steal from your last job without attribution? The deletion of unused code? The moment you decide to delete the unused code?
\nOr perhaps the moment we recognize it is bound to break, malfunction, fail:
\n> “…software engineering performs an impossible expulsion of consititutive failure from technology, with this move establishing itself as a discipline.” -p76
\nAnd further, what else software development is. Because it couldn’t just be about formalizing the process, right? Because how do we account for the incalculability of costs/time between problem and solution?
\n> “Thus, Dijkstra resorts to individual creativeity – or, as Derrida would have it, ‘genius’ – as an explanation for what is in excess of a procedural method and constitutes a leap beyond the programmable.” -p82
\nBut others from the conference warn about the cult of genius. Interesting earlier this year I was mulling over a similar intervention four decades later:
\n> “The ‘exessive’ creativity of the ‘system type’ is in turn portrayed as ‘bad’ unexpected–something that exceeds the management of the project and threatens it.” -p84
\nReplace “system type” with our modern-day 10x programmer or rockstar and it’s comforting to think that 50 years ago computer scientists were already weary of the danger this person posed to software development. It certainly seems like Frabetti is jabbing at that here.
\nSoftware resists instrumentality, to be merely called “code”; it follows, then, that engineers resist becoming fungible resources in a complicated domain space. Software’s realization is a co-consititutive process of increasing understanding of the problem and the solving of the problem itself. I like the way this passage sums it up:
\n> “How can something based on the lack of knowledge be realized successfully? This paradox clarifies the particular understanding of time that programmers develop in their interaction with software. Not only does one find out what the system does only by constructing it; the original ignorance of what the system does is constitutive of the system…Infelicity is constitutive of the possibility of felicity…One always starts albeit one does not know what will be.” -p90
\nOf course, the solution is never an end. Or have you ever built software that should not be extensible?
\n", "date_published": "2020-06-08T01:00:00-07:00", "url": "https://softlydeveloping.micro.blog/2020/06/08/book-quotes-and-commentary-software.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2020/04/26/lets-talk-about-orchestration-vs.html", "title": "Let's talk about Orchestration vs Separation of Concerns", "content_html": "Check out the second – and I believe last – in this short series: https://dev.to/internetross/let-s-talk-about-orchestration-vs-separation-of-concerns-react-redux-edition-part-2-imo
\nI’m emerging from the shadows, a bit, and trying out dev.to. Check out this first in a two part series: https://dev.to/internetross/let-s-privilege-orchestration-over-separation-of-concerns-4410
\n", "date_published": "2020-04-26T01:00:00-07:00", "url": "https://softlydeveloping.micro.blog/2020/04/26/lets-talk-about-orchestration-vs.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2020/04/01/preferring-repetitive-action-notifications-over.html", "title": "Preferring repetitive Action notifications over reuse", "content_html": "Have you ever noticed yourself going to unnecessary lengths to avoid repetition in your code despite the fact that requirements actually represent a complicated world? I swear the longer I write code in the industry the more DRY feels like a leaky ideological imposition that drifts from “knowledge” duplication into code/documentation – ie text artifact – duplication. Sigh. This is a nuance we lose too easily by the ad nauseam peddling of the shorthand DRY; which I suppose also reveals the danger of the supremacist tendency of the axiomatic; axioms all-to-easily claim ontological root. Especially in the minds of early career folks or folks emerging from industry founding fathers cargo cults.
\n> Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.\n>\n>
\nAs we’re tapping along in an editor, the code that bears some resemblance to other code is, in fact, the precise nuance our applications need to create the richness of these membranes we build between people and machines. Here’s an example slightly altered.
\nLet’s say we are working with an events management system where a new feature is being built to allow event organizers to administer marketing campaigns on their events. In the current world, an event organizer can do two things to a campaign once it’s added to the event:
\nA sketch of the stateless component in our graph might look like so (just relevant JSX and event handler):
\n\nThen Product decides to add a new nicety whereby an event organizer, when activating a marketing campaign, will automatically trigger marking that campaign with the special “featured” flag if that campaign happens to be the only active marketing campaign on the event. This is effectively a third flow; of course to the user it’s just a list item with a couple check boxes (simple stuff, right?).
\nAs the developer I might think: this doesn’t seem all that hard! I already had the foresight to implement a flexible indirection – a consolidated event handler to coordinate the store notifications for user interactions in one place. This means all I have to do is flavor the conditional will another branch; and I can reuse the current dispatchers. I’m a fucking oracle.
\nWhereby I try:
\n\nI mean, that’s the right logic. All my test mocks are reusable. We are sailing along.
\nSort of.
\nThen something nags at me looking at this code. It’s subtle, but there’s a risky assumption embedded here. Inside the interior if-then branch under the conditional expression hasNoActivated, we are sending a sequence of two distinct mutative notifications to our data store; moreover, the second depends on the first to complete successfully. Now, we might test this code in the browser and it works every time. Our tests pass.
But.
\nFor how long?
\nThis code lives downstream of our next indirection – the container – that shepherds these messages to the store. So this code is trying to coordinate a subroutine of effectful functions (Actions) three (perhaps more) layers away from the store itself.
\nWhich begs some questions. For example, although the action notifiers I’m calling are synchronous, how confident am I in the inner workings of my component framework’s render engine and algorithm – particularly it’s collaboration with my data layer (ie Redux)? I might be forcing additional renders here. More importantly, how much can I trust other developers to maintain the correct sequencing in the container? Will a test help? Will a comment help? Will either of these prevent mistakes when additional behavior needs to be added.
\n100% maybe.
\nSoftware is weird. Code like this could become a productive, yet forgotten, corner of entropy. But silent risks, if recognized, must be avoided. We can do better, although part of reaching this better is yielding our mental model to become more reactive – to adapt, to embrace nuance, to become loose as the requirements become more complicated. My observation is that the code is not lack for defensive guards and documentation, but lack for an expanded set – single, unambiguous, authoritative – of blessed possibilities with distinct articulations. In other words, an expanded model – expressed in code – that models more precisely the desired possibilities of what a user can do.
\nLet’s try rewriting our component-level event handler to incorporate the new happy path into our domain’s lexicon: the Action notifiers, the names of things “that depend on when they are called or how many times they are called” (see Grokking Simplicity).
\n\nThe modifications in this third example add a new Action notifier (handler) that represents the distinct type of mutation we want to effect against the store. In other words, a function that satisfies the new Product case that narrows attention – of the developer and program – on the new case by leveraging a semantic, structural, change to the number of container handlers. (Side note: I fantasize that Zachary Tellman might describe the new handler name as a too “natural” yet still “consistent” name (see Elements of Clojure).
\nFurthermore, let’s observe that the payload semantics remain the same. Which means our data layer comprised of the container and action dispatching, only requires similarly modest adjustments to shepherd the same data. Lastly, though quite importantly, our container is now capable of dispatching messages to the store and effecting a mutation in just a single pass if we wish it. For example:
\n\nupdateCampaignAndUpdateFeaturedCampaigns(data) {\n dispatch(updateCampaigns(data));\n}\n\n// Whereby our reducer might return the state mutations composed as:\n\n{\n campaigns: {\n ...state.campaigns,\n {\n id: payload.id,\n activated: true\n // other fields...\n }\n },\n featuredCampaigns: [\n ...state.featuredCampaigns,\n payload.id\n ],\n}\nOverall this design provides increased confidence that this display component, our presentational leaf node, is more precisely responsible for render and event notification. Perhaps the subtweet here is keeping events and messages 1:1, even if you wind up with similar or duplicate lines of code.
\n", "date_published": "2020-04-01T01:00:00-07:00", "url": "https://softlydeveloping.micro.blog/2020/04/01/preferring-repetitive-action-notifications-over.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2020/03/12/the-will-to-better-software.html", "title": "The will to better software companies", "content_html": "![\"Semilattice](\"https://internetross.space/uploads/2020/c998eb6b6b.png\" "\\"Semilattice-a-and-Tree-Structures-b-Source-A-City-is-Not-a-Tree-4.png\\"")
\nLately I’ve been thinking about productivity and it’s evolutionary rhythm while scaling. Like, how easy the cadence ebbs. My lived experience as a software developer often feels like anfractuous GPS reroutes. For example, we have split teams to tackle different product areas in parallel. Usually this means working separately in our “owned” codebases. But software is never neat. So when the team in Mendoza needs review on a changeset that touches our code area, we’re talking temporal crossings to achieve conciliation.
\nIt’s late afternoon in Argentina wine country when I’m just digging my heals into a morning Philz roast.
\nThe additional burden of a cross-geo async request means that I’ll have to hunker down to decipher what they’re proposed code is doing and what it’s supposed to do – what might take a few minutes pairing could take tens of minutes. While async communication over Slack is ok, closing the mental gap in understanding the code changes is tough. We are facing a kind of Derridean differánce. As if navigating the palimpsest wasn’t enough. Multiple personages reading and explaining the code text, scribbling comments, changing, re-reading the next day; discovering the truth in the spaces/tabs. Reading software is really tough stuff. This impact of distance and time spent to “get up to speed” (pun intended) is a delta that doesn’t always feel satisfyingly addressed by organizational planning.
\nDoes this sound like what you do for work?:
\n> Every software project is like a palimpsest where every developer scratches old text, and writes on top of it their perceived new solution, creating a manuscript where a mix off styles and languages reflect different understandings of the world, different world visions.\n>\n>
\nAnd
\n> Différance is the systematic play of differences, of the traces of differences, of the spacing by means of which elements are related to each other. This spacing is the simultaneously active and passive (the a of différance indicates this indecision as concerns activity and passivity, that which cannot be governed by or distributed between the terms of this opposition) production of the intervals without which the “full” terms would not signify, would not function.\n>\n>
\nHoly complicatedness, richness, depth! No wonder you can’t just throw more devs at the problem. Though apparently that’s what men in the industry used to think.
\n—
\nNot too long into my first software gig my team of 5 engineers organized a book club and tackled The Mythical Man Month. That’s when I really learned how dev teams became reduced to fungible “resources.” (It wasn’t long before I was at a happy hour and our head of sales was asking me, “Why can’t we just ship the work you do to India?” So I apparently it’s a historically recurrent theme.) It was also my first introduction to the idea that you can’t just throw more people at software problems to achieve speed gains.
\n> Adding manpower to a late software project makes it later.\n>\n>
\nIf we believe Jessica Kerr and the other cyberneticians of our ilk, and on this point I might – software is a symmathesy: a learning system of learning parts. Brooks must have believed something similar I just don’t remember his exact words.
\nNonetheless, I interpolate. Brooks' insights feel situated as early symmathecist thinking. Software is so highly sophisticated, so highly complicated!, that command and control thinking can’t intervene to establish order:
\n> As time passes, the system becomes less and less well-ordered. Sooner or later the fixing cease to gain any ground. Each forward step is matched by a backward one.\n>\n>
\nSo why does this happen? Like, despite Brooks' spacious, ethereal characterization of our work as only slightly removed from pure thought-stuff where we build castles in the air (words I do remember wonderingly)…we definitely live through a tangible stickiness, queues, waiting rooms; especially mid-to-late in the build cycle. Things get really hard. I swear there’s something even metallic about a build failure.
\n> In order to change our system, we need a mental model of it. Each developer has a mental model of the software we work on. Each developer’s mental model is necessarily incomplete and out of date. And, they’re each different from everyone else’s. (This is called Woods’ Law, if I recall correctly.) We spend time reconciling our mental models enough to communicate with each other; this is a coherence penalty.\n>\n>
\nWell, we all know the drill and can recall with pretty sharp clarity what tends to happen. Making code changes later in a project becomes increasingly difficult because previous design decisions have constrained possibilities. More consistency is demanded; maybe not total, but if the component handlers should call to the reducer, why are you calling setState() directly in the handler? Because…the rush to the finish line produces anxiety that strains communication (within the already polynomial channeling). You shift from pensive philosopher to tactician; code breaker. Code review quality suffers; if only for the obvious reason that you need to double down on crafting and glueing code for more hours in the day. This, in turn, decreasing mental reserves for context switching to someone else’s code. All that great senior leadership out the door. There’s simply less consensus building. Public Slack channels are quieter. Regardless how high-performing the team, I’m convinced there will be some communication degradation in the twilight hours.
—
\nWhen I read Coda Hale’s recent piece Work Is Work all of this ugh was loaded into view again; and I really appreciate his analysis of how we end up in slog mode; and the antidote. Maybe the industry hadn’t received a really concise reflection in a while. Maybe it’s the mathematical proofing and formalism that adds a seductive element for the modern SWE struggling in their unwieldy symmathesies; what Karatani would call our “will to architecture”. This piece was going around the Greater than Code sphere for sure. For my philosopher/poet brain for sure. Ok, so similar to Brooks, but for orgs, Hale says:
\n> At some point in time, every organization realizes that it’s slowing down.\n>\n>
\nLike Brooks, Hale is dealing with that slog. But with the scope zoomed out to help us understand how to manage and overcome the obstacle of big organizations growing at economies of scale. He enriches the idea of the mythical man month with Amdahl’s law:
\n> The work capacity of an organization scales, at most, linearly as new members are added.\n>\n>
\nAmdahl’s law: I’m still wrapping my head around it! But I believe the gist is: when we try to add more people to parallelize parts of the dev work, we won’t get any dramatic (exponentialized) speed gains over the sequential work of the smaller group. Amdahl observed this behavior while throwing additional processors at a computational task in a computer machine. The “parallel fraction” of speed increase when adding N new members is only relative to the original group size, and eventually tops out and flattens. Rather than the speed boost our command-control leadership wills, we get something a flip side slog:
\n> Coherence costs grow quadratically as new members are added.\n>\n>
\nSlog = coherence costs! That’s a sweet little buttoned up phrase for it.
\nAround the same time I read Hale’s piece I was picking up the aforementioned Kojin Karatani book, Architecture as Metaphor. So while I’m sitting with these ahas! about how the frustrating things at work are these somewhat well-understood “coherence costs” that occur on large teams like mine which can be observed with rigor from the outside (etic)…I’m suddenly finding myself in chapter 4 of Architecture as Metaphor called the Natural City where Karatani continues to build his argument for the ways that theory is entrapped again and again by the architectonic. But the thread I want to pull on is simply Karatani’s synopsis of Christopher Alexander’s The City Is Not A Tree. Lol, of course I should meet Alexander here. He is like one of the father’s of Software Patterns – see his 1996 keynote at OOPSLA – that would inspire so much of how our apps are built at scale today.
\nIn the seminal essay The City Is Not A Tree, that would inspire people across fields and perhaps give rise to the concept of bounded rationality, Alexander proposed mathematically based, formal, structural, ideas (just like Hale is doing) to describe the “natural city” as a semi-lattice; a concept from Set theory.
\n> A collection of sets forms a semilattice if and only if, when two overlapping sets belong to the collection, the set of elements common to both also belongs to the collection.\n>\n>
\nHe is thereby able to reveal the “natural city” as something we can think about rationally. Particularly, and importantly, rationally distinct from the nemesis “artificial city” – a command-and-control style approach to designing cities in a treelike fashion from those who don’t appreciate the the richness, subtlety, and complexity in the overlaps that otherwise staves off “coming destruction” and “anarchy.”
\n> When we think in terms of trees we are trading the humanity and richness of the living city for a conceptual simplicity which benefits only designers, planners, administrators and developers. Every time a piece of a city is torn out, and a tree made to replace the semilattice that was there before, the city takes a further step toward dissociation.\n>\n>
\nAnd
\n> The semilattice…is the structure of a complex fabric; it is the structure of living things, of great paintings and symphonies.\n>\n>
\nMy brain keyed on semilattices because they seemed to describe the structure of a software system I’ve been coming to know through Kerr and Bateson (opera, camerata, living) – not to mention the cutely convenient lexical overlap of mathematical terms in the definition; eg, a “Set” is a common data structure implemented by many high-level programming languages. Mendoza devs putting their text in our text. Some overlap of time zone. Knowledge overlaps as more tenured developers work in more areas of the codebase. Overlap at the coffee station, at the lunch table. Overlapping documentation, nearly duplicate. Also the incomplete lines of connection. The grassroots partnerships and friendships that emerge across teams. The polymorphic ensemble of patterns and style in our web applications: classes called as functions, state reducers and DOM events, REST with GraphQL, compositional components within hard-bound graphs. Microservices databases implementing Order and User over and over again. The semilattice seems very familiar.
\nTherefore, in the context of a symathesy, where Alexander might say our bounded rationality (not to mention hubris, or inexperience, or ego, or other ingressive tendencies) limits our ability to observe and study the subtlety and richness of the organization, throwing more men at the problem is short-sighted as fuck. Managers can’t govern from apart, at the top of the edifice. There are superlinear interactions to behold.
\nThen the advice that Hale starts giving to tackle coherence costs makes a lot of sense:
\n> The only scalable strategy for containing coherence costs is to limit the number of people an individual needs to talk to in order to do their job to a constant factor.\n>\n>
\nLimit the overlap!
\n> As with heavily layered applications, the more distance between those designing the organization and the work being done, the greater the risk of unmanaged points of contention. Top-down organizational methods can lead to subdivisions which seem like parallel efforts when listed on a slide but which are, in actuality, highly interdependent and interlocking. Staffing highly sequential efforts as if they were entirely parallel leads to catastrophe.\n>\n>
\nAnd
\n> As an organization hires more employees, work on productivity improvements must be a constant priority. Internal tooling, training, and services must be developed and fielded to ensure that all members are able to work on problems of continuously increasing impact. The ceaseless pursuit of force multipliers is the only possible route to superlinear productivity improvements as an organization grows.\n>\n>
\nIn an essay I assume Hale drew from, and to which Jessica Kerr’s above quote references, Michael Nygard makes a similar suggestion:
\n> …take a look at your architecture, language, tools, and team. See where you spend time re-establishing coherence when people make changes to the system’s model of the world…take a look at your architecture, language, tools, and team. See where you spend time re-establishing coherence when people make changes to the system’s model of the world.\n>\n>
\nI love all this. Of course, it’s hard. Alexander tested folks, experimented to discover that the tendency was to “reorganize” the mental model into a treelike structure (though perhaps he only interviewed a group of limited white men, or folks embedded in white supremacist society?) But I suspect some of the hardness has to do with:
\nOur inability to see the costs (ie the complexity, simply constrained by our brain’s inherent limitation to expansively see/hold it all); for leadership looking at the org we can also probably say that their “mental model is necessarily incomplete and out of date”.
\n> It is similarly difficult to visualize the semi-lattice structure – where multiple sets overlap–of the natural city, and thus we tend to reduce it to a tree, the only structure we can visualize.\n>\n>
\nAn ignorance that we have a semilattice at all. Who out there amongst leadership are systems thinkers? Embracers and students of variety, incompleteness, ambiguity, multiplicity? Who can embrace these, split things, and double down on rewiring the learning (neuronic) threads? Ensembles over A/agile. More of that interspecies contamination, contaminated diversity that Anna Tsing talks about. Mushrooms and the dying earth can help.
\n> Where a matrix indicates a high-touch relationship between two groups (e.g., a group of engineers working on a feature and the lawyers trying to ensure the legal compliance of that feature), efforts should be made to reduce the cost of that interaction by colocating their members (e.g., embed a lawyer with the engineers).\n>\n>
\nManagement or whatever version of leadership you have must stay on top of it. It’s some serious work. Maybe we need better integration tech; it’s like we are missing some connective tissue. Maybe it’s not tech at all.
\nI remember being met with a lot of skepticism when I suggested to some engineers at my company that we create a meeting support team. It was a partially-formed thought, but the basic idea would be to make a self-selected group available to take notes for other peoples' meetings. I don’t think many devs grasp the importance of their meeting communication as architectural design records; and similarly how hard it is to accurately and correctly document after the fact; or document in progress for someone who is also trying to participate. Living in entropy is easier than culture change. I also understand that no computer science education ever taught anyone this stuff was important which is why Brooks' observations went unheeded for 50 years.
\nPostscript:
\nWhy did I keep trudging through Karatani while writing this essay?? I should have known better: a few chapters later I’m cry-laughing because I bump into that hopeful schizo theory which blew my mind like 20 years ago in undergrad. And now I’m like damn because Karatani is saying that the semilattice is probably not the ideal (post)structure I want to imagine upon my software company. Of course, this makes sense in Karatani’s argument because he wants to problematize architectonic thinking.
\n> Despite its appearance, [the semilattice] is orderly and centered.\n>\n>
\nAnd
\n> What happens when the semilattice is broken?\n>\n>
\nBy Delueze and Guattari of course. Whatever, I still think the semilattice is a good formal representation of why coherence costs emerge in the indeterminate, rich encounters of the software symmathesy; the gentle swish of overlapping domains; like at Hearst and Euclid. But the rhizomatic network requires consideration soon. I’m urged that way anyway – see my hints above about interspecies contamination and the anthropocene. I think the ensemble moves toward assemblage soon.
\n", "date_published": "2020-03-12T01:00:00-07:00", "url": "https://softlydeveloping.micro.blog/2020/03/12/the-will-to-better-software.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2020/01/24/some-patriarchal-intervention-at-google.html", "title": "Some patriarchal intervention at Google I/O a while back", "content_html": "\nAbout 11 years ago at Google I/O two dudes, Brian Fitzpatrick and Ben Collins-Sussman, presented The Myth of the Genius Programmer to an audience of mostly dudes. Well, we can surmise at the demographics because women were still being invented around this time.
\n> Women are a very recent invention.\n>\n>
\nOr, rather, reinvented since they had been denied participation in Western STEM since at least the middle 1700s:
\n> Women lost their security clearances very early in the stories of leading-edge science.\n>\n>
\nDespite the missed opporunity to cite the origins of congressive world-making in non-human-men being experience, indigenous practice, cooperative economics, anarchism, feminism, liberation theologies, etc…the talk is a pretty good orientation for ingressive types to think congressively about working with other people.
\nThat’s my subtext as I watch. I just wish men were erudite enough to understand they’re re-invention. Non-mens have to keep rewinding it back. For example:
\n> The men who wrote the [Agile] manifesto are unclear on whether they invited any women. Even so, the thing I notice from both the manifesto, the accompanying principles, and the fact that these 17 men call themselves ‘organizational anarchists’ is that what they came up with is inherently subversive, anti-authoritarian, and feminist. There is an emphasis on self-organising, collaboration, experimentation, welcoming change, and building high-trust and supportive relationships.\n>\n>
\nTech, like other industries, continues to produce the worst of/from man because its manifest teleology of Progress (what Donna Haraway calls “Euclidean tales…of tragic detumescence”, the “prick tale.” ) – sieved through history from the industrial revolution – is wrong for the precarity of the Anthropocene and a damaged earth. For richness of our symmathesies. We all suffer for it.
\nRacism and sexism are the key ingredients in the alchemy that has transformed “Don’t be evil” to solving the hard problems of “Controlling the explosion of child porn on the platform” (Youtube, to name a recent example. The darkest of whoops).
\nWhat these guys are hinting at is that an ingressive mindset can help us move us at the speed of trust, and therefore build better software together. So, yep, there was some movement going on a decade ago. Radical muds seeping into the granite of hard dick culture; white boys catching each other and putting together slides for the other boys.
\nThe talk is an introduction and invitation in trust-based collaboration and vulnerability. Touchstones include:
\nFrom the progenitor of the terms “ingressive” and “congressive” that I’ve been flinging about wildly:
\n> Ingressive is about going into things and not being waylaid by what people think or by emotions and congressive is about bringing people with you and bringing people together and unifying and making connections between things…. I’ve come to think that congressive behavior is basically better for society but that ingressive behavior is rewarded more by society because society is based on competition. It’s based on how you present yourself so for things like competing for a job, you have to be ingressive to put yourself forward for promotion and to talk about how great you are. Whereas, when you’re actually doing some work with people, then it’s really helpful to be congressive because then you bring people together, you understand people.\n>\n>
\nIt’s devastating to think about the enormity of emotional intelligence training men needed/need/will need; how expensive it is to refactor patriarchy’s structural grammar; that ambition which pits men against one another in an end game for supreme master and commander. In this ever-war even order and peace means the seizing of power; power must be assumed by the individual. It is not shared.
\nSure, there is a drip of undoing of Patriarchy when disenfranchisng the myth of genius; but the non-human-men bear the major brunt of burden for maintaining the moral center and possible salvation.
\nI’m reminded of another talk.
\n\nHillel Wayne turns a similar gaze navel-y and spotlights the peril of “charisma-driven development” we suffer in engineering culture. We might say another symptom of cock-sure genius arising. I love this talk. Recognizing the artifice of loudness and leaning, he looks at the data and calls bullshit on men. The data is good. It’s a tool. Nonetheless, I’m not sure Hillel’s Empiricism will be as powerfully feminist as interventions like Thomas' archeology. Of course, Cheng’s metonymic replacements are interesting in that they make it easier to implicate women’s complicit was in patriarchy. Hot take: overall let’s be skeptical of the neo-classical – logic can win – and neo-liberal – we can reach across the aisle tactics.
\n", "date_published": "2020-01-24T01:00:00-07:00", "url": "https://softlydeveloping.micro.blog/2020/01/24/some-patriarchal-intervention-at-google.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2020/01/20/thinking-about-heuristics-for-avoiding.html", "title": "Thinking about heuristics for avoiding code duplication across the stack", "content_html": "![\"Doublemint](\"https://internetross.space/uploads/2020/de42e3984a.jpg\" "\\"doublemint-1.jpg\\"")
\nAt the office I’ve sprinkled some glue labor on a piece of documentation that attempts a heuristics for avoiding code duplication across client and api layers. I kept seeing this type of repetition occur and it was creating too much maintenance risk in the code.
\nHere’s an example. Imagine a piece of code that takes inventory items from an order and derives a cost based on the order status. This calculation could be executed in the api layer, where it would be serialized into response body adjacent to the original cost data. Something like:
\n{\n inventory_items: [\n {\n order_id: 1234\n cost: {\n major: ...,\n minor: ...,\n // etc...\n },\n cost_display: 'MXN186.67' // <== augmented data\n }\n ]\n}\nThis is a totally reasonable API design. However, a client developer could decide to do the calculation in the view code with a more raw serialization of the inventory item and order objects, and then merge that data:
\nconst composeInventoryItemForDisplay = (inventoryItem) {\n ...inventoryItem,\n costDisplay: calculateCostForDisplay(inventoryItem);\n}\n\nfunction calculateCostForDisplay(inventoryItem) {\n let newCost;\n const order = lookupOrder(inventoryItem.get('order_id'));\n const currency = order.get('currency');\n // subsequent processing steps...\n return newCost;\n}\nIn a software system there are many floating nodes urged toward similar ends: teams, software that’s running, software that’s being worked on, etc… It hardly uncommon for both a front and back end team to write some code to solve a similar problem – what might even be a simple calculation – while totally blind to the other side tapping away. Frequent team project reassignments, geospatial and organizational distance, depth of expertise, weak cultural value around curious coding, etc… these types of contention costs create the regrettable complicatedness, the vivant natura, that results in risky duplications. Especially risky for inconsitencies that might develop inside essential software modules like pricing computations.
\nSupplemental thoughts from Coda Hale’s new blog post going around:
\n> Contention costs grow superlinearly as new members are added.
\n> Coherence costs grow quadratically as new members are added.
\n> Limit the number of people an individual needs to talk to in order to do their job to a constant factor.
\nI’m not sure I would have believed this type of thing would happen before I joined a larger company with an engineering group spread across geos; teams flung across the ownership matrix by the high winds of market shift. This investor and wall street casino shit drives tough team decisions. Lol team pet names: stunted protologisms. Like, what happened to the Squirrel team? Oh, they are the Crib Gto Pomp team now. Well, at least we are consistently circumlocutory at naming teams.
\nBut lo and behold, such an example like the above cost calculation exists. I saw something like it in our JavaScript code. Then I asked the folks who work on backend if the frontend really needed to be doing this work. We shouldn’t. We literally shouldn’t because the computation for this existed in our backend service already. This is one reason we can’t have nice things.
\nSo I’ve been thinking a lot about an approach to code, a kind of mental shim, to mitigate the coherence costs across the stack. Even with a fluctuating number of devs with knowledge about the code. Maybe we should just call this predicament patchy; patchy coding. Here’s what I’ve got so far with a cute story and real life examples:
\nAvoid duplicating code across the stack\n\nConsider the following scenario which is based on true events.\n\nOne day Team RocketShip is working on a feature for Big Initiative X. They implement some computational logic in Ticket Availability Service which adds a new attribute on TicketClass. The code is great, it ships, customers are elated. But soon after, Team SpaceShip is tasked with another piece of Big Initiative X and needs to display the result of similar computational logic in a React app. However, Team SpaceShip doesn't know about Team RocketShip's previous implementation in TAS, and they decide they can actually write this computational logic into the client code using existing TicketClass data. The code is great, it ships, customers are elated.\n\nUh oh. Now we have duplicate code on the backend and frontend. Which means code that is very likely to become out-of-sync and result in disruptive maintenance work or bugs in the future. But how do we avoid this situation? Unfortunately, this is one of those social (read: people) problems of software engineering. There's no way to reliably automate prevention with static analysis of the code.\n\nHeuristics:\n\n There > 1 attributes returned from the API that are similarly named\n Here's a real life example:\n TicketClass used to have attributes for auto_hide, hide, auto_hide_before, and auto_hide_after that client code in checkout utilized to compute the ticket's "hidden" status. In other words, client code asked of these associated attributes: should this ticket be unavailable for purchase. However, creating statically derived properties from a mixture of data may be an indication the backend can do this work for you, or already has.\n Ticket Availability Service already had code that computed this logic. Ultimately the frontend computation was replaced with a new attribute added to the TicketClass API.\n There > 1 attributes returned from the API that are related "communicationally," in that they reference similar types of data that are computed differently.\n Similar to the example above, the existence of auto_hide and hide attributes seem conceptually related – through "hide" – and can be a clue that there may be logic on the backend that could be reused to for hidden status calculation.\n I need a static value that won't be impacted by user behavior after first load\n\nMake the backend do the work\n\nHeuristics:\n\n Will the iOS and Android team's have to implement this too?\n Always remember that the desktop website is just one place where we write code for consumers of our applications. If the feature you are building will likely end up on a device, it's likely the backend code can expose what you need in the API.\nIn the most recent issue of JS Weekly, a new piece from Eric Elliot about optional values in JavaScript reminded of one of the first Lambda Cast episodes I listened. #6: Null and Friends. At that point in time I was near the start of my functional programming research and finishing Kyle Simpson’s Functional-Light JavaScript. During the podcast I was delightedly shocked to hear the hosts discuss functional languages that are actually designed to keep null out of your programs. I could feel myself pulled toward the FP language hype, especially if that hype was about solving the real-world unpleasantness of working with ambiguity in code.
\nBecause of JavaScript’s dynamic type system, optional values like null, undefined, or an empty string can easily make trouble in your software. The language lets us get away with saying I don’t know without any compose-time feedback. Therefore spinning up the browser and pushing play is often your only recourse to see how optionals are actually handled.
In his article, Elliot lists the common progenitors of null:
> 1. User input\n> 1. Database/network records\n> 1. Uninitialized state\n> 1. Functions which could return nothing
\nOh boy #3. I’ve got an example from the office, bear with me.
\nIn our Event management application there is a form field. This field represents a maximum limit on the number of holds for an event ticket. There are two types of input this field can receive from a user: 1) an integer or 2) nothing (ie, be left empty). The latter signifies that the user desires to unrestrict the number of holds.
\nNullable fields! These are quite commonplace and a user would never think twice about the dark alchemy we’re performing behind the scenes. What the user doesn’t know is that this field maps to a database columm that expects an integer (INT). Thus, when the user leaves the field empty and then submits the form, we need to make sure that an empty string is cast as a stringified representation of zero to slot in the POST body: {limit: 0}. Zero means unlimited. Leaving the field blank is not a lack, but bountiful! Nothing is not nothing. Logically sound, but conceptually wacky. A sensible default.
function serializeFormData(formData) {\n const limit = formData.limit || 0; // the empty input string is nullable!\n const nextField = //...\n const body = {\n limit,\n nextField,\n // ...\n }\n\n return body;\n}\nOf course, a reverse alchemy must occur from the other direction when our React code initializes the form to begin with. We first hand our form builder an empty object – key/value pairs with field names as keys and undefineds as values. The builder then converts these undefineds to appropriate defaults.
function getInitialFormData(initialData) {\n const limit = initialData.limit || '';\n const nextField = //...\n const initialFormData = {\n limit,\n nextField,\n // ...\n }\n\n return initialFormData;\n}\n\nLooks familiar.
\nThusly, the JavaScripter putzes around with a notion of nothingness by phase-shifting duck typed values.
\nnull <-> '' <-> 0
(There’s probably cooler mathematical notation for this.)
\nUnforch we have to use null and friends for lack of a better optional option. Like, for lack of formal invariants in-language. It’s impossible to truly prevent these meaningless nothings from entering our JavaScript programs. (Meaningless like may never receive meaning, ambiguous, undecided. Totally void 0: what a good euphemism from the grammar.) Like, you can’t serialize nothing for a value an API response formatted as JSON.
>>> json.dumps({name: }\n File "<stdin>", line 1\n json.dumps({name: }\n ^\nSyntaxError: invalid syntax\nOr try and stringify an Object back up again with the same:
>> JSON.stringify({name: })\nSyntaxError: expected expression, got '}'\nNull and undefined are optional in JS but they are not illegal. Like in Haskell, which wraps up the ambiguity in a fat Nothing.
Elliot does an interesting rhetorical jiu jitsu by giving us new options for optional values. In liue of eviscerating null from JS, we can work to push null to the edge of our programs with a handful of innovative approaches. In a sense we can ignore nullables and declutter areas of code which can just focus on data pipelining and other UI biz logic. Techniques include: constructing state machines – highly determined object interfaces – that error without values set to a wanted data type; ie something. We can also take advantage of that new new: Optional Chaining. And then there’s borrowing from FP. The last I love.
I’ve already been thinking about Maybes a lot recently. My last post was about using “maybe” in function names to negotiate the unrealistic binary of if/else with better signaling to other developers; like, a function may or may not complete it’s designated purpose if an async call fails or an argument is unacceptable. The real word is far too fuzzy. In contrast to the imperatives of JS, FP languages substitute nullable data with algebraic structures that encapsulate possibilities of existence or nothingness. For example, the actual Maybe data type represents either a Just (truth, success, completion) or Nothing (false, error, incompatibility). Data that’s wrapped in a Maybe and operated on won’t leak a nullable into our program, like the commonly observed undefined. Obviously implementations vary across libaries. Here’s a simple example from the Practica library which demonstrates the way that using Maybe can simplify code:
import { Maybe } from 'pratica';\n\nconst data = await fetchAllPeople(...);\n\nMaybe(data)\n .map(people => people.filter(person => person.cool))\n .map(people => people.map(getNames))\n .map(names => name.toUpperCase())\n .cata({\n Just: transformedData => render(transformedData),\n Nothing: () => console.log('Womp, no data returned from API.')\n })\n(Btw, “cata” stands for catamorphism and means to decompose the Maybe container into simple values. Honestly, I’m not good enough in the category theory yet to confidently distill it for you completely – pun intended – but that’s the gist.)
\nA more basic JS solution might look like:
\nconst data = await fetchAllPeople(...);\n\nif (data) {\n const coolPeople = people => people.filter(person => person.kind);\n\n if (coolPeople.length) {\n const formattedKindPeople = people => people.map(formatPersonForDisplay);\n render(formattedKindPeople)\n } else {\n console.log('Womp, only unkind people.')\n }\n} else {\n console.log('Womp, no data returned from API.')\n}\nThe combination of FP-style data pipelining – allowed by Maybe’s monadic interface, I think? – and control flow encapsulated in the data type itself, we get a semantically rich and easy-to-read solution without nullables and exhausting boilerplate; ie, param existence checks.
\nWhere Elliot really surprised me was drawing a line between FP’s similar-to-Maybe data type Either and JS’s Promise. Tucking null away with Promises is super neat. Let’s see how that plays out in a sec.
While maybes represent one or no value, Just or Nothing, Either implementations are slightly different in that they represent one or the other, but not both. If you’re familiar with bitwise XOR, it’s the same algorithm, except that in place of a Nothing or performing a noop, Eithers provide a secondary branch for an error case. Let’s see it in action.
\nTake Elliot’s example of a small abstraction that hides null checking away in a kind of promisified ternary (which I’ve slightly modified):
const exists = (x) => x !== null;\nconst ifExists = (value) =>\n exists(value)\n ? Promise.resolve(value)\n : Promise.reject(`Invalid prop: ${value}`);\n\nifExists(prop.name).then(renderName).catch(log);\nHere basic null checking and *primitive" if/else binaries are replaced with a more expressive, semantically rich statement for the logical disjunction: proceed this way if success, or that way.
\nNow, logging an error doesn’t get us very far from param checking and early returns. A slightly more interesting example might be something like:
\nconst inputExists = x => x !== '';\nconst ifInputExists = value => inputExists(value) ?\n Promise.resolve(value) :\n Promise.reject(`Input is blank`);\n\nonInput((prevValue, nextValue) =>\n ifInputExists(nextValue)\n .then(validate)\n .catch(trackClearInput(prevValue))\nIt’s hard to see the real power of this for a simple resolve/reject example. It just feels like a fancy if/else, right? But if we extrapolate from this base interesting things start to happen. Here’s a slightly modified version of an example from Practica’s docs with an imaginary Either that uses Promises under the hood and implements a chain behavior:
const isPerson = p => p.name && p.age\n ? Promise.resolve(p)\n : Promise.reject('Not a person')\n\nconst isOlderThan2 = p => p.age > 2\n ? Promise.resolve(p)\n : Promise.reject('Not older than 2')\n\nconst isJason = p => p.name === 'jason'\n ? Promise.resolve(p)\n : Promise.reject('Not jason')\n\nconst person = awaitfetchPerson(...);\n\nEither(person)\n .chain(isPerson)\n .chain(isOlderThan2)\n .chain(isJason)\n .then(p => console.log('this person satisfies all the checks'))\n .catch(msg => console.log(msg)); // if any checks reject, then this function will be called. If isPerson rejects, then isOlderThan2 and isJason functions won't even execute, and the err msg would be 'Not a person'\nSuffice to say I’m quite tickled by the re-purposing of Promises as Eithers. You can start to imagine how one might construct custom-fit control flow chains and layer cakes using thenable types to play nicely with other function composition and pipelining. I’m not always in love with (what feels like) sacrificed readability with chaining over stacked lines of assigned returns or async/await. But seeing it an action using Practica I’m starting to believe more and more in its viability, even in a codebase touched by less experienced or new developers.
\nGripes with FP readability aside, it’s eye-opening to look at available JS language features and see them in a different light. Also, aside from the clever use of Promises, just getting the null check into an abstraction exists(...) already has us using an FP mindset to build strong declarative (function-first) foundations.
Migrating my content from Medium was due, but this past week became a particularly opportune time to repost some old content on the subject of naming. Because I’m in one of those feels again, y’ll. And it’s about one of the two hard things enshrined by Phil Karlton. Really we just float in a crisis of language trying to speak correct enough to make some money. Between thought and action. Between computer and person. Between persons.
\nHow do I communicate to the next developer that this function might do one thing, or it might do another?
\nThe other day I’m refactoring some code and picking apart a function to understand how it works. Let’s call this function saveThing. It’s about 60 lines. Kinda medium-sized but a lot of lines are neat procedural steps of computation. The part that’s quizzical to me is a condition that will exit the function if the user is missing a permission. So…sometimes this function won’t save a thing.
This is FUNKY. I want to rename the function to maybeSaveThing because the steadfast verbiage seemed incorrect. Like, literally it was signaling something wrong to me about its gist. I think I may have been particularly sensitive because I had already spent two days refactoring a bunch of code in this area and was becoming a bit exasperated with various kinds of misdirection. I really wanted the code to start being straight with me. But it’s when we’re weakest that we need the code to be brutally honest. Fixing critical bugs. Nearing deadlines. When stuff’s happening at home. In the world. Ironically, these modes reveal the code’s honest readability.
But this could be a matter of style. I’m not sure. I’m mulling it over. I have colleagues who think maybeSaveThing isn’t really necessary. The internal conditional is obvious enough once you peer inside. I think I’m going to fight with them more about it.
I felt validated when a homie from a JS community I hang with on Slack gave me an example of production code from his place of work:
\ncomponentDidUpdate() {\n this.maybeRedirect();\n this.updateTitle();\n this.maybeDoActivation();\n this.maybeInjectSampleTimelineItems();\n},\nI LOVE this. Don’t you think it reads nicely? Like, you can really understand the sequence. The maybes communicate a true story of many possibilities. I’m imagining refactoring this component transition block. These function names are helping me decide what to care about now or later; to maybe deal with them or not.
\n", "date_published": "2019-11-18T15:11:00-07:00", "url": "https://softlydeveloping.micro.blog/2019/11/18/maybe-maybes.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2019/11/10/do-helper-for-emphasis-in.html", "title": "“do” helper for emphasis in variable naming", "content_html": "However you mental wrap the process of realizing virtual things (writing, accretion, rose gardening), there’s no question literary-ness does imprint at some point on IDE surfaces. In my experience working in the higher stories of the tower (cloudgineering, we so high): up there with web pages, casually cast instructions inRuby and JavaScript, cascades in hierarchical CSS computer notation, and declarative document formatters (XML, HTML); up here you’re definitely notating control flows and arguments that require semblances to English lang. Arguments. Computer languages.
\nThe other day I surprised myself by forming an excited opinion during code review about what a variable should be called. I guess the time had done arrived; I had spent just enough time in Ember and client state management to become OCD about the signifiers being passed around. And so I found myself feeling incomplete when I read over a line of code announcing a state change event that facetChanged. I can’t totally explain it but this wording felt insufficient. I instinctively wanted more. Needed surge troops. Something like…facetDidChange.
\nThe difference is slight, but important.
\n(It’s hard, y’all. One of two things.)
\nI researched the grammar to figure out why the variable was letting me down.
\nTurns out the “do” helping verb isn’t a special thing. But when added to another verb in the preterite, it increases emphatic assertion heaping deeper credibility on the thing that did happen. You can really feel it on your brain tongue, right? The additional slam ofd in the phrase, like doors shutting — the hardness more certain.
\nOr maybe the reassurance is there because of the influence of the black/southern dialect on modern American english; the Shakespearian-like emphasis where past finality is hammered home when something done happened, or 2x emphasized when someone done did.
\nThe code doth protest too much??
\nEh, I didn’t push for a rewrite in the code review. Naming is a bar brawl and sometimes you fight and sometimes you don’t. The author is balancing empathy for their colleagues with their own mental frame of the application at the moment they create the code; and then there are many an english word and conventional abbreviations, degrees of formality and tone. There’s a reason Steve McConnell dedicates 30 pages on The Power of Variable Names. And this section doesn’t even explicitly tackle naming receivers, subscribers, etc…
\nJust tryna make sense of what these users be doing.
\n", "date_published": "2019-11-10T15:10:00-07:00", "url": "https://softlydeveloping.micro.blog/2019/11/10/do-helper-for-emphasis-in.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2019/11/07/more-about-anointed-princes-and.html", "title": "More about anointed princes and gatekeeping culture", "content_html": "Ok, gonna brain dump a little because I got excited about some synergy! Maybe I’m just really starting to find some peeps in the trillicon valley zeitgeist.
\nGee Paw Hill published a blog a few days ago that retrospects on geek culture gatekeeping (I think we can basically proxy software industry for geek culture here). He presents this notion of our geek culture as “thin culture”; boundaried, exclusive. Lo and behold I was pleasantly surprised to see him use the phrase “anointed princes” to describe the folks – “they’re usually men” – who perpetrate the thinness. Yay because this is nearly identical language I used in my last post for analyzing the behavior I saw in some other internet writing that made me feel poopy. I feel validated.
\nFeels!
\nI like that he backtracks the finger-pointing though; like, a fire with fire counter is a non-helpful meanness here. But also, I’d argue some anger first is ok. “Anger is clarifying” – as Fleet Maull once told me many years ago. Or maybe a tool. Today during the Human Dimension of Business training at work we practiced the art of the rant – privately journal your story of blame – as a bridge step to toward truth and clarity; and as a way to measure and check our extra assumptions against the NVC-like framework (“The facts are…”, “I feel…”, etc…).
\nThere’s some interesting stuff in Gee Paw’s reflection. I feel armed with richer clues about where gatekeeping culture is inherited from, and inspired again to work with it in my own being.
\nLoneliness, isolation, computer as friend, for some of these guys. I mean these are kind of obvious origin story props that will perpetuate harm and abuse across generations. It also may be a narrative setup for geek thinness that Gee Paw warns us to see for fiction.
\nBut I think, bringing his frame of three gatekeeping behaviors that keep our culture narrowly defined – “badging, self-blindedness, atemporality” – to any reading or conversation with the anointed princes in our industry will likely save us from feelings of smallness. (Those of us who came in through the side door; ie not academia). And to my fellow white dudes, it will help us break the cycle of abuse.
\nLets freestyle this a little bit:
\nDispatch from Soekarno-Hatta International Airport.\nArrived way too early because of traffic fantasies.
\nWhile leafing through my daily software briefs I came across an article with that dissapointing refrain in our industry: this should be easy to do. There’s probably no better way to put a reader on the defensive and create an adversarial teaching situation. Suddenly I’m challenged to match the author’s intellectual prowess or else remain befuddled and continue writing shitty code. Why you fuckin with my head???
\nThe article is another offering to the OO world which introduces the dependency indirection “injectable factory” design pattern as a cure for “rigid direct dependencies” in unit tests. Super simple stuff.
\nAlso just LOL the indexical disambiguation science of the OO world. I’m just in love with Steve Yegge’s satire about this. A true kingdom of nouns. Frankly it’s a deliciously bookish world compared to JS-land where it’s function function function function.
\nIf I grokked it right, I think the article is just a way of instructing the use of mocks without dependency injection, helping you avoid writing a service implementation for your tests that looks like this:
\npublic class OrderServiceImpl implement OrderService {\n private final ShoppingCartService cartService;\n private final PricingService pricingService;\n private final InventoryService inventoryService;\n private final UserSession userSession;\n private final TimeProvider timeProvider;\n // ... and many more, this list will keep increasing when more requirements added\n\n public OrderService(\n ShoppingCartService cartService,\n PricingService pricingService,\n InventoryService inventoryService,\n UserSession userSession,\n TimeProvider timeProvider) {\n this.cartService = cartService;\n this.pricingService = pricingService;\n // ....\n }\n\n public CreateOrderResponse createOrder(CreateOrderRequest req) {\n // ...\n }\n}\nAh yeah that looks hairy. I’m flashing to Jest unit tests where small function implementation details are mocked all the way down.
\nI remember a moment, a phase if you will, in my first couple of years working professionally as a softwhere engineer when I thought that understanding OO design patterns was part of our right of passage into…seniority, I guess? At the time I was beginning to write more in the Rails parts of our codebase and as a consequence, began inheriting a pressure, a notion – from where I’m not sure – to achieve familiarity with common OO design patterns.
\nFrom where, indeed. It’s really subtle how this worldview is propogated amongst our ilk but I think I’m starting to see, with clear eyes, the quiet, viral expansion.
\nFor example, this digesis about “injectable factory” thats got me irked. When the author completes the situation and complication setup, he begins his solution section with:
\n> The pattern is pretty simple.
\nUmm great, so what you’re proposing is just a fancy name for something I probably already know about? But then:
\n> It’s implemented as a mutable value holder. This pattern is related to the factory, service locator, singleton pattern and ambient context pattern. All these patterns are considered anti-patterns according to most DI articles. But in practice, those patterns, especially singleton, are very handy and useful. They are prevalent in almost every non-trivial project. But they come with caveats. InjectableFactory tries to prevent those caveats at the same time keep the convenience and simplicity of those patterns.
\nIt’s so simple I just need to have a solid undertanding of these (what must be other simple) concepts as well:
\nI’m reminded of Rich Hickey’s 2012 Rails Conf talk where he disambiguates simple from easy which is a linguistic casuality which creates confusion in our industry about what “simple” or “easy” software really is or achieves. In the talk Hickey helps recoup a specificity for each word through an etymological tracing. Distilled you take away that simple is objective and easy is relativistic.
\nIn consideration of the foregoing, our Javian knight likely means easy, which, by Hickey’s redefinition (rather reinstatement of acuity), means a spacial relativism of nearness. As in easy to go to or get or near to our understanding. In other words familiar. Like a better developer experience. Like:
\n> …can I get this instantly and start running it in five seconds?
\nBut he probably also means “being near to our capabilities”, the promise of easy.
\nEven if the usage intent is closer to Hickey’s easy, what about this list of like seven things I need to know that may not be near my capabilities? Like, easy for whom? What type of reader is summoned here? Since the author never names his imagined reader/audience we’ll never know for sure, but we can infer it’s likely folks who are experts in OO and the Java lang. Perhaps that’s the transgression that bothers me. This invocation of simple to self anoint as meister amongst a court of meisters, but without warning patronizingly forecloses access for an unitiatied reader. I think this is the gatekeeping emerging, infectiously. Almost too quickly to observe. I’m really glad Hickey also finds circumscribing code as easy dangerous for our industry’s wellbeing:
\n> And we don’t like to talk about this because it makes us uncomfortable because what kind of capabilities are we talking about? If we’re talking about easy in the case of violin playing or piano playing or mountain climbing or something like that, well, you know, I don’t personally feel bad if I don’t play the violin well because I don’t play the violin at all.
\n> But the work that we’re in is conceptual work, so when we start talking about something being outside of our capability, well, you know, it really starts trampling on our egos in a big way. And so, you know, due to a combination of hubris and insecurity, we never really talk about whether or not something is outside of our capabilities. It ends up that it’s not so embarrassing after all because we don’t have tremendously divergent abilities in that area.
\nSigh. The deleterious effect of gatekeeping. Like is there some insecurity at play here for the author that requires he front his meisterness?
\nThough what if…I wonder if the author actually intended to describe injectable factory as simple by Hickey’s definition? As in, requiring less effort to “repurpose, substitute, move, combine, extend”, and less coupled (“interleaved”). The root of the word is one fold, braid, or twist. That does seem to be accomplished in the design. Nevertheless, I can’t get over the heavy connotation of reader culpability and capability implied in the (weak) qualification of “pretty simple.” Language is weird.
\nI’m thinking it’s probably best to avoid “simple” and “easy” in technical writing. Let’s not fuzzy match.
\nThis reminds of when the words good or bad are used when discussing code. Without more objective substance, simple evidence, they just do a big hand-wave over facts and truths of the software’s outcomes and the shared understanding of the folks in the conversation. Is the software reliable, easy to change? What level of expertise is required, what audience are you interpolating into this discourse of nouns?
\nIs simplicity achieved?:
\n> There are tons of libraries that look, oh, look, there’s different classes; there’s separate classes. They call each other in sort of these nice ways, right? Then you get out in the field and you’re like, oh, my God! This thing presumes that that thing never returns the number 17. What is that?
\nIs easiness achieved?:
\n> …can I get this instantly and start running it in five seconds?
\n", "date_published": "2019-10-10T01:00:00-07:00", "url": "https://softlydeveloping.micro.blog/2019/10/10/harmful-ways-to-write-about.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2019/10/06/a-better-term-for-unintentional.html", "title": "A better term for unintentional technical debt", "content_html": "The other day I got into a tiff with coworkers during our retro sailboat exercise, hunched over stickies and milling about thoughtfully. Abruptly, I leaped from my chair and smacked a note on the whiteboard: application too big. Did this qualify as technical debt, and therefore start in motion various debt protocols and procedures (tagging, itemizing, scoping, slotting, mapping…).
\nThe damned slice of monorepo which we had been toiling in since last sprint was damaging our pace with a super bloom of contributions from different teams. The code was getting hard to reason about, we were feeling immobile amidst the swarm; it was getting too complicated:
\n> It has many interconnected parts, each full of details. Conditionals abound, forming intricate rules that may surprise us when we read them.
\nLately I’d been thinking about debt as the future IOW on quality to increase speed in the present. A somewhat common definition. But that definition didn’t seem to characterize what I had slapped on the board. By that narrow definition, if this nuanced latticework were debt, we’d be able to rustle up the ledger, analyze the running amortization plan, protocls and procedures and so far and get eh work scheduled or assigned as noop or what-have-you. Yet, but nope, to think of complicated code emerging from a combination of variegated knowledge across teams, and the teleologic weight of entropy (bit rot, cruft, and so forth) – that didn’t situate in Cunningham’s metaphor for me. All this new code was showing up as a stunning kind of surprise not as a calculated tradeoff.
\nPerhaps other sources of debt people discuss could help us understand our current morass? Could it be situated as procrastination, not revisiting architecture, postponing test-writing? I don’t think so. I truly believe the teams working in this code were doing right by all these additions.
\nThen there’s the category of “unintentional” debt. But that still missed. There was an aspect of stuff out of our control but the intent/unintent dichotomy felt unsatisfying if do, in fact, believe that software is a rich system of people, code, automations, feedbacks…I don’t know. Language is hard. I guess I’m gliding at the edges of a linguistic constraint with the lexicon that was tossed around the table by my colleagues. Some sort of weak Sapir–Whorfian confusion that I couldn’t peak around.
\nNonetheless, I conceded to my fellow engineers – to wares that are soft:
\nok, fine, this debt that so cunningly creeped with bold surprise was, in fact, a (indefinite) form of technical debt
\nIn fact again, the frame I particularly appreciated was this: while it may not have been a result of a conscious decision, now that we observed this mucky muck we could choose to deal with it as debt. Ok, debt is debt whether it arrives by forethought or entropy.
\nLuckily, as I was catching up on my daily doses of software newsletters this morning, jessitron (who I can’t stop quoting) hyperlinked her latest blog to another post from the Atomist site that gives us what I think is a more accurate language for this very type of technical debt. Frankly, any optimistic (re)casting of language in our field is welcome; we’re so prone to a feeling of unfinished, incomplete, or overwhelmed, everything is fine (eh, nope).
\n> Technology drift is a form of technical debt that comes from progress. As our target architecture advances, it leaves a trail of projects in all its momentary incarnations. As repositories proliferate, the accumulation holds us back. We have many technologies and many versions of each. We have the risks of all of them.
\nTECHNICAL DRIFT
\nFuck yeah, let’s use that!
\n", "date_published": "2019-10-06T01:00:00-07:00", "url": "https://softlydeveloping.micro.blog/2019/10/06/a-better-term-for-unintentional.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2019/10/01/two-tales-of-binary-search.html", "title": "Two tales of Binary Search", "content_html": "I still have lingering rage from two years ago when an interviewer said to me: “I could probably implement this in about 20 minutes.” Seriously crushing words to utter offhand during a facetime code screen for someone who has been programming and building web apps professionally for 3+ years.
\nThe problem was something like find the nearest value to x in the array. I’m so bad at toy algorithm questions since I basically spent those first 3sh years smashing a ton of Rails and Ember into my brain and worked to be productive building more typical business app/e-commerce style UIs. I wasn’t a whiz at data traversal. More like a deep component interface expert. What else would you call it? Suffice to say a simple filter function at 0(n) time would satisfy the requirements. That is lived experience.
\nBut my interviewer pushed me to consider a big fat array. I was stumped, and failing hard in the spotlight. Only 20 minutes. Bro even let me spend some time after the interview coming up with a solution to email later, but that was futile. I didn’t even know how to properly phrase the problem for Google. I got rejected.
\nWhat I learned later is that bro was looking for a solution implementing binary search – something any CS grad would know. I didn’t have a CS background. I learned to program on the job and never had to care about that level of performance in the apps I worked on.
\nTo this day, around 6 years into my career, I haven’t had to implement a binary search algorithm to scan over a big data set.
\nJulia Evans put out a short series of zine pages recently that describe best practices for debugging. And guess who showed up? Binary search! Leaning back at my desk chair I realized that all along I’ve been using binary search in my every day work.
\nWhen fixing a bug without a useful stack trace, triangulating the problematic code requires what I used to think as a kind of cludgy technique: step by step, commenting out large parts of the code at the top and/or bottom of suspect files. Like, literally just comment out half the file where you think the buggy code lives. Does the error still throw? If yes, the problem is not in that half. Try commenting out the other half. If no, then keep halving that part of the file. Recursively repeat. This is binary search. Also, did you notice we’re now also talking about recursion, a topic that even senior programmers have trouble with?
\n“Advanced” CS concepts can show up in our work all the time. Whether it’s UI, backend, databases, ops, throughout all layers of this mushy cake stack. (“Mushy” as in blended, bleeding, fluid, transitional. Not as in gross, unfit, unstable.) We need to begin reconciling with the danger of narrowly defining their employ and weaponizing them in toy code examples for gatekeeping (cough cough interviewing).
\nWhen we learn the meaning behind these CS concepts, we may actually discover more creative ways to use them. Or how they are already part of our toolkit. For example, git-bisect!
\n", "date_published": "2019-10-01T01:00:00-07:00", "url": "https://softlydeveloping.micro.blog/2019/10/01/two-tales-of-binary-search.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2019/09/16/deeper-software-concepts-showing-up.html", "title": "Deeper software concepts showing up in UI problems", "content_html": "I’ve got three posts in my brain backlog now about more complex software concepts showing up in UI work. Here’s the first!
\nI’ve been waiting for years, thumbing a bitwise operator curiously. Finally the opportunity presented itself the other day.
\nWriting UI, most of the time the basic comparison and logical operators of JavaScript give us the power and control we need to deliver product requirements. Equal, not equal, AND, OR, NOT, etc.. But then there’s that arcane set of bitwise comparison operators. These special boolean operators give us expressiveness for more complex comparison scenarios. Their weirdness stems from the fact they do comparisons at the binary integral level. They coerce the values to bits first, far from view.
\nTake XOR – “exclusive OR”. In JavaScript XOR will return 1 when the output of either side of the operator is different, else 0. Similar to a boolean return, we can easily pass around the result of a bitwise operator as a predicate.
As it turns out, this happens to be the very logic we need for testing existence between two dependent form fields on the frontend.
\nAt Eventbrite, the UI library has graphical pickers for both date and time fields that we use in Event creation workflows. Our designs typically place these fields next to each other and make them required. We provide sensible defaults, but event creators can freely modify the values, unpredictably, even nulling them out. For example, it’s possible for the user to leave one field blank. We want to give event creator immediate feedback before they go on to other tasks on the page. If they put the form in this state, we run a validation on blur. And we can do it using XOR logic!
\nNevertheless, for checking existence, we don’t want to bitwise compare the two sides of the expression directly. These fields liberally capture data as strings (versus ints, datetime, etc…). To make the comparison reliable, we first cast each side to boolean values with using bangs for brevity. Then we wrap up the expression in a composable function. The result is a very concise one-liner:
\nconst isOneTruthyAndTheOtherNot = (a, b) => !a ^ !b;Which might be passed around in a hypothetical React event handler like:
\ndateTimeValidator: (dateValue, timeValue) => {\n const hasEmptyField = isOneTruthyAndTheOtherNot(dateValue, timeValue);\n const error = hasEmptyField ? FORM_ERRORS('dateTimeField') : null;\n\n this.setState({\n dateTimeFieldError: error\n }\n\n this.props.onError(error)\n}\nThis could be written in a couple ways without the more arcane XOR:
\n... = ( foo && !bar ) || ( !foo && bar );\n... = foo ? !bar : bar\nBut those expressions are tough to mentally load on glance. On the other hand, the bitwise operators are clever, but the single operator is a standard interface. Even a less experienced engineer can quickly reference the MDN docs which are crystal clear about how the XOR algorithm works:
\n> “Performs the XOR operation on each pair of bits. a XOR b yields 1 if a and b are different”
\nThe docs will also introduce you to the algorithmic decision table for the operator logic, which is a great learning device for engineers of all levels.
\n| a | b | a XOR b |\n| :-: | :-: | :-----: |\n| 0 | 0 | 0 |\n| 0 | 1 | 1 |\n| 1 | 0 | 1 |\n| 1 | 1 | 0 |\nWhat always makes this sort of exposé interesting to me is that we get a chance to trouble the early-web understanding of UI as document structure and style. There’s still too much emotional labor educating the web dev community about complexity throughout all layers of what’s becoming an increasingly mushy layer cake stack. Computer science in form logic. Like blended, bleeding, fluid, transitional. Not the pejorative gross, unfit, or unstable.
\n", "date_published": "2019-09-16T15:04:00-07:00", "url": "https://softlydeveloping.micro.blog/2019/09/16/deeper-software-concepts-showing-up.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2019/07/31/react-inline-function-gotcha-but.html", "title": "React inline function gotcha, but in a non-obvious way", "content_html": "I think a lot about Hillel Wayne’s blog post INSTRUCTIVE AND PERSUASIVE EXAMPLES: an interpolative critique of a best practice article on unit testing.
\nWayne argues that “instructive” examples don’t make a reader care. In contrast, we should labor harder to craft “persuasive” examples that attempt to satisfy simian desiring machines:
\n> 1. If your example is too simple, people brush it off.\n> 2. If your example is too complicated, people won’t follow. They’re also less likely - to trust it, because you complicated example might be concealing a simpler way.\n> 3. If your example is too abstract, people won’t see how it’s useful in practice.\n> 4. If your example is too concrete, people won’t see how it generalizes to their own - problems.
\nWe see examples of #1 and #4 all of the time in technical writing – maybe because a lot of it is written for marketing purposes.
\nExtrapolating Wayne’s plea: let’s be careful about how we present anti-patterns and best practices when we’re trying to thought leader. Often this writing ends up being spec or framework documentation plagiarized and adorned with gifs. But without contextual complexity we may be doing a disservice to our fellow humans who dev – especially less experienced devs.
\nPersuasive examples are harder but the payoff is bigger. By demonstrating the why and why not there’s a better chance of putting knowledge into your reader’s brain and making it stick. This is certainly my experience. If you:
\nTo wit. (An attempt at a persuasive example.)
\nJust this week I toiled on a bug with a colleague that ultimately turned out to be a case of a classic React anti-pattern where an inline function declaration caused undesirable re-renders of a Pure Component.
\nNow, I’ve definitely read at least a 3–4 instructive articles on the pitfalls of declaring functions inside of render(). Perf implications and unnecessary function creation, etc…. But that insight didn’t help me – or my similarly schooled – colleague come to resolution with any alacrity. We failed spectacularly to bring our academic rigor to bear because we weren’t working with sandboxed toy code from instructive examples. The root cause became obvious only after hours of thought-work finally revealed where the problem code even was.
Again, finding problematic inline functions in something like this triviality of Hillel’s lament would, of course, be much easier:
\nrender() {\n return (\n \n )\n}\nBut in our case, the problem function was buried in a nested component wrapped in a separate constructor function and abstracted into a separate helper in a separate file and blah dee blah…you get the point. Our journey was starting miles from render().
Our code better resembled:
\n// Template.js\nexport default (...props) => {\n // ...\n const Sidebar = connectSidebar(Sidebar);\n const Main = connectMain(Main);\n\n return ;\n}\n\n// Page.js\nimport Template from `./Template`;\n\nexport class Page extends Component {\n // ...\n render() {\n return (\n <- Template {...props} />\n )\n }\n}\nThe bug was observed when a user clicks the “Buy on Map” button in the Sidebar. The click was getting swallowed and not transitioning the view.
\nSo what was going on?
\nWhen we dug deeper we noticed that at the moment of click an unwanted blur event would be triggered on the form field in the <main></main> component; which would update its state. This redux-form state update would then ripple through the component tree and cause the sidebar to be re-rendered, even though none of the props passed to <sidebar></sidebar> had changed. The result was the sidebar button getting re-rendered in the middle of the click event; which meant the click handlers of the newly rendered button were not capturing the click and able to transition to the next view! Client concurrency issues.
![\"Inline](\"https://internetross.space/uploads/2020/57a595de41.jpg\" "\\"inline_gotcha_funtimes.jpg\\"")
One hack we considered was changing the onClick handler of the sidebar button to onMouseUp – the newly rendered button could seemingly receive that event just fine in the thrash sequence (browsers are weird). But we knew our bandage likely wouldn’t last long, o we decided to troubleshoot the real issue: the unnecessary re-renders of the sidebar upon field blur.
After binary searching the code up and down <page></page>, deleting chunk by chunk until the re-renders stopped, we discovered the fix to be fairly straight forward. Just move the invocation of connectSidebar and connectMain outside of the Template function context into the module context.
// Template.js\nconst Sidebar = connectSidebar(Sidebar);\nconst Main = connectMain(Main);\n\nexport default (...props) => {\n // ...\n return ;\n};\nAfter this mod, when <layout></layout> was rendered, the child component passed as the prop sidebar wouldn’t be invoked – it’s already been invoked and the return value of the component has been assigned. In other words, we are not creating a new function in memory and executing it fresh every time just like all those instructive examples say!
Sigh. We likely ended up in this place by not being careful with nested connectors and their subscription boundaries. Sometimes you forget that it’s just functions all the way down. Like, declaring and assigning a component constructor inside another component constructor would not be how you’d typically compose your functions. I will humbly accept this not uncommon (read: forgivable) symptom of “bottom-up” programming. (See David Kourshid’s talk about finite state machines and the sad stories of “bottom-up”).
\nIn sum, unlike the pristine nirvanic fields of instructive examples, we make our bed in large projects born from large organizations – cue Conway’s law. The requirements for the application accrete in fantastic ways over time. Cue McConnell’s oyster farms. The primitives you start with to satisfy embryonic requirements, like a root-level <page></page> component, may just become one large prop-drilled well. Graph hell.
This means you suddenly find yourself debugging why a click event on a sidebar button is being swallowed. You notice the divs are flashing in the Elements tab of Chrome dev tools, which means the browser is repainting the sidebar on click – re-renders!
\nOk, so instructive examples won’t necessarily help you. But I’ll add an asterisk and deign they aren’t worthless either. Because I’ve read these instructives, I am able identify and classify this bug post facto as a commonly known React problem – that is, a problem with React composition not a problem inherent to React – because the instructive examples are out there contouring a problem space and a shared vocabulary. I can then use this shared language when communicating the what or what caused this… during a retrospective or or incident report. Notwithstanding, we should endeavor to be better.
\n", "date_published": "2019-07-31T01:00:00-07:00", "url": "https://softlydeveloping.micro.blog/2019/07/31/react-inline-function-gotcha-but.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2019/07/13/closed-connections.html", "title": "499 closed connections", "content_html": "Bugs reveal. I look, observe. I learn things. I just experienced another one.
\nThe customer can’t publish. Ensue existential how come???
\nAfter poking around I noticed our client code was deleting a parent entity too eagerly during a fail case while create operations were in flight for hiearchically bound entities – too sanguine, our home-backd front-end ROLLBACK. If the parent save call failed, subsequent saves of child data would nevertheless proceed, leaving unhooked child data stranded in the db. When the user would later hit “Publish”, our system would crash, unable to reconcil the ill-begotten state.
Take a look at the code (simplified for example):
\n\nCan you see how this code was written a bit too simplistically? From what I can tell there are at least two latent problems that make this code prone to fail in a way we don’t want.
\nFirst, a parse error may be thrown during “other synchronous things” after the saveChildEntity promise is fulfilled. See a contrived example of that: async/await with synchronous error
Second, it’s possible that the POST request initiated by saveChildEntity may succeed on the backend and persist the child data, but the connection between browser and server may be severed before the browser recieves the 200 and the promise becomes fulfilled! When that happens, the promise is actually rejected and the runtime goes into the catch block.
In the end, it was the latter.
\nIt seems obvious in retrospect. We allow the user to hit Publish anytime which kicks off a heavy network sequence that finishes with a full page reload. Yet, while the publish sequence is in flight the user can still interact with the page. Meaning they could click another visible button – “Save” – that triggers saveStuffThunk. Based on the server logs, it seems that fairly often the Publish sequence would complete and then start to reload the page right in the middle of the second try/catch block of saveStuffThunk. When that happens nginx sends down a special 499 status code meaning the client closed the connection before the server responded with a request. The client code then interprets this as an error and sends the runtime into the catch-delete block.
The server logs (simplified):
\nIt still blows my mind this happened consistently to effect hundreds of records. The browser deterministically queues/coordinates? It was a very strange UX-driven race condition.
\nIn addition to realizing that our thunk code was written too optimistically, another aspect of this bug that fascinates me was the discovery that we had missed the really really important requirement of locking the page for the user when they click the “Publish” button. This was actually implemented for other similar interfaces, but when my team implemented a new screen with similar access to the “Publish” button, we didn’t fully understanding the potentiality of allowing this race condition. Or how to prevent it.
\nOrganizational debt becoming bug. A big complex system with fast-shifting pubertal code and fugitive ownership creating blind spots.
\n> “Every existing feature, and even past bugs, makes every new feature harder. Every user with expectations is a drag on change.” - jessitron
\nIt was a weird one but we observed some new things and thereby pushed our learning edge farther out.
\nLike, tangential learning came from investigating potential sources of 499s. While digging, folowing a hunch about the load balancers sitting in front of our API servers, I discovered that connections could be cancelled eagerly by such a load balancer upon a timeout. Because Publishing was a long-ish operation, at one point in the debugging adventure we surmised a heavy query might be exceeding the a timeout interval. See: Nginx 499 error codes. Nevertheless that was a false start; our ops folks were able to confirm we didn’t have load balancers managing these particular requests.
\nDemystifying architecture is an important part of this process for the perspicacious dev.
\nI’m just hard reflecting on how signals of “broken” – like bad data – can reveal many interesting things about the system. Just think about how much our client promise handling hid national treasures.
\n", "date_published": "2019-07-13T01:00:00-07:00", "url": "https://softlydeveloping.micro.blog/2019/07/13/closed-connections.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2019/06/24/debugging-a-test-that-does.html", "title": "Debugging a test that does nothing", "content_html": "This weekend I spotted Julia Evans posting tips about debugging – of course a zine quickly followed. This resonated deeeply because it touches on one aspect of debugging that I often struggle with. It’s comforting to know this is a common kind of struggle!
\n![](\"https://softlydeveloping.micro.blog/uploads/2026/e4cea74c97.jpg\")
\nWhat Evans articulates so well is how we are always standing in a muddy, vast ecology. When we sit down and begin to debug a single piece of a program we start by gathering all the things we think we know to be true. But we’re already at a loss. Our starting point is an incomplete, locally maximal set of facts about how the program should work based on a collection of initial assumptions from a limited field of reasoning. We’re fenced off, bounded.
\nAssumption is what makes the debugging process laborious. Each attempt to decipher error output or logs becomes a heated, lasting tango between your assumptive limit and proofs against the current reality. Herbert Simon, who coined the term “bounded rationality”, describes humans in this mode (quoting from Donella Meadows):
\n> blundering “satisficers,” attempting to meet (satisfy) our needs well enough (sufficiently) before moving on to the next decision. (p106, Thinking in Systems)
\nWhile this trial-and-error process ensues you begin to receive feedback, often surprising, which may cause your steps to travel different hypotheses. Or it may require a pause in the action when you cancel one idea and foreclose the set of possibilities; though bounded, you are not entirely helpless. You unlearn, go back, change course. The tango lasts.
\nAlso…
\nIt’s impossible to throw out all we know at the beginning and re-interrogate every line of code.
\n> …you just have to pick one and start checking.
\nPatience is what we need, as we methodically unpack our worldview from the inside out.
\nThis past week I spent a good part of two days wrestling with a broken acceptance test in a somewhat unfamiliar part of code. My initial assumptions misled me from the start.
\nThe test was written to observe a state change by simulating a click on the first menu item in a dropdown, which would flip the disabled state of a Purchase Button elsewhere in the container component. That assertion was no longer passing. Because my new code had changed the source of the the initial values for the dropdown, I had set my sights on determining if that source data in the test was wrong.
\nSigh, that was an incorrect assumption. I spent a bunch of time interrogating these source values in the test setup for the dropdown menu but in the end they were correct – my initial presumption and assumption (worldview) steering me into a void. Sucked.
\nAfter repeatedly playing with the test instructions and comparing to the outcome in the browser, I discovered the click action was doing nothing because the initial state for the Purchase Button was already set through a test setup step which equaled the first value of the dropdown menu; so the click action didn’t actually change the value in the test (I was finally able to repro this in the browser). There was no state change to observe. In fact, and this is the best part, the test wasn’t needed at all. My code change inadvertently exposed a test that was applying false assumptions to the code.
\nLol, how much of our software is layer cakes of fallacious worldviews???
\n", "date_published": "2019-06-24T01:00:00-07:00", "url": "https://softlydeveloping.micro.blog/2019/06/24/debugging-a-test-that-does.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2019/06/19/precrude-development.html", "title": "Pre-crude development", "content_html": "I caught this tweet by Ruth Malan yesterday. It’s a wonderful reminder about the tension between continuous evolution and product instability in software development.
\n> But like putting “product stability” in tension with “continuous evolution” is a very (relevant) “today” recognition. For example, if we keep changing a complex dashboard UI, we frustrate users (perpetual learning curve/adaptation pushed onto them) and it may even be unsafe…
\nAre you having a Val Garland DING DONG moment? It truly is a daily battle attempting to sit comfortably in this oversized chair, right? Like, certainly not a quotidian gracelessness I was prepared for at the start of my career. Back then I imagined long-lived codebases more manicured and predictable than the embryonic Rails app I would find myself working on in my first software job. Presently I’m working in a legacy codebase (like 10+ years running, ancient in software years), and I’m not really sure if it’s much more stable than that 3 year-old startup experiment. Sure, there are ignorable fossilized bits in corner tar pits that have run largely unattended for years; and quite elegant code abounds; it’s a mixed bag. Nonetheless, I often find myself in labored negotiation with the code in-between those ends, in that muddy mix; code that’s branched and maundered, complected semi-recently, as well as pubescent new growth. We might call this code pre-crude pressurized compounds with some new raw material shoveled in – does code storm, form, norm?1 These are tension points where I struggle the most. There are just enough layers of abstraction, code reuse, shared responsibility, etc… – tensile strength – that don’t make changing the code easy. Any change could destabilize things, like expose bugs, ie break existing functionality.
\nThe day-to-day discipline of working with legacy code is wiggling in tension, but also support all existing behavior. jessitron quotes in a recent blog:
\n> Every new feature comes with the invisible requirement: “and everything else still works.”
\nThis is a wild task in pre-crude places!
\n[1]: en.wikipedia.org/wiki/Tuckman's_stages_of_group_development
\n", "date_published": "2019-06-19T00:00:00-07:00", "url": "https://softlydeveloping.micro.blog/2019/06/19/precrude-development.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2019/05/11/too-many-imports-eyes-tired.html", "title": "Too many imports, eyes tired", "content_html": "There are too many imports in this React component file. I’m staring down like 50 lines of imports. External libraries (React, Lodash, etc…), our own internal libraries, components files, helpers, constants. The last bothers me the most because they feel like implementation details I want hidden away in these other components or helpers. So I’m looking at this statement inside a render() block:
\nconst isSoldOut = this.props.statusType == SOLD_OUT;\n\nAnd suddenly I’m reminded of what Kyle Simpson told me on twitter a couple weeks ago:
\n> “in ‘functional programming,’ we love and embrace functions! functions everywhere!” – @getify
\nThat’s it, that’s my out. We can refactor the equality expression into a function that represents data:
\n\nconst isSoldOut = ({ status }) => status === SOLD_OUT;\n\nWe might find our code getting repetitive for computing different statuses:
\n\nconst isSoldOut = ({ status }) => status === SOLD_OUT;\nconst isAvailable = ({ status }) => status !== UNAVAILABLE && status !== SOLD_OUT; \nconst isUnavailable = ({ status }) => status !== UNAVAILABLE; \n// etc...\n\nIn which case we might find an indirection at a higher level that hides the implementation details of our equality expressions:
\n\nconst getTicketStatusType = (ticketProps) => STATUS_TYPES_MAP[get(ticketProps, \"status\")];\n\nSTATUS_TYPES_MAP could implement an object hash where the equality expressions are values or our data functions.
This post almost became about mitigating import noise. But exploratory development while waxing with words wandered a bit. This is my day writing code in a nutshell – felicitous detours. Refactoring constants used for direct comparison into a reusable module. At the least those status constants can live in this new module. Nevertheless, the abstraction work yields other interesting propositions:
\nThat last point is important. At least to me. Untidy render() blocks are hard to scan, debug, and test. The machinations for constructing and composing the things to render can happen in other places: above the component class definition, in class methods, or in a separate file. The first options is one I quite like because abstractions don’t have to be all that general. It’s great if they are localized to the component at hand.
There’s always heated babbling (err…babeling) on the cyberspace to assign metaphor to our embryonic field of building digital things: writing or engineering or accretion. One thing for sure, humans have a religious proclivity to conquistador in the bikeshed when faced with terra incognita. Perhaps, ironically, because it’s something of a science and therefore seems to ask for a pinning down. But these guys, some of us, just seem unable to leave it alone to variance; to let it lie under a broad, mercurial atmospheric plane of something like creating.
\nI remember when I attended my first Railsconf in 2014. In the opening keynote DHH made a todo about software writing (and more famously that TDD was dead).
\nHello, World!
\nFucking comma in there. You have an author-face.
\nAt that time, 2014 in Chi-city (my place of birth), I was too green building product to really care what you called what I was doing. (Maybe I’ll never actually care that much.) It wouldn’t have helped me get a quicker handle on the revealing module pattern.
\nAnd then, a couple days later in the closing keynote, Aaron Patterson rebukes the writing metaphor and talks about the advanced engineering of improving Rails 4 query performance. Did they do that on purpose?
\nWhat’s in a name? Sigh, we don’t have the luxury of poetic soliloquy when getting business done and keeping this company afloat. Shitty code smells like shit no matter what you call it. I’m not gonna care too much for now what the pontificators put on the LHS.
\n- <-{@