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.)
> “…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.
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
I’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
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.
Lately 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.
About 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.
> Women are a very recent invention. > > Ursula K. Le Guinn, The Wave in the Mind
Or, rather, reinvented since they had been denied participation in Western STEM since at least the middle 1700s:
At 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.
Here’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.
In 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.
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.
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.
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.
Gee 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.
Dispatch from Soekarno-Hatta International Airport. Arrived way too early because of traffic fantasies.
While 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.
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…).
The 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.
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.
The 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’ve got three posts in my brain backlog now about more complex software concepts showing up in UI work. Here’s the first!
I’ve been waiting for years, thumbing a bitwise operator curiously. Finally the opportunity presented itself the other day.
Writing 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.
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.
Wayne 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:
> 1. If your example is too simple, people brush it off. > 2. If your example is too complicated, people won’t follow.
Bugs reveal. I look, observe. I learn things. I just experienced another one.
The customer can’t publish. Ensue existential how come???
After 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.
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!
What 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.
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.
> 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…
Are you having a Val Garland DING DONG moment?
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:
const isSoldOut = this.props.statusType == SOLD_OUT; And suddenly I’m reminded of what Kyle Simpson told me on twitter a couple weeks ago:
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.