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.