Reading Notes, June 2021
Article: âAre you still there?â by Nicholas Carr
In a few years, all new TVs will have operational cameras. All new TVs will watch the watcher. This will be pitched as an attractive new feature. Weâll be told that, thanks to the embedded cameras and their facial-recognition capabilities, televisions will henceforth be able to tailor content to individual viewers automatically. TVs will know whoâs on the couch without having to ask. More than that, televisions will be able to detect medical and criminal events in the home and alert the appropriate authorities. Televisions will begin to save lives, just as watches and phones and doorbells already do. It will feel comforting to know that our TVs are watching over us. What good is a TV that canât see?
Weâll be the show then. Weâll be the show that watches the show. Weâll be the show that watches the show that watches the show.
Nicholas Carrâalways on point.
the operators of the machines that gather our signals. Weâre the sites out of which industrial inputs are extracted, little seams in the universal data mine. But unlike mineral deposits, we continuously replenish our supply. The more weâre tapped, the more we produce.
The game continues. My smart TV tells me the precise velocity and trajectory of every pitch [in baseball]. To know is to measure, to measure is to know. As the system incorporates me into its workings, it also seeks to impose on me its point of view. It wants me to see the game â to see the world, to see myself â as a stream of discrete, machine-readable signals.
I sometimes despise that, on the web, weâve come to accept this premiseâto know is to measure, to measure is to know. As if what cannot be measured does not exist. Pic or it didnât happen. Tree witnessed or it didnât fall. Feedback or flatline.
Article: âLooping over Arrays: for vs. for-in vs. .forEach() vs. for-ofâ
Iâve always wondered about for
and for-in
and foreach
and for-of
. Through my own trial and error, my perception has become:
for
is old school, what I learned in computer science 101forEach
is what Iâll use most of the time, except when doing async stuff becauseawait
doesnât work inside itfor-in
I use for asyncâor wait, should that befor-of
? Meh, Iâll just useawait Promise.all
.
The lazy person in me finally gets to understand all the fors. Now weâll just see if I can remember it.
Article: â#162: Minimum Viable Selfâ
The personal brand, that groan-inducing pillar of digital existence
âGroan-inducingââjust love that description of the personal brand.
Offline we exist by default; online we have to post our way into selfhood. Reality, as Philip K. Dick said, is that which doesnât go away when you stop believing in it, and while the digital and physical worlds may be converging as a hybridized domain of lived experience and outward perception, our own sustained presence as individuals is the quality that distinguishes the two.
Article: âLink to downloadâ
Content-Disposition
headerdownload
attributeblob:
anddata:
A concise summary of how to get the browser to download things. I've used the blob:
one before. Itâs a rather neat trick for downloading files.
Article: âDoing the right thing for the wrong reasonsâ
Itâs one thing for a department to over-ride UX concerns, but I bet theyâd think twice about jeopardising the siteâs ranking with Google.
This resonates in my bones.
Article: âDonât Feed the Thought Leadersâ
Create an extended product roadmap and put those items at least a year off into the future âand as long as they donât seem relevant, you can just keep pushing them into the future.â Perversely this plan made everyone happy â everyoneâs feedback is on the roadmap, and now itâs all just a question of priorities.
Seemingly perverse, yes. Useful? Also yes.
Roadmaps have use beyond 6-week priorities. Sometimes you have to bring people along for the ride, giving acknowledgement to their voice even though you never plan to act on it.
The problem with all the bad advice was that it was unrelated to the problem we were trying to solveâŚ
The solution to every problem canât be the same
Boom!
The solution to every problem canât be the same? Try telling that to a framework.
Uncontingent advice is what I think of when I hear the term thought-leader - someone has a single solution that seems to fit every problem. Whatever problem you face, the answer is test-driven development or stream architectures or being-really-truly-agile.
I get frustrated by advice like that but is it wrong? Unit testing, streaming architectures, agile are all good things.
Itâs a good point. Itâs usually good advice. But itâs not always pertinent advice given constraints like resourcing, time, ambitions, goals, etc.
One way to think about advice is as a prediction. Advocating for TDD can be viewed as a prediction that if you donât write tests before you write code, your project will be less well-designed and harder to maintain.
Good observation. Advice is prediction. Do x
and youâll get y
. Itâs risk mitigation.
Software development is full of confident forecasters. We are a pretty new field, and yet everyone seems so sure that they have the best solution to whatever problem is at hand.
The proverbial âsilver bulletâ.
A great tool is not a universal tool itâs a tool well suited to a specific problem.
So whatâs the takeaway?
The more universal a solution someone claims to have to whatever software engineering problem exists, and the more confident they are that it is a fully generalized solution, the more you should question them. The more specific and contingent the advice - the more someone says âit dependsâ⌠the more likely they are to be leading you in the right direction. At least thatâs what I have found.