dce/davideisinger.com
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Ship dispatch 6

Browse Source
This commit is contained in:
David Eisinger
2023-08-06 22:23:04 -04:00
parent df24492a6f
commit fc0bb6ace0
5 changed files with 1398 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

81
content/journal/dispatch-6-august-2023/index.md
View File

@@ -1,71 +1,86 @@
---
title: "Dispatch #6 (August 2023)"
date: 2023-08-05T12:00:00-04:00
date: 2023-08-06T12:00:00-04:00
draft: false
tags:
- dispatch
references:
- title: "Why I don't use Copilot"
url: https://inkdroid.org/2023/06/04/copilot/
date: 2023-08-07T02:20:18Z
file: inkdroid-org-belior.txt
- title: "Phase change"
url: https://www.robinsloan.com/lab/phase-change/
date: 2023-08-07T02:20:18Z
file: www-robinsloan-com-sbm0vr.txt
- title: "The looming demise of the 10x developer: Why an era of enthusiast programmers is coming to an end"
url: https://blog.testdouble.com/posts/2023-07-12-the-looming-demise-of-the-10x-developer/
date: 2023-08-07T02:20:19Z
file: blog-testdouble-com-krzanb.txt
- title: "Daily notes for 2023-07-17 | Yes, Mike will do."
url: https://mike.puddingtime.org/posts/2023-07-17-daily-notes/#notes-on-conflict
date: 2023-08-07T02:20:20Z
file: mike-puddingtime-org-svf0ua.txt
---
Some thoughts here...
Nice to have a quieter month, though we still managed to spend a weekend at Lake Norman and took Nev on her first camping trip at [Carolina Hemlocks Recreation Area][1]. We also had a nice visit from my folks to celebrate my mom's birthday.
<!--more-->
* Lake
* Visit from my parents
* Camping @ [Carolina Hemlocks Recreation Area][1]
<div class="image-set">
{{<thumbnail 05569D5B "400x" />}}
{{<thumbnail DBCE9DD4 "400x" />}}
</div>
Tech-wise, I switched from Vim to [Helix][2], which I've detailed [over here][3]. I was also able to work through a whole bunch of the [Go track on Exercism][4] -- it's a good way to get a handle on the basics of a language, but doesn't cover using third-party packages, organizing large codebases, etc. To get that kind of experience, I'm going to try my hand at an app for fantasy sports drafts -- take a set of player projections and a scoring formula, and output a UI I can use during a live online draft. I've been doing this with spreadsheets for years, and it's pretty cumbersome. I'm going to use TOML for configuration, SQLite for data persistence, and [Bubble Tea][5] for the UI itself. We'll see how it goes!
I've signed up for the [Bull City Race Fest][6] half-marathon in October. Training starts ... tomorrow. I'm going to try to mix in some better eating habits + cross-training this time.
[1]: https://www.recreation.gov/camping/campgrounds/233954
* Go
* Did Exercisms
* Fantasy draft TUI app in Go
* Did a bike ride
* Am I running a half-marathon this fall?
* **YES** -- [Bull City Race Fest][2]
[2]: https://capstoneraces.com/bull-city-race-fest/
[2]: https://helix-editor.com/
[3]: /journal/a-month-with-helix
[4]: https://exercism.org/tracks/go
[5]: https://github.com/charmbracelet/bubbletea
[6]: https://capstoneraces.com/bull-city-race-fest/
This month:
* Adventure:
* Project: Fantasy draft TUI app
* [Bubble Tea][3]
* Skill:
[3]: https://github.com/charmbracelet/bubbletea
* Adventure: spending a weekend at Virginia's Eastern Shore with some childhood friends and a week at the beach with my family
* Project: build a fantasy draft <abbr title="text-based user interface">TUI</abbr> app in Go using [Bubble Tea][5]
* Skill: learn how to organize a larger Go codebase as part of ☝️
Reading:
* Fiction: [_Title_][4], Author
* Non-fiction: [_The Creative Programmer_][5], [Wouter Groeneveld][6]
* Fiction: [_Tress of the Emerald Sea_][7], Brandon Sanderson
* Non-fiction: [_The Creative Programmer_][8], [Wouter Groeneveld][9]
[4]: https://bookshop.org/
[5]: https://www.manning.com/books/the-creative-programmer
[6]: https://brainbaking.com/
[7]: https://www.brandonsanderson.com/standalones-cosmere/#TRESS
[8]: https://www.manning.com/books/the-creative-programmer
[9]: https://brainbaking.com/
Links:
* [Why I don't use Copilot][7]
* [Why I don't use Copilot][10]
> I enjoy programming because it’s about reasoning, thinking, models, concepts, expression, communication, ethics, reading, learning, making, and process. It’s an art and a practice that is best done with other people.
>
> Increasingly I think it’s imperative for programming to be done more slowly, more deliberatively, and as part of more conversations with more people. The furious automation of everything is eating the world.
* [Phase change][8]
* [Phase change][11]
> *What could I do with a universal function — a tool for turning just about any X into just about any Y with plain language instructions?*
>
> I don’t pose that question with any sense of wide-eyed expectation; a reason­able answer might be, *eh, nothing much*. Not every­thing in the world depends on the trans­for­ma­tion of symbols. But I think that IS the question, and I think it takes some legit­i­mate work, some strenuous imagination, to push yourself to believe it really will be “just about any X” into “just about any Y”.
* [The looming demise of the 10x developer: Why an era of enthusiast programmers is coming to an end][9]
* [The looming demise of the 10x developer: Why an era of enthusiast programmers is coming to an end][12]
> That is to say, I’ve come to believe the era typified by the enthusiast programmer—autodidactic, obsessive, and antisocial—is drawing to a close.
* [Notes on Conflict | Yes, Mike will do.][10]
* [Notes on Conflict | Yes, Mike will do.][13]
> Over time I shifted on the matter a little, but when I look back on it I realize I wasn’t really evolving my attitude toward conflict, I was just evolving my response to its existence, while still believing that being in a state of conflict is a problem. I just got better at keeping my blood pressure low and gritting through it. I think I was looking at conflict as a thing that you have to acknowledge exists, but that you need to get through as quickly as possible, because it’s a bad place to be.
[7]: https://inkdroid.org/2023/06/04/copilot/
[8]: https://www.robinsloan.com/lab/phase-change/
[9]: https://blog.testdouble.com/posts/2023-07-12-the-looming-demise-of-the-10x-developer/
[10]: https://mike.puddingtime.org/posts/2023-07-17-daily-notes/#notes-on-conflict
[10]: https://inkdroid.org/2023/06/04/copilot/
[11]: https://www.robinsloan.com/lab/phase-change/
[12]: https://blog.testdouble.com/posts/2023-07-12-the-looming-demise-of-the-10x-developer/
[13]: https://mike.puddingtime.org/posts/2023-07-17-daily-notes/#notes-on-conflict

641
static/archive/blog-testdouble-com-krzanb.txt Normal file
View File

@@ -0,0 +1,641 @@
[1]Test Double The Test Double logo
Menu
(BUTTON) Menu Menu An icon that displays an illustration of a website
menu
* [2]Home
* [3]Agency
* [4]Services
* [5]Careers
* [6]Blog
* [7]Contact
[8]Blog [9]Posts
The looming demise of the 10x developer
Why an era of enthusiast programmers is coming to an end
An icon of a clock Publish Date
July 12, 2023
An icon of a human figure Authors
[10]Justin Searls
I’ve recently been telling anyone who will listen that I am excited to
be on the precipice of using [11]Sorbet to write a type-checked edition
of [12]Mocktail that has the potential to unlock productivity workflows
never before possible in Ruby.
I’m not there yet.
I don’t want to say it’s been a “quagmire,” but I’m over [13]150
commits in, and there’s a lot left to button up before release. It’s
been a real challenge. Learning Sorbet at all takes a good chunk of
time, to be sure. I’ve also hit a number of thorny edge cases and
elusive bugs along the way (both in the type system itself and that the
type system exposed in my code). And, like usual, I’m trying to do
something that’s never quite been done before, so I’m constantly
oscillating between feelings of nervous excitement and fear that I’m
attempting the impossible. (Though it’s been made far more possible
thanks to the generous assistance of [14]Ufuk Kayserilioglu, [15]Kevin
Newton, and [16]Jake Zimmerman!)
Beyond this, any specifics I might share about my current quest are so
banal as to not be worth your time. (If you somehow find this
interesting, please [17]email me so I might feel less alone in this
world.) That said, there is something generally interesting here that
programmers don’t often talk about. And that’s the deeper question: why
do I keep doing this to myself?
[18]What makes me “special”
I am an enthusiast programmer.
I stumble on a problem like this one and I stay up late every night
until I find the solution. I wake up early each morning with new ideas
of things to try. I don’t take enough breaks, but when I do, they’re
tactically-designed to exploit my brain’s asynchronous processor to
generate solutions for whatever I’m currently stuck on. I irresponsibly
defer responsibilities from other areas of my life. Eventually, I
realize I’m only at the 20% mark and that a pattern is repeating where
a month or more of my life is about to disappear from the calendar.
Towards the end, I find myself rushing to find the maze’s exit because
my desire to unlock the puzzle’s final secret starts to be overtaken by
the shame of all the other balls I’m dropping. It’s excruciating as I
approach that inflection point—as intense as an overbearing manager’s
“do or die” deadlines ever were, except in this case the pressure I
feel is entirely self-imposed.
And then, at some uneventful moment at 4 pm on a Sunday, it’s done.
Sometimes people care about what I made. Usually they don’t. Often,
even I don’t.
I give myself enough time to clear my inbox, tidy the house, and shave.
Then I move onto the next Sisyphean task I’ve laid before myself.
This describes how I’ve lived my life since I was 13 years old, with
few exceptions. And let me tell you, it’s very difficult to juggle a
healthy personal life and a sustainable work life when you’re
simultaneously engulfed in an endless series of side quests to will
every creative curiosity into existence.
When I was a consultant at [19]Crowe, there was one year I billed
clients for nearly 2100 hours, which averages out to more than 40 hours
per week every week of the year with zero days off. And that’s not
counting travel time. Or the half-dozen hours of weekly administrative
work that wasn’t considered billable. Nevertheless, I found time in my
nights and weekends that year to build an app with Apple’s buggy,
mostly-undocumented initial iPhone SDK. The app was a native client to
[20]vBulletin web forums, allowing users to browse threads and compose
replies. Despite knowing nothing about any of the underlying
technologies, I obsessively polished the app to perfection. Did I make
time to sleep? I don’t remember. The whole year’s a blur.
All so that Apple could reject my app because users might post swear
words or dirty pictures. Oh, well. Onto the next thing.
I don’t know what word best describes my behavior above without
inflecting significant value judgment. Perfectionist? Obsessive?
Passionate? Whatever we call this compulsion, it’s hardly an unalloyed
good and it comes with its share of downsides. Nevertheless, it’s one
of a number of idiosyncrasies and character flaws I’ve decided to lean
into and find productive outlets for rather than attempting to repress
or rewire.
Other examples:
* I ruminate endlessly under stress, so I wrest back some control by
manufacturing stress responses over things I’m building to trick my
brain into ruminating on work that’s useful to me. This both
overrides the unhelpful, irrational worries that surround me every
day and unlocks a “second shift” where I accomplish almost as much
away from the keyboard as in front of it
* I’m a terrible listener and struggle with auditory processing,
especially in groups and loud environments. (One reason I talk so
much is that it’s always felt safer to drive the conversation than
risk mishearing and offending someone.) Parsing others’ sentences
often feels like I’m filling in the blanks to make sense of them,
like playing a game of [21]Mad Libs. Over the years, I’ve
redirected this into a source of creativity and humor. Most of my
puns and wordplay are happy accidents as I fill in the gaps in my
own listening comprehension. Some of my most creative ideas are
things I swear I heard someone say when it turns out they were
actually talking about something else
* I’m a really bad learner—disinterested, distractible, and
disagreeable. I’ve never enjoyed learning and generally avoid it,
especially learning for its own sake. At the slightest discomfort
when struggling to understand something, I’ll grasp for any
distraction that might offer me a momentary escape. When I do
manage to get traction, I inevitably find myself disagreeing with
the premise or subversively trying to prove the authors wrong. The
upshot is that once I actually do learn something, I know it cold.
It means I will have scoured every nook and climbed out of every
pitfall. Professionally, this apparent weakness has turned out to
be a superpower. Learning everything the hard way has made me a
natural consultant and mentor. Because I’ve already explored all
the wrong paths, I often know someone is stuck before they do,
understand what threw them off course, and show them how to get
back on track
The reason I landed on this topic today is not that any of the above
makes me special, it’s actually that contradictions like these—whatever
their origin—are so typical among programmers born before 1990 that
they’re entirely mundane.
[22]An aberrant generation of programmers
Squint and everything I just said about myself could have described a
character from [23]The Big Bang Theory or [24]Silicon Valley. I’m at
peace with the fact that on my best days, I’m an overplayed, abrasive
character trope come to life. For decades, we’ve associated a slew of
mostly-negative traits like these with programmers as if the linkage is
inherent and inevitable. I’ve always thought that stereotype was
arbitrary—anybody can learn programming and be great at it—but now I’m
starting to think it’s a product of our times as well.
That is to say, I’ve come to believe the era typified by the enthusiast
programmer—autodidactic, obsessive, and antisocial—is drawing to a
close.
Why do I think that? Because there was a specific, generational moment
that attracted a bunch of people like me into the software industry. It
occurred during the brief window between home computers becoming widely
available and their becoming sealed airtight by platform holders. For a
fleeting moment, computers were simultaneously accessible and scrutable
during a necessary but temporary stage in the maturation of information
technology. Before they were rendered irreducibly complex as consumer
devices, merely using a computer required figuring out a lot about how
it worked. And coming of age with an understanding how computers worked
made programming them far more approachable. And thanks to cosmic
coincidence and the marketing teams of companies like RadioShack,
society unwittingly handed a generation of social mobility to [25]the
boys of upper-middle-class families in the US who felt more comfortable
at home with their computer than outside engaging socially with their
peers. I was definitely one of those awkward, anxious kids and a whole
lot of the programmers I’ve met along the way were too.
But one reason to believe that programmers don’t have to be like this
is that programmers weren’t always like this. I remember asking a
computer science professor in 2003 about our school’s gender disparity
(we only had a single woman in my class, and she later switched
majors). He recounted that before 1990 and the advent of hacker and
gamer subcultures, my college touted robust majorities of women in
computer science. (Nationally, women’s enrollment in CS doubled in a
decade, [26]peaking at 37.1% nationally in 1984 before dropping
precipitously.)
And one reason to believe programmers won’t always be this way is that
there’s plenty of evidence that the next generation of professional
programmers is no longer dominated by enthusiasts. People becoming
software developers today look markedly different than those who came
before. (Sadly, I wish I could say I’m referring to the success of
movements to increase representation from traditionally marginalized
groups—tech is still dramatically over-indexed on white dudes who
enjoyed affluent upbringings.) I’m just pointing to all the money
sloshing around here: it catapulted programming from a firmly middle
class job that appealed to people who really loved computers into a
comfortably upper-middle class profession that attracts anyone who
wants to secure their financial future. Ask anyone who switched careers
in the last decade how many times someone suggested they “learn to
code.” Countless people are entering the industry simply because
programming is a relatively secure, well-paying profession. (And
there’s nothing wrong with that!)
[27]Inter-generational conflict is brewing
I’m not sure if anyone has ever said “OK boomer” to my parents, but I
can imagine it wouldn’t feel awesome to hear.
Nor do I know whether anyone will coin a term to dismiss my generation,
but I have faith that there’s enough societal exasperation out there
for someone on TikTok to come up with something snappy. A lot of people
in my professional cohort still see themselves as social outcasts who
grew up in front of a CRT in their parents’ basements, but I suspect
the next generation sees a homogenous monolith of 40-somethings wearing
hoodies and sandals (with socks!) that lucked their way into capturing
control of the software industry just as it settled into a state of
economic maturity.
Sit with this distinction for a while, and you might start to see these
old-hat programmers as belonging to an Enthusiast Generation, one
that—due to its unique initial circumstances—is unlikely to be
replicated. Once I introduced the word “generation” to my thinking, it
became easier to make sense of many contentious, unresolved issues in
tech that flared up over the past decade by looking at them through the
lens of intergenerational conflict. And just like any discussion of
generations, it’s important to caveat that there are no firm boundary
lines, that exceptions are plentiful, and that many observations will
be isolated to a single locale and culture (the U.S. in this case,
maybe Canada?). The only thing that bucketing people into generations
can do for us is provide a new way to look at how a population may be
changing, thanks to a big enough time-step to perceive the accumulation
of decades of gradual change.
To illustrate, I’ll highlight three high-profile conflicts that make a
different kind of sense when viewed as a generational shift.
[28]Passion
I remember about 8 years ago, people [29]got [30]passionate [31]about
[32]the [33]word [34]passion.
This rubbed me the wrong way at first. Then again, everything does.
I remember thinking, “banning the word ‘passion’ will just lead people
to pick others like ‘self-driven’, ‘highly-motivated’, and
‘ambitious’.” I remember asking, “are we supposed to screen out
candidates for whom programming is a hobby outside work?” What I don’t
remember was pondering whether this was an indication that the times
were changing.
When I entered the industry, my salary was lower than it would’ve been
if I’d gone into accounting, or become an actuary, or majored in civil
engineering—myself and most of the people around me did get into
software because we were passionate about it. Reading tweets and
thinkpieces that suggested “passion” was a four-letter word felt like a
personal affront, so I responded defensively.
What I wasn’t thinking about was what it must have felt like for
everyone who entered the industry expecting their job to be a job but
who found themselves managed by people from my generation who didn’t
leave them room to have a life outside work. Maybe everyone else on the
team worked overtime without being asked. Maybe taking “too much”
supposedly “unlimited” time off would foreclose any chance for a
promotion. Maybe building rapport at lunch required holding evolved
opinions on Emacs vs. Vim, or mechanical key switches, or whatever was
on the front page of Hacker News. That sounds like a pretty miserable
existence, especially if programming isn’t what gets you out of bed in
the morning.
If you allow for the possibility we’re undergoing a generational
change, maybe this debate over “passion” is evidence that the
assumption that most programmers will always be passionate about
programming was mistaken and counter-productive.
[35]Craftsmanship
This brings another contentious word to mind: “craftsmanship.” Its
origin, as I witnessed it, was a reaction to the watering down of the
technical aspects of the agile software movement in the late 2000s in
favor of more lucrative soft-skills training and consulting services.
In case you missed it, most of the craftsmanship meme could be summed
up as a Slow Code movement. There was a lot of talk about measuring
twice and cutting once, establishing apprenticeship programs to train
new programmers, and a million ways to leverage automated tests for
purposes other than testing things.
I was an active participant in this community, speaking at the
[36]conference several times, putting [37]my name on the manifesto, and
generally exhorting anyone who would listen to please make their
software less terrible.
But looking back, the craftsmanship movement wasn’t only about
rekindling the tremendous engineering insights of agile methods like
[38]Extreme Programming, it was also a response to a rapid influx of a
generation of programmers who didn’t care about code quality the same
way we did. There was a sense that serious programmers were under
threat and hopelessly outnumbered by unserious ones. That if your team
didn’t get more disciplined about what you allow in your codebase,
you’d find yourself mired in a maze of complexity, beholden to epochal
build times, and left holding the bag with yet another legacy system.
Thinking about this point of tension as another manifestation of the
generational shift we’re experiencing, it’s easy to spot the problem:
“what you allow in your codebase” is a wee bit too easy to conflate
with “who you allow in your codebase.”
Shibboleths like “test-driven design” were so numerous that, to
outsiders, even perfunctory conversations were riddled with rhetorical
land mines. The emphasis on apprenticeship also carried assumptions
nobody seriously grappled with: that it implied “one true path” to
programming, that somebody (us) had uniquely figured it out, and that
the only way to learn it was to imitate the people who came before you.
I watched more than one conference talk advocating for
professionalizing software like any other trade by licensing
programmers just like we do plumbers, electricians, and [39]Canadian
engineers. Everyone’s intention was to prevent people from writing bad
software, but some of the movement’s prescriptions would have prevented
many people from writing software at all.
[40]10x Developers
Before you say anything, I know [41]you [42]probably [43]already
[44]have [45]an [46]opinion [47]on [48]the [49]idea of a “10x”
developer. If you aren’t familiar, the term refers to
debatably-mythical programmers whose output is worth that of ten other
programmers. What aspects of that output? Which ten other programmers?
Unclear.
The concept behind the “10x” term predates either of the generations of
programmers being discussed here. It seems to have originated in
[50]this (flimsy) 1968 study that among experienced programmers, the
best were ten times more productive than the worst (as opposed to the
average). We remember it because it was referenced in the late Fred
Brooks’ seminal [51]Mythical Man-Month.
That some people are better at their jobs than others is (usually)
uncontroversial. At least, it was, until it bubbled up in The Discourse
during the 2010s as a flashpoint over who the industry chooses to
valorize, often sparked by tweets from people affiliated with venture
capital and advocating that founders should strive to “only hire 10x
developers.”
In response, many people who reasonably identified this framing as
unproductive chose to pick a weird fight by claiming that 10x
developers don’t exist instead. This invited a lot of
counter-criticism, as I think most of us can dream up examples of
people whose work is 1/10th as valuable as their own. From there, the
conversation shifted to counter-counter-critiques enumerating the
adverse knock-on effects of adding a toxic actor to a team, no matter
how much of a ninja/rockstar they are at coding.
And it was here that the conversation settled into a stalemate, with
clear battle lines dividing the two camps. On one side were proponents
who believed a lot of well-compensated programmers aren’t very good,
but that a few programmers are so good that the value they generate far
exceeds the range of a typical payscale (which was why Google used to
brag that they “[52]pay unfairly”). On the other side were critics who
were more than happy to project every negative stereotype about
programmers onto these supposedly hyper-productive ones, suggesting a
10x developer’s easy-to-measure output often came with hard-to-measure
organizational and technical costs.
But now, looking back, this debate would have gone a lot differently if
we’d considered it through the valence of inter-generational conflict.
I’ll come clean: do I believe some programmers are at least an order of
magnitude better at programming than others? In my experience … yes.
I’ve worked with programmers who routinely solve problems in minutes
after I’ve wasted days or weeks on them. I’ve witnessed a programmer
singlehandedly build something in a day that an entire team struggled
to deliver in two weeks—without any of the catastrophic antisocial,
unsustainable downsides one might imagine. I’ve honestly seen more
socially corrosive behavior from the other end of the productivity
spectrum, because programmers who spin their wheels and make zero
forward progress for days, weeks, or months will inevitably scramble
for a way to save face.
It may be uncomfortable to admit, but it’s not altogether unreasonable
to speculate that enthusiast programmers may, in aggregate, outperform
professional programmers who hang up their keyboard at the end of each
shift. In my experience, these traits differentiate the former from the
latter:
* Tireless: spending more time practicing programming—not under
coercion to work long hours, but being intrinsically motivated to
do so—will generally make someone a better programmer
* Tenacious: chasing down answers with limitless curiosity and
relentless, no-holds-barred tenacity—whether or not it’s in their
job description to spelunk open source stack traces or debug other
teams’ code—will yield better information and faster progress
* Thorough: priding oneself on the quality of one’s work and pursuing
excellence in the (brace for it) craft—not falling victim to
perfectionism, but cutting the right corners when necessary—will
produce better-working software that’s easier to maintain
In the context of this generational rift, all three of the above are
exemplified by (but by no means exclusively limited to) us last-gen
models: the individual that programs in their spare time, obsessively
refuses to let a hard problem go, and is personally invested in the
quality of their work product.
I can’t imagine this dynamic feels awesome for members of the new
generation who don’t want to spend more than 40 hours a week at their
computer, or who have significant family commitments, or who aren’t
inclined to asynchronously ponder refactoring techniques as they run
errands. Will they be forever outpaced by more enthusiastic colleagues
for whom “programmer” is an all-encompassing identity as well a career?
I don’t know.
It’s an uncomfortable conversation because it’s an uncomfortable
reality.
[53]What do we do with this?
The power of an analogy lies in what it empowers people to do.
Envisioning programmers as belonging to discrete generations who are
ushering in a dramatic transition in the industry can equip us to
identify the common threads between many of the challenges we’re
currently facing. It may even enable us to predict and plan for
inevitable difficulties in the future, as more members of the earlier
generation age out.
Suppose you’ve read this far and you can buy both these arguments:
1. The next generation of programmers are less likely to be motivated
by a love of programming than the previous generation and may
differ in profound ways as a result
2. Software, as an industry, has structurally organized itself around
the assumption programmers will continue to resemble members of the
outgoing generation
If so, then you can probably imagine there will be a lot of problems to
be solved here. The hot-button issues we revisited above are already
known, even if we failed to put our collective finger on a common cause
at the time. It’s likely that countless more challenges lie beneath the
surface, waiting for the spark that causes them to boil over. It’s up
to us whether we put in the work to uncover and address these problems
proactively.
Here are a few examples of questions I find myself asking after sitting
with this for a few days:
* The new generation is more likely to expect structure and support
from human resources and management, whereas the previous
generation is more likely to find active management (e.g. career
pathing, coaching, goal-setting) actually saps their autonomy and
intrinsic motivation. Can organizations effectively cater to the
needs of both groups?
* It’s an open secret that the industry has no idea how to teach
people to program. Computer Science degrees famously don’t prepare
programmers for the job of programming, which has always been left
as an exercise to the student to figure out on their own time. If
the industry is going to outlive us enthusiast programmers, will it
adopt a sustainable approach to educating the next generation that
doesn’t require people to teach themselves everything?
* Betting your business on a limitless supply of self-starting,
self-sufficient, self-disciplined candidates seems a lot like
investing in the long-term prospects of fossil fuel extraction. How
will companies that built their cultures around enthusiast
programmers adjust to a generation needing more direction, more
support, and more accountability?
All we know for sure is that time keeps marching forward and change is
a constant, so planning for a future that looks different than the past
is usually time well spent.
What challenges do you see in this generational transition? I’d love to
[54]hear from you! If you enjoyed this piece and want to keep up with
what myself and the other agents are up to, you should check out our
[55]monthly newsletter.
[56]Justin Searls
An icon of a human figure Status
Double Agent
An icon of a hash sign Code Name
Agent 002
An icon of a map marker Location
Orlando, FL
[57]Twitter [58]Mastodon [59]Github [60]LinkedIn [61]Website
Related posts:
[62]How to tell if AI threatens YOUR job
Can ChatGPT help do your job? If so, how can you be sure AI won't
eventually replace you? Spot whether your job is at risk and what you
can do about it.
An icon of a clock Publish Date
March 14, 2023
An icon of a human figure Authors
[63]Justin Searls
An icon of a paper organzier Categories
[64]Industry
[65]Career
[66]Never Staff to the Peak
For a decade, engineering leaders were taught to solve every problem
with more full-time hires. There was always a better solution. Are you
ready for it?
An icon of a clock Publish Date
April 3, 2023
An icon of a human figure Authors
[67]Justin Searls
An icon of a paper organzier Categories
[68]Industry
[69]Leadership
[70]How my experience as an engineer made me a better recruiter
How similar are engineers and recruiters? Turns out a lot. A developer
turned recruiter adapted from writing code to recruit those who write
code.
An icon of a clock Publish Date
March 20, 2023
An icon of a human figure Authors
[71]Colleen Leonard
An icon of a paper organzier Categories
[72]Recruitment
[73]Community
Looking for developers? Work with people who care about what you care about.
We level up teams striving to ship great code.
[74]Let's talk
[75]Home [76]Agency [77]Services [78]Careers [79]Blog [80]Contact
[81]Mastodon [82]GitHub [83]LinkedIn [84]Twitter
[85]614.349.4279
[86]hello@testdouble.com
[87]Privacy Policy
Founded in Columbus, OH
[88]Test Double
References
1. https://testdouble.com/
2. https://testdouble.com/
3. https://testdouble.com/agency
4. https://testdouble.com/services
5. https://testdouble.com/careers
6. file:///
7. https://testdouble.com/contact
8. file:///
9. file:///posts/
10. file:///authors/justin-searls/
11. https://sorbet.org/
12. https://github.com/testdouble/mocktail
13. https://github.com/testdouble/mocktail/pull/22
14. https://github.com/paracycle
15. https://github.com/kddnewton
16. https://github.com/jez
17. mailto:justin@testdouble.com
18. file:///var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12618-6018TMP.html#what-makes-me-special
19. https://www.crowe.com/
20. https://www.vbulletin.com/
21. https://en.wikipedia.org/wiki/Mad_Libs
22. file:///var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12618-6018TMP.html#an-aberrant-generation-of-programmers
23. https://en.wikipedia.org/wiki/The_Big_Bang_Theory
24. https://en.wikipedia.org/wiki/Silicon_Valley_(TV_series)
25. https://www.npr.org/transcripts/356944145
26. https://nces.ed.gov/programs/digest/d12/tables/dt12_349.asp
27. file:///var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12618-6018TMP.html#inter-generational-conflict-is-brewing
28. file:///var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12618-6018TMP.html#passion
29. https://starbreaker.org/blog/programmer-passion-considered-harmful/index.html
30. https://www.hotjar.com/blog/the-passion-fallacy/
31. https://web.archive.org/web/20160304021738/http://www.gamasutra.com/view/feature/6523/the_designers_notebook_passion_.php?print=1
32. https://avdi.codes/the-moderately-enthusiastic-programmer/
33. https://philippe.bourgau.net/is-there-any-room-for-the-not-passionate-developer/
34. https://exceptionnotfound.net/passion-not-required-its-ok-to-only-program-for-a-paycheck/
35. file:///var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12618-6018TMP.html#craftsmanship
36. https://scna.softwarecraftsmanship.org/
37. http://manifesto.softwarecraftsmanship.org/
38. https://en.wikipedia.org/wiki/Extreme_programming
39. https://engineerscanada.ca/become-an-engineer/overview-of-licensing-process
40. file:///var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12618-6018TMP.html#10x-developers
41. https://jasoncrawford.org/10x-engineers
42. https://web.archive.org/web/20131205042721/https://medium.com/about-work/6aedba30ecfe
43. https://networkingnerd.net/2019/07/18/i-was-a-10x-engineer-and-im-sorry/
44. https://www.swarmia.com/blog/busting-the-10x-software-engineer-myth/
45. https://erikbern.com/2016/01/08/i-believe-in-the-10x-engineer-but
46. https://a16z.com/2014/07/30/the-happy-demise-of-the-10x-engineer/
47. https://blog.kenforthewin.com/state-of-the-10x-programmer-in-2018/
48. https://web.archive.org/web/20230326131816/https://payne.org/blog/the-myth-of-the-myth-of-the-10x-programmer/
49. https://avichal.com/2011/12/16/focus-on-building-10x-teams-not-on-hiring-10x-developers/
50. https://dl.acm.org/doi/10.1145/362851.362858
51. https://en.wikipedia.org/wiki/The_Mythical_Man-Month
52. https://www.inc.com/jeff-haden/why-google-quietly-uses-power-law-rule-to-pay-its-superstar-employees-unfairly.html
53. file:///var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12618-6018TMP.html#what-do-we-do-with-this
54. mailto:justin@testdouble.com
55. https://testdouble.com/newsletter
56. file:///authors/justin-searls/
57. https://twitter.com/searls
58. https://mastodon.social/@searls
59. https://github.com/searls
60. https://linkedin.com/in/searls
61. https://justin.searls.co/
62. file:///posts/2023-03-14-how-to-tell-if-ai-threatens-your-job/
63. file:///authors/justin-searls/
64. file:///categories/industry
65. file:///categories/career
66. file:///posts/2023-04-03-never-staff-to-the-peak/
67. file:///authors/justin-searls/
68. file:///categories/industry
69. file:///categories/leadership
70. file:///posts/2023-03-20-how-my-experience-as-an-engineer-made-me-a-better-recruiter/
71. file:///authors/colleen-leonard/
72. file:///categories/recruitment
73. file:///categories/community
74. https://link.testdouble.com/blog-cta-sales
75. https://testdouble.com/
76. https://testdouble.com/agency
77. https://testdouble.com/services
78. https://testdouble.com/careers
79. file:///
80. https://testdouble.com/contact
81. https://mastodon.social/@testdouble
82. https://github.com/testdouble
83. https://www.linkedin.com/company/testdouble
84. https://twitter.com/testdouble
85. tel:+16143494279
86. mailto:hello@testdouble.com
87. file://testdouble.com/privacy-policy
88. file://testdouble.com/

165
static/archive/inkdroid-org-belior.txt Normal file
View File

@@ -0,0 +1,165 @@
#[1]inkdroid
(BUTTON)
* [2]Home
* [3]About
* [4]Tags
* [5]Bookmarks
* [6]Photos
* [7]Podcasts
* [8]Music
* [9]Software
* [10]Mastodon
* [11]Talks
* [12]Web Archives
* [13]Feed
* [14]🎁
Why I don't use Copilot
June 4, 2023
[15]programming [16]artificial-intelligence
__________________________________________________________________
TL;DR Don’t install Copilot. It rots your brain and destroys the
environment.
__________________________________________________________________
[rubber-duck.jpg] [17]A rubber duck in use by a developer to aid code
review
[18]GitHub Copilot is a technology that is designed to help you write
code, kind of like your partner in [19]pair programming. But, you know,
it’s not an actual person. It’s “A.I.”–whatever that means.
In principle this sounds like it might actually be a good thing right?
I know several people, who I respect, that use it as part of their
daily work. I’ve heard [20]smart people say AI coding assistants like
Copilot will democratize programming, by making it possible for more
people to write code, and automate the drudgery out of their lives. I’m
not convinced.
Here’s why I don’t use Copilot (or ChatGPT) to write code:
1. Copilot’s suggestions are based on a corpus of open source code in
GitHub, but the suggestions do not mention where the code came
from, and what the license is. GitHub is stealing and selling
intellectual property.
2. Copilot lets you write code faster. I don’t think more code is a
good thing. The more code there is, the more code there is to
maintain. Minimalism in features is usually a good thing too. Less
really is more.
3. As more and more programmers use Copilot it creates conservativism
in languages and frameworks that prevents people from creating and
learning new ways of doing things. Collectively, we get even more
stuck in our ways and biases. Some of the biases encoded into LLMs
are things that we are actively trying to [21]change.
4. Developers become dependent on Copilot for intellectual work.
Actually, maybe addicted is a better word here. The same could be
(and was) said about the effect of search engines on software
development work (e.g. Googling error messages). But the difference
is that search results need to be interpreted, and the resulting
web pages have important context that you often need to understand.
This is work that Copilot optimizes away and truncates our
knowledge in the process.
5. Copilot costs money. It doesn’t cost tons of money (for a
professional person in the USA) but it could be significant for
some. Who does it privilege? Also, it could change (see point 4).
Remember who owns this thing.
6. How much [22]energy does it take to run Copilot as millions of
developers outsource their intellectual work to its LLM
infrastructure? Is this massive centralization and enclosure really
progress in computing? Or is it a [23]step backwards as we try to
[24]reduce our energy use as a species?
7. What does Copilot see of the code in your editor? Does it use your
code as context for the prompt? What does it store, and remember,
and give to others? Somebody has probably looked into this, but if
they have it is always up for revision. Just out of principle I
don’t want my editor sending my code somewhere else without me
intentionally doing it.
8. Working with others who use Copilot makes my job harder, since they
sometimes don’t really understand the details of why the code is
written a particular way. Over time Copilot code can mix idioms,
styles and approaches, in ways that the developer doesn’t really
understand or even recognize. This makes maintenance harder.
As far as I can tell the only redeeming qualities of Copilot are:
1. Copilot encourages you to articulate and describe a problem as
written prose before starting to write code. You don’t need Copilot
for this. Maybe keep a work journal or write a [25]design document?
Maybe use your issue tracker? Use [26]text to communicate with
other people.
2. Copilot is more interactive than a [27]rubber duck. But, it turns
out Actual People are even more interactive and surprising. Reach
out to other professionals and make some friends. Go to workshops
and conferences.
3. I could be convinced that Copilot has a useful place in the
[28]review of code rather than the first draft of code. It wouldn’t
be a replacement for review by people, but I believe it could
potentially help people do the review. I don’t think this exists
yet?
4. Copilot makes me think critically about machine learning
technology, my profession and its place in the world.
Maybe my thinking on this will change. But I doubt it. I’m on the older
side for a software developer, and (hopefully) will retire some day.
Maybe people like me are on the way out, and writing code with Copilot
and ChatGPT is the future. Maybe programming has always been about
increasing layers of abstraction and this is just the next logical
layer. I really hope not.
I enjoy programming because it’s about reasoning, thinking, models,
concepts, expression, communication, ethics, reading, learning, making,
and process. It’s an art and a practice that is best done with other
people.
Increasingly I think it’s imperative for programming to be done more
slowly, more deliberatively, and as part of more conversations with
more people. The furious automation of everything is eating the world.
Programs need to run more efficiently. Programs need to be well
understood, by a more diverse and varied set of people. Programs need
to be robust and resilient. Programs need to be easier to change.
Can Copilot help with these [29]goals? I think the answer is no,
because it doesn’t actually understand anything, and more importantly,
it doesn’t promote understanding.
__________________________________________________________________
Update (2023-06-09): For another take on Copilot that uses this post as
a jumping off point see Vivek Haldar’s [30]Re: Why I don’t use Copilot.
Unless otherwise noted all the content here is licensed [31]CC-BY
References
1. https://inkdroid.org/feed.xml
2. file:///
3. file:///about/
4. file:///tags/
5. http://pinboard.in/u:edsu
6. https://www.flickr.com/photos/inkdroid
7. file:///podcasts/feed.opml
8. https://bandcamp.com/edsu
9. https://github.com/edsu
10. https://social.coop/@edsu
11. file:///talks/
12. file:///web-archives/archives/
13. file:///feed.xml
14. https://bookshop.org/wishlists/d7c0224f5440df8d2c174ad2cc38b3fca1aa813f
15. file:///tag/programming
16. file:///tag/artificial-intelligence
17. https://commons.wikimedia.org/wiki/File:Rubber_duck_assisting_with_debugging.jpg
18. https://en.wikipedia.org/wiki/GitHub_Copilot
19. https://en.wikipedia.org/wiki/Pair_programming
20. https://changelog.com/podcast/534
21. https://www.wired.com/story/tech-confronts-use-labels-master-slave/
22. https://dl.acm.org/doi/pdf/10.1145/3442188.3445922
23. https://www.washingtonpost.com/technology/2023/06/05/chatgpt-hidden-cost-gpu-compute/
24. https://www.jasonhickel.org/less-is-more
25. https://en.wikipedia.org/wiki/Software_design_description
26. https://graydon2.dreamwidth.org/193447.html
27. https://en.wikipedia.org/wiki/Rubber_duck_debugging
28. https://en.wikipedia.org/wiki/Code_review
29. https://permacomputing.net/
30. https://vivekhaldar.com/articles/re--why-i-don-t-use-copilot/
31. https://creativecommons.org/licenses/by/4.0/

197
static/archive/mike-puddingtime-org-svf0ua.txt Normal file
View File

@@ -0,0 +1,197 @@
[1]Yes, Mike will do.
(BUTTON)
* [2]About
* [3]Tags
* [4]Categories
* [5]Search
* [6]Feed
[7]Home » [8]Posts
Daily notes for 2023-07-17
July 17, 2023
Table of Contents
* [9]Notes on conflict
* [10]The INT650
Notes on conflict[11]#
When my master and I were walking in the rain, he would say, “Do not
walk so fast, the rain is everywhere.”
—Shunryu Suzuki
For a very long time — too much of my life — I thought conflict was a
sign that there was a problem. I didn’t like disagreeing with people
about much of anything. I’m using “conflict” in a broad sense: Over
resources, points of view, vision, beliefs, tastes.
Over time I shifted on the matter a little, but when I look back on it
I realize I wasn’t really evolving my attitude toward conflict, I was
just evolving my response to its existence, while still believing that
being in a state of conflict is a problem. I just got better at keeping
my blood pressure low and gritting through it. I think I was looking at
conflict as a thing that you have to acknowledge exists, but that you
need to get through as quickly as possible, because it’s a bad place to
be.
That attitude created some problems:
* When you’re bad at being in conflict, you’re at a disadvantage with
people who are good at it and mean you harm; and you’re annoying
people who are good at it and mean you no harm.
* When you look at conflict as a thing to grit through and end
quickly it’s hard to maintain your integrity. (See above: The
people who don’t want what’s best for you (or the business, or the
world, or etc.) understand this, and the ones who are really good
at it and a little indifferent toward what’s best for you are
counting on you to do all the work to get out of conflict.)
* When you’d rather do anything than admit that you’re in a state of
conflict, you will eventually do something about your problem that
is less skillful for having waited than if you’d admitted it to
yourself (and whoever you’re in conflict with) sooner. Or, as one
of my past managers put it to me, “don’t be that guy who
hockey-sticks.” (I nodded then kind of hockey-sticked.)
* When you’re bad at being in conflict, and you’re willing to be set
aside your integrity or do other things to get out of it quickly,
you’ll eventually get tired of “losing” and figure out ways to
“win” that cause others to see you as, at best, baffling and
frustrating, and at worst Machiavellian and treacherous.
That, anyhow, is a rough categorization of my many hundreds of
mishandlings of conflict. Maybe the most interesting thing to me about
all those mishandlings is that over time I managed to convince myself
that failing to be in conflict well was a sign of virtue. Moral
sophistication. “Taking the high road.” “Not worth the stress.”
“Learning how to play the game.” “Protecting the team.”
Over the past few years, I’ve changed on the matter: On balance, I
definitely don’t think its existence is a sign there’s a problem. It’s
just a sign that there’s a conflict.
I still feel a little cautious about conflict when I don’t know the
person I’m in conflict with very well. Caution is useful, because
people who are bad at being in conflict but mean well — people who are
“good eggs” — can still sort of mess things up, because if I have to
bet on whether someone hates “losing” or just grinning and bearing it
more, my money is on them hating losing more. When things get to a
place where it feels existential to them, even good eggs can act sort
of rotten. So you have to take time and attend to the interaction so
they can be in conflict and feel safe about it.
I still think I have a responsibility to introduce the existence of
conflict with kindness, or receive the news that I’ve entered into a
state of conflict in a manner that invites a full airing. “Relaxed and
possibly delighted curiosity,” I suppose I’d call it, rather than a
furrowing of the brow and assurances that I want to restore harmony at
once. Because I don’t want to restore harmony at once. I want to
understand why we want different things, then figure out how we can
both behave with integrity while we sort that out.
The INT650[12]#
I finally quit waffling on what to do with the Royal Enfield Himalayan.
I took it up to [13]Sabatino Moto in St. Johns and traded it in for
another Royal Enfield: An INT650 (“Interceptor” everywhere else in the
world, but not in North America where Honda owns the rights to the
name.)
It’s a pretty night and day difference. The Himalayan is a mountain
goat, and the INT650 is … something a little prettier and a little less
rough. I was never going to ride the Himalayan the way it was meant to
be ridden — fire roads, gravel, dirt — and I didn’t have the patience
for the very “work in progress” attitude Royal Enfield took toward it.
One thing you learn from all the Himalayan videos on YouTube is that
the people who love them best don’t mind fiddling, tweaking, and
wrenching. After reading hundreds of owners talk about their
experiences, I have come to realize I lost the factory QA lottery on
mine, and that engendered a lack of confidence in it that I never
recovered from.
Also turns out, I think, that I had a bad dealer:
The first RE dealer in the Portland area doesn’t really want to sell
them, and it really does not want to do anything other than the most
basic service. I think I’ve documented that elsewhere, so I won’t go
into it more here, but I’ll just offer the observation that RE’s
strategy of linking up with Harley dealers to build out its US
distribution network did its customers no favors.
The folks at Sabatino, on the other hand, seem to have a genuine
appreciation for the bikes, that extends all the way to acknowledging
that RE has some QA challenges. Sabatino addresses that by doing their
own QA when they uncrate a new bike. And they’re willing to talk about
the ups and downs of each model. My head was briefly turned by another
model, and I got a reasoned, balanced, discussion of why maybe that one
wouldn’t work for me.
They also offer test rides. I can name one dealership that grudgingly
made me sign a waiver and write a check for the full amount to test
ride a Grom for five laps around their parking lot, and they only did
that because it was a two-year-old model and they’d sold the newer one
they promised me out from under me. Sabatino made me do the waiver,
share my insurance information, and hand over my license, but then they
tossed me the keys and told me they’d see me when they saw me.
Anyhow, the test ride sold me. I’ve been through several configurations
of motorcycle and scooter since getting my motorcycle endorsement —
maxiscoots, normal scoots, mini-moto, cruiser, trail bike, dual-sport —
and none of them have been the thing I first imagined myself riding
when I finally decided to learn how to ride. Well, learn how to ride as
an adult, anyhow. The twin 650 runs and sounds nice, the bike handles
more comfortably than the Himalayan despite there being 40 pounds more
of it, and the super-simple analog speedo and tach are just sort of
pleasant. I ran it around St. Johns for a while, was struck by how
immediately comfortable it was (and how confident I felt on it), and
that was that.
Yesterday I took it on a ride out Foster Road toward Damascus. There’s
a side road I head out onto that eventually rejoins on the other side
of Damascus, close to a back road that joins the highway down to
Estacada. So I headed out past Estacada, to see how it did on a small
back highway. There was a little bit of buffeting — no fairings — but
it ran and handled well. I felt more confident on the little back roads
coming back than I did heading out as I got to know the bike better. I
did decide to detract from its vintage purity a little by ordering a
Dart flyscreen when I got back: People say it helps clean up the
turbulence at highway speeds, and keeps the bugs off the pretty silver
cans.
Anyhow, glad I’ve got it in the driveway with so much of the riding
season left, and I can wholeheartedly recommend Sabatino Moto if you’re
looking to buy one for yourself.
* [14]journal
* [15]conflict
[16]« Prev
Daily notes for 2023-07-18 [17]Next »
Mission: Incomprehensible © 2023 Mike Hall — [18]Colophon
References
Visible links:
1. https://mike.puddingtime.org/
2. https://mike.puddingtime.org/about/
3. https://mike.puddingtime.org/tags/
4. https://mike.puddingtime.org/categories/
5. https://mike.puddingtime.org/search/
6. https://mike.puddingtime.org/index.xml
7. https://mike.puddingtime.org/
8. https://mike.puddingtime.org/posts/
9. file:///var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12623-9641TMP.html#notes-on-conflict
10. file:///var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12623-9641TMP.html#the-int650
11. file:///var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12623-9641TMP.html#notes-on-conflict
12. file:///var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12623-9641TMP.html#the-int650
13. https://www.sabatinomoto.com/
14. https://mike.puddingtime.org/tags/journal/
15. https://mike.puddingtime.org/tags/conflict/
16. https://mike.puddingtime.org/posts/2023-07-18-daily-notes/
17. https://mike.puddingtime.org/posts/2023-07-15-mission--incomprehensible/
18. file:///colophon
Hidden links:
20. https://social.lol/@mph
21. https://pix.puddingtime.org/
22. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12623-9641TMP.html#top

347
static/archive/www-robinsloan-com-sbm0vr.txt Normal file
View File

@@ -0,0 +1,347 @@
#[1]next [2]alternate
[3]Home [4]About [5]New: Concept album
From: Robin Sloan
To: the lab
Sent: March 2023
Phase change
An extremely close-up photograph of a snowflake, looking almost
architectural. [6]Snowflake, Wilson Bentley, ca. 1910
Please excuse the off-schedule transmission. The idea of a steady,
predictable publishing cadence is always so appealing … and then events
overtake me!
I think this lab newsletter will shift into a “whenever appropriate”
schedule for the rest of this year. In this news flash, you’ll find two
items: a time-sensitive link, and some thoughts on all that’s happening
with AI.
This is an archived edition of Robin’s lab newsletter. You can sign up
to receive future editions using the form at the bottom of the page.
A group of internet thinkers has proposed a [7]Summer of Protocols:
an 18-week program that will run from May 1 to Aug 31, 2023, and
aims to catalyze broad-based and wide-ranging exploration of the
rapidly evolving world of protocols.
[8]Applications are due in just a couple weeks, which is why I wanted
to circulate the link immediately. I don’t know a ton about the program
or its organizers, but I like the spirit captured on the website, and
I feel like it might be a generative opportunity for someone(s)
reading this.
Even for those of us who aren’t going to participate, the introductory
paper makes for a bracing, inspiring read: [9]The Unreasonable
Sufficiency of Protocols.
Now, on to the AI thoughts, which, as you’ll see, loop around to
connect to protocols again:
[10]Finding a question
Earlier this week, in [11]my main newsletter, I praised a new project
from Matt Webb. Here, I want to come at it from a different angle.
Briefly: Matt has built the [12]Braggoscope, a fun and useful
application for exploring the archives of the beloved BBC radio show In
Our Time, hosted by the inimitable Melvyn Bragg.
In Our Time only provides HTML pages for each episode — there’s no
structured data, no sense of “episode X is connected to episode Y
because of shared feature Z”.
As Matt explains [13]in his write-up, he fed the plain-language content
of each episode page into the GPT-3 API, cleverly prompting it to
extract basic metadata, along with a few subtler properties — including
a Dewey Decimal number!?
(Explaining how and why a person might prompt a language model is
beyond the scope of this newsletter; you can [14]read up about it
here.)
Here’s [15]a bit of Matt’s prompt:
Extract the description and a list of guests from the supplied episode notes fro
m a podcast.
Also provide a Dewey Decimal Classification code and label for the description
Return valid JSON conforming to the following Typescript type definition:
{
"description": string,
"guests": {"name": string, "affiliation": string | null}[]
"dewey_decimal": {"code": string, "label": string},
}
Episode synopsis (Markdown):
{notes}
Valid JSON:
Important to say: it doesn’t work perfectly. Matt reports that GPT-3
doesn’t always return valid JSON, and if you browse the Braggoscope,
you’ll find plenty of questionable filing choices.
And yet! What a technique. (Matt credits Noah Brier for [16]the
insight.)
It fits into a pattern I’ve noticed: while the buzzy application of the
GPT-alikes is chat, the real workhorse might be text transformation.
As Matt writes:
Sure Google is all-in on AI in products, announcing chatbots to
compete with ChatGPT, and synthesised text in the search engine.
BUT.
Using GPT-3 as a function call.
Using GPT-3 as a universal coupling.
It brings a lot within reach.
I think the magnitude of this shift … I would say it’s on the order
of the web from the mid 90s? There was a radical simplification and
democratisation of software (architecture, development, deployment,
use) that took decades to really unfold.
For me, 2022 and 2023 have presented two thick strands of inquiry: the
web and AI, AI and the web. This is evidenced by the structure of these
lab newsletters, which have tended towards birfucation.
Matt’s thinking is interesting to me because it brings the
strands together.
One of the pleasures of HTTP (the original version) is that it’s almost
plain language, though a very simple kind. You can execute an HTTP
request “by hand”: telnet www.google.com 80 followed by GET /.
Language models as universal couplers begin to suggest protocols that
really are plain language. What if the protocol of the GPT-alikes is
just a bare TCP socket carrying free-form requests and instructions?
What if the RSS feed of the future is simply my language model replying
to yours when it asks, “What’s up with Robin lately?”
I like this because I hate it; because it’s weird, and makes me
feel uncomfortable.
__________________________________________________________________
I think it’s really challenging to find the appropriate stance towards
this stuff.
On one hand, I find critical deflation, of the kind you’ll hear from
Ted Chiang, Simon Willison, and Claire Leibowicz in [17]this recent
episode of KQED Forum, appropriate and useful. The hype is so powerful
that any corrective is welcome.
However! On the critical side, the evaluation of what’s before us isn’t
sufficient; not even close. If we demand humility from AI engineers,
then we ought to match it with imagination.
An important fact about these language models — one that sets them
apart from, say, the personal computer, or the iPhone — is that their
capabilities have been surprising, often confounding, even to
their creators.
AI at this moment feels like a mash-up of programming and biology. The
programming part is obvious; the biology part becomes apparent when you
see [18]AI engineers probing their own creations the way you might
probe a mouse in a lab.
The simple fact is: even at the highest levels of theory and practice,
no one knows how these language models are doing what they’re doing.
Over the past few years, in the evolution from GPT-2-alikes to
GPT-3-alikes and beyond, it’s become clear that the “returns to
scale”—both in terms of (1) a model’s size and (2) the scope of its
training data — are exponential and nonlinear. Simply adding more works
better, and works weirder, than it should.
The nonlinearity is, to me, the most interesting part. As these models
have grown, they have undergone widely observed “phase changes” in
capability, just as sudden and surprising as water frozen or
cream whipped.
At the moment, my deepest engagement with a language model is in a
channel on a Discord server, where our gallant host has set up a
ChatGPT-powered bot and laced a simple personality into its prompt. The
sociability has been a revelation — multiplayer ChatGPT is much, MUCH
more fun than single player — and, of course, the conversation tends
towards goading the bot, testing its boundaries, luring it
into absurdities.
The bot writes poems, sure, and song lyrics, and movie scenes.
The bot also produces ASCII art, and SVG code, and [19]PICO-8 programs,
though they don’t always run.
I find myself deeply ambivalent, in the original sense of: thinking
many things at once. I’m very aware of the bot’s limitations, but/and
I find myself stunned by its fluency, its range.
Listen: you can be a skeptic. In some ways, I am! But these phase
changes have happened, and that probably means they will keep
happening, and no one knows (the AI engineers least of all) what might
suddenly become possible.
As ever, [20]Jack Clark is my guide. He’s a journalist turned AI
practioner, involved in policy and planning at the highest levels,
first at OpenAI, now at Anthropic. And if he’s no longer a
disinterested observer, he remains deeply grounded and moral, which
makes me trust him when he says, with confidence: this is the biggest
thing going, and we had all better brace for weird times ahead.
__________________________________________________________________
What does that mean, to brace for it?
I’ve found it helpful, these past few years, to frame my anxieties and
dissatisfactions as questions. For example, fed up with the state of
social media, [21]I asked: what do I want from the internet, anyway?
It turns out I had an answer to that question.
Where the GPT-alikes are concerned, a question that’s emerging for
me is:
What could I do with a universal function — a tool for turning just
about any X into just about any Y with plain language instructions?
I don’t pose that question with any sense of wide-eyed expectation; a
reasonable answer might be, eh, nothing much. Not everything in the
world depends on the transformation of symbols. But I think that IS the
question, and I think it takes some legitimate work, some strenuous
imagination, to push yourself to believe it really will be “just about
any X” into “just about any Y”.
I help operate [22]a small olive oil company, and I have actually spent
a fair amount of time lately considering this question in the context
of our business. What might a GPT-alike do for us? What might an even
more capable system do?
My answer, so far, is indeed: eh, nothing much! It’s a physical
business, after all, mainly concerned with moving and transforming
matter. The “obvious” application is customer support, which I handle
myself, and which I am unwilling to cede to a computer or, indeed,
anyone who isn’t me. The specific quality and character of our support
is important.
(As an aside: every customer support request I receive is a miniature
puzzle, usually requiring deduction across several different systems.
Many of these puzzles are challenging even to the general intelligence
that is me; if it comes to pass that a GPT-alike can handle them
without breaking a sweat, I will be very, very impressed.)
(Of course, it’s not going to happen like that, is it? Long before
GPT-alikes can solve the same problems Robin can, using the tools Robin
has, the problems themselves will change to meet the GPT-alikes
halfway. The systems will all learn to “speak GPT”, in some sense.)
The simple act of asking and answering the question was clarifying and
calming. It plucked AI out of the realm of abstract dread and plunked
it down on the workbench.
__________________________________________________________________
Jack Clark includes, in all of his AI newsletters, a piece of original
micro-fiction. One of them, [23]sent in December, has stayed with me.
I’ll reproduce it here in full:
Reality Authentication
[The internet, 2034]
“To login, spit into the bio-API”
I took a sip of water and swirled it around my mouth a bit, then
hawked some spit into the little cup on my desk, put its lid on,
then flipped over the receptacle and plugged it into the
bio-API system.
“Authenticating … authentication successful, human-user identified.
Enjoy your time on the application!”
I spent a couple of hours logged-on, doing a mixture of work and
pleasure. I was part of an all-human gaming league called the
No-Centaurs; we came second in a mini tournament. I also talked to
my therapist sans his augment, and I sent a few emails over the
BioNet protocol.
When I logged out, I went back to the regular internet. Since the AI
models had got minituarized and proliferated a decade ago, the
internet had radically changed. For one thing, it was so much faster
now. It was also dangerous in ways it hadn’t been before - Attention
Harvesters were everywhere and the only reason I was confident in my
browsing was I’d paid for a few protection programs.
I think “brace for it” might mean imagining human-only spaces, online
and off. We might be headed, paradoxically, for a golden age of “get
that robot out of my face”.
In the extreme case, if AI doesn’t wreck the world, language models
could certainly wreck the internet, like Jack’s Attention Harvesters
above. Maybe we’ll look back at the Web Parenthesis, 1990-2030. It was
weird and fun, though no one in the future will quite understand
the appeal.
We are living and thinking together in an interesting time. My
recommendation is to avoid chasing the ball of AI around the field,
always a step behind. Instead, set your stance a little wider and form
a question that actually matters to you.
It might be as simple as: is this kind of capability, extrapolated
forward, useful to me and my work? If so, how?
It might be as wacky as: what kind of protocol could I build around
plain language, the totally sci-fi vision of computers just TALKING to
each other?
It might even be my original question, or a version of it: what do
I want from the internet, anyway?
From Oakland,
Robin
March 2023, Oakland
I'm [24]Robin Sloan, a fiction writer. You can sign up for my
lab newsletter:
____________________ Subscribe
This website doesn’t collect any information about you or your reading.
It aspires to the speed and privacy of the printed page.
Don’t miss [25]the colophon. Hony soyt qui mal pence
References
1. file:///confirm/main/subscribe/
2. https://www.robinsloan.com/feed.xml
3. file:///
4. file:///about
5. https://ooo.ghostbows.ooo/?utm_source=Robin_Sloan_sent_me
6. https://publicdomainreview.org/essay/the-snowflake-man-of-vermont?utm_source=Robin_Sloan_sent_me
7. https://efdn.notion.site/Summer-of-Protocols-3d7983d922184c4eb72749e9cb60d076?utm_source=Robin_Sloan_sent_me
8. https://efdn.notion.site/Application-5b71c238d6bd44cf9137946ef7767e53?utm_source=Robin_Sloan_sent_me
9. https://efdn.notion.site/Pilot-Study-1bf3e3be6bf34a2eb8156ddf98d3fa67?utm_source=Robin_Sloan_sent_me
10. file:///var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12614-3163TMP.html#gpt
11. https://www.robinsloan.com/newsletters/ring-got-good/?utm_source=Robin_Sloan_sent_me
12. https://genmon.github.io/braggoscope/?utm_source=Robin_Sloan_sent_me
13. https://interconnected.org/home/2023/02/07/braggoscope?utm_source=Robin_Sloan_sent_me
14. https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-openai-api?utm_source=Robin_Sloan_sent_me
15. https://news.ycombinator.com/item?id=35073824&utm_source=Robin_Sloan_sent_me
16. https://brxnd.substack.com/p/the-prompt-to-rule-all-prompts-brxnd?utm_source=Robin_Sloan_sent_me
17. https://www.kqed.org/forum/2010101892368/how-to-wrap-our-heads-around-these-new-shockingly-fluent-chatbots?utm_source=Robin_Sloan_sent_me
18. https://www.anthropic.com/index/toy-models-of-superposition-2?utm_source=Robin_Sloan_sent_me
19. https://www.lexaloffle.com/pico-8.php?utm_source=Robin_Sloan_sent_me
20. https://importai.substack.com/?utm_source=Robin_Sloan_sent_me
21. file:///lab/specifying-spring-83/
22. https://fat.gold/?utm_source=Robin_Sloan_sent_me
23. https://us13.campaign-archive.com/?u=67bd06787e84d73db24fb0aa5&&id=a03ebcd500&utm_source=Robin_Sloan_sent_me
24. https://www.robinsloan.com/about?utm_source=Robin_Sloan_sent_me
25. file:///colophon/