coors = mediocre beer, CORS = annoying security gotchas

Recently I was on a project where we started using "bearer tokens" (like bearer bonds, bearer tokens means if you have possession of it, you're trusted)

But we were getting CORS errors - but they read like cross-origin issues?And the request with the bearer token would go ahead and work when exported as cUrl commands....

Cut to the chase, the browser was sending an OPTIONS request to sniff around to the "Access-Control-Allow-Origin" header - but accidentally that was set to require the token - but that's not the way OPTIONS are supposed to work, so the browser doesn't include it. Anyway, so the 401 rejection of the OPTIONS request meant that the browser wouldn't try the actual GET. 

A little frustrating. It's like "c'mon browser - live a little, send the request, let the server figure out if it doesn't want to talk to you" -- sort of like giving a pep talk when you're playing wingman for your single friend at a bar.

chatgpt as lossy compression

My favorite sci-fi author Ted Chiang wrote ChatGPT is a blurry jpeg of the web:

Imagine what it would look like if ChatGPT were a lossless algorithm. If that were the case, it would always answer questions by providing a verbatim quote from a relevant Web page. We would probably regard the software as only a slight improvement over a conventional search engine, and be less impressed by it. The fact that ChatGPT rephrases material from the Web instead of quoting it word for word makes it seem like a student expressing ideas in her own words, rather than simply regurgitating what she's read; it creates the illusion that ChatGPT understands the material. In human students, rote memorization isn't an indicator of genuine learning, so ChatGPT's inability to produce exact quotes from Web pages is precisely what makes us think that it has learned something. When we're dealing with sequences of words, lossy compression looks smarter than lossless compression.

Admittedly this was written last year but I think he underestimates the usefulness of ChatGPT in applying knowledge to a particular case at hand:

This analogy makes even more sense when we remember that a common technique used by lossy compression algorithms is interpolation--that is, estimating what's missing by looking at what's on either side of the gap. When an image program is displaying a photo and has to reconstruct a pixel that was lost during the compression process, it looks at the nearby pixels and calculates the average. This is what ChatGPT does when it's prompted to describe, say, losing a sock in the dryer using the style of the Declaration of Independence: it is taking two points in "lexical space" and generating the text that would occupy the location between them. ("When in the Course of human events, it becomes necessary for one to separate his garments from their mates, in order to maintain the cleanliness and order thereof. . . .") ChatGPT is so good at this form of interpolation that people find it entertaining: they've discovered a "blur" tool for paragraphs instead of photos, and are having a blast playing with it.

I'm willing to grant that asking ChatGPT to apply its embedded gleaned knowledge to a particular problem is basically that kind of of interpolation, but in practice it is far more useful than making entertaining mashups. In my case, especially for technical tasks - as I previously quoted David Winer:

ChatGPT is like having a programming partner you can try ideas out on, or ask for alternative approaches, and they're always there, and not too busy to help out. They know everything you don't know and need to know, and rarely hallucinate (you have to check the work, same as with a human btw). It's remarkable how much it is like having an ideal human programming partner. It's the kind of helper I aspire to be.

Interesting world.

don't be afraid to duplicate

 "I generally follow the rule. Duplicate code until you have at least three examples. Then you can generalise.

So many times if you dedupe code which appears in two places that at first looks like the same code you later realise it is different behaviour and make the "general" function much more complex."

--Clair Blackshaw

Interesting to pair that with my general sense of the kneejerk tendency of some folk to look for a library rather than write a little bespoke code. A good library solves MANY scenarios at once, but since the whole point is kind of NOT understanding the solution as deeply (or taking a lot of time to learn new language of configuration) if it does go wrong you're likely to have less clear sight into how to dig yourself out...

the chicken and the pig

Once upon a time I had official scrum master training with Ken Schwaber.

Besides the general scrum knowledge I acquired some details have stuck with me, like the bill-shaped duck call he would use to get peoples' attention. (He said people were less likely to steal it.)
 

Also this introductory line which seems oddly belligerent, but reflects the Scrum folks' faith that they had the better idea (and indeed they did make the new standard, even if few places practice the pure version) is this:

You suck... and that makes me sad.

Also I remember hearing this story, not quite sure if this exactly the version but:

A man walks into Fat Burger and orders a Double Fatburger, fries, and a drink.

Man only has $3.15 but the total comes to $7.15. The manager tells him he’s going to remove something from his order.  But the man insisted to have it all.

The manager doesn’t want to lose the customer so he walks out and finds a dead squirrel off the street.  He makes the burger by cooking the squirrel and putting it on a bun and hands it over to the man.

So if you draw the analogy of the story with the scenario above, it clearly seems that team compromises the quality just to deliver the product on time.

In order to achieve the unrealistic deadlines, first thing teams do is to discard the automated tests and stops refactoring the code. Soon after their code resembles coding they did in high school and they are making a huge mess.

But mostly I remember the metaphor of the chicken and the pig:

 

(Here's Vizdos' page on the origin of the cartoon)

The metaphor was that developer are the "pigs" whose bacon is on the line, so to speak, while the other people involved were "chickens" without skin in the game, and so should be quiet observers during the daily standup, for instance.

OK, for one thing, that is a WEIRD metaphor. Way back when I sketched out a different final panel:

(Ken Schwaber was amused by the panel and asked to keep it.)

But that really tied into my problem with the metaphor; Product Owners and other non-devs DO have skin in the game, their jobs and reputations are at stake as well, and in some ways it's even tougher for them because they are dependent on devs and can't just "work harder" to get better results. (also true Scrum aims to guarantee predictability over time, and has relatively little to say about efficiency and timeliness.  As my team lead Steve Katz put it: "the process isn't about not getting fired")

I guess they've moved on from the chicken/pig metaphor anyway - it was a little too joke-y, and I think other people shared my view that non-dev stakeholders are still critical to the success of a project.

humane/her

Marques Brownlee reviews the Humane AI Pin... "the worst product I've ever reviewed... for now"

The form factor reminds me of this chef's kiss detail from the movie "Her" - Samantha's form factor is basically that of a foldable smartphone, but Twombly uses a safety pin to give her a boost in his pocket so she can see the world:

 (Also Brownlee had the clapback of the year to someone arguing he shouldn't have been so negative about a new striving-to-be-innovative product - "We disagree on what my job is")

 

 

on leadership

the biggest threat facing your team, whether you're a game developer or a tech founder or a CEO, is not what you think

Brilliant article on leadership. It's long and gets into the weeds of the games industry, but there is a lot that is true for the whole corporate world.

It touches on one point that is much on my mind: so much of our corporate leadership is "make number go up" (immediately! but then also forever.) Corporations generally have a legal obligation to "increase shareholder value", and in general that's on a per quarter basis. Sustainability and long term viability are afterthoughts at best.

The article points out there's parallels in that and some USA policy decisions in Vietnam:

But when the McNamara discipline is applied too literally, the first step is to measure whatever can be easily measured. The second step is to disregard that which can't easily be measured or given a quantitative value. The third step is to presume that what can't be measured easily really isn't important. The fo[u]rth step is to say that what can't be easily measured really doesn't exist. This is suicide.

But then when you combine that with leaders who view themselves as capable of finessed big picture and aesthetic decisions as, say, Steve Jobs... well, they aren't always looking to the people reporting to them as potential Jony Ives - they want to go on their own guts.

So an organization has to thread the needle between "it only counts if it can be quantified" and "it only counts if it has good 'gut feel' to topmost leadership". I think you do that by building and then trusting the expertise of the people in the middle.

from "Headcrash"

"I mean." Uberman cleared his throat, adjusted his necktie, and began delivering his morning whine, which is clearly what he'd been intending to do all along. "This is, what? The third network outage this year?"

I stopped. "We're having some problems porting your database to our server, sir." I edged one step closer to the exit.

"I mean," Uberman scowled, "if I can't depend on your network, I'm screwed. Just totally screwed, you know?"

Then how come you're not smiling? is what I thought, but "We'll have it back up as soon as possible," is what I said.

"I mean," Uberman whacked his PC with his newspaper again, "we never had problems like this before MDE acquired us. Dammit, our old Applied Photonics network never crashed! Not once!"

"So I've heard." And heard, and heard, and heard! And if you gave me just sixteen users in a one-floor office, I could make this network look pretty good, too.

Bruce Bethke, "Headcrash"

"Headcrash" is kind of a no-account cyberpunk-y book from the mid-90s... the technobabble is pretty clumsy, but for some reason this passage has stuck with me for 20 years so I thought I'd post it - from time to time, its reminder that little toy systems can get away with things that projects you want to scale can't is useful.