In 2015 I bought this book. 7, or 8 years ago. Year one into my software career. This book is canon. I've had little use for its studies of algorithms. # thus far, see below I don't think Bentley would be offended. First sentence: "Computer programming has many faces." I’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.
> 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.
Boundary cross. Sex.
From a small heap software that helps make software. By way of Devine Lu Linvega
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):
> DEI is seen by a sizable chunk of the funder class as an allowable luxury to keep the peons happy.
Documentation, naming things. Hard. Let’s see this hardness compound at the intersection of these two phenomena in the real world.
I’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.
The 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?).
Nonetheless, 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.
There exist happy little clouds of coincidence when studying new languages. And not just across the computer ones, mind you!
Ruby and Indonesian share a frugal brevity and disinterest in flairs of punctuation when managing possession.
Itu bukuku. vs
That's my book. And…
me = Person.find(my_user_id) my_books = me.books vs
const me = await prisma.user.findUnique({ where: { id: 99, }, include: { books: true } }); myBooks = me.books; Well, Rails AR query syntax vs Prisma (NodeJS).
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.
My 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.
Recreating a lazy-evaluated let-style block in JS, Hicks performs some clever scoping gymnastics which makes me nervous.
Another world is possible. But what of worlding? How to world?
When 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!
Per 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?
There are so many goodies in Naur, 1985. Filter, some():
Declares there’s no right way to write software (Further) rebukes the scientific method Calls out lack of empirical study of software methods The programmer as “manager” of computer activity Thank you ceejbot for further distillations.
The year is 1985. Certain kinds of optimism abound in programming circles. From Peter Naur’s Programming as Theory Building:
"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." 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.
During her novel workshop on estate planning, Sarah Deluca of Move Money Shift Power poses the question:
Is holding onto control after your death something you want?
If 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.
No. You can’t. Not yet.
It’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.
The way she caresses the monitor in this scene: longingly, tenderly, expectant. The arrogant gush of buzzwords. Unalloyed after school cool.
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.
Pennies per day (by day count) in Clojure:
(defn pennyPerDay [numDays] (reduce + (range 1 (+ numDays 1))) ) (pennyPerDay 30) Pennies per day (by day count) in JS:
function pennyPerDay(numDays) { return Array(++numDays) .fill(0) .reduce((sum, _, i) => sum + i, 0); } pennyPerDay(30); Most frequent terms in JS:
const termList = ['term1', 'term2', 'term3', 'term3']; function mostFrequentTerms(arr) { return arr.reduce((result, curr) => { result[curr] = ++result[curr] || 1 return result; }, {}) } mostFrequentTerms(termList); Most frequent terms in a list with Clojure:
Not 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:
> 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.
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.
Math 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).
Femi Ogunbanjo & Hanne Klintoe, 1999, The Loss of Sexual Innocence Back 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.
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.
> …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. > > Software Development and Reality Construction > Ch 5.1: The Denial of Error, Joseph A Goguen
The 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.
Hannah Höch, Für ein Fest gemacht (Made for a Party), 1936 Collage 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.
function List({ items }) { return items.map((item) => ( {item.name} {item.children && } )); }
Each 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:
“It’s a function that calls itself.” “You make your list of tasks first then start from the last and work your way back up” or “It’s like unpacking a box with other, smaller boxes, with other smaller boxes, with other…and then only start looking at the boxes from the smallest to the largest, one at a time” (🎩👌 Aditya Bhargava’s grokking algorithms) “It’s good for building up a list or value, kind of like reduce” “It can be less code but less performant.
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.
I 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.
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.
Yesterday I was running through a block of questions with an ex-colleague and we noticed that some of the answers were a bit inchoate.
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.