Meredith Whitaker, the President of Signal and chief advisor to the AI Now Institute, appeared on the Big Technology Podcast and she had some interesting things to say about OpenAI, Microsoft and the hype that has built around AI since the release of ChatGPT.

ChatGPT itself is not an innovation. It's an advertisement that was very, very expensive that was placed by Microsoft to advertise the capacities of generative AI and to advertise their Azure GPT APIs that they were selling after effectively absorbing OpenAI as a Microsoft subsidiary. But the technology or frameworks on which ChatGPT are based are dated from 2017.

So, Microsoft puts up this ad, everyone gets a little experience of communicating with something that seems strikingly like a sentient interlocutor. You have a supercharged chat bot that everyone can experience and have a kind of story about. It's a bit like those viral "upload your face and we'll tell you what kind of person you are" data collection schemes that we saw across Facebook in the 2010s and then an entire narrative of innovation or a narrative of scientific progress gets built around this sort of ChatGPT moment.

Suddenly generative AI is the new kind of AI. Suddenly claims about sentience and about the superintelligence and AI being on the cusp of breaking into full consciousness and perhaps, endangering human life. All of this almost like religious rhetoric builds up in response to ChatGPT.

I'm not a champion of Google but I think we need to be very careful about how are we defining innovation and how are we defining progress in AI because what I'm seeing is a reflexive narrative building around what is a very impressive ad for a large, generative language model but not anything we should understand as constitutionally innovative.

Meredith Whitaker on ChatGPT

She also talks about the dangers of trusting the models to return factual information.

I didn't say useless. I said not that useful in most serious contexts or that's what I think. If it's a low stakes lit review, a scan of these docs could point you in the right direction. It also might not. It also might miss certain things because you're looking for certain terms but actually, there's an entire field of the literature that uses different terms and actually if you want to research this and understand it, you should do the reading.

Not maybe trust a proxy that is only as good as the data it's trained on and the data it's trained on is the internet plus whatever fine-tuning data you're using.

I'm not saying it's useless, I'm saying it is vastly over-hyped and the claims that are being made around it are I think leading to a regulatory environment that is a bit disconnected from reality and to a popular understanding of these technologies that are far over-credulous about the capabilities.

Any serious context where factuality matters is not somewhere where you can trust one of these systems.

Meredith Whitaker on AI Hype and Doing the Reading

I remember Ezra Klein talking about the importance of doing the reading and the connections that can be formed in your mind as the material becomes more familiar to you. That depth of knowledge can provoke insights to create something new or to improve an existing service. Loading all your books into an expert system does not help this type of thinking if you never read them yourself.

Productivity in knowledge work is still incentivized to produce more volume rather than more quality. There's great story about Bill Atkinson when Apple decided to track the productivity by the number of lines of code that they wrote in a week. According to Folklore.org:

Bill Atkinson, the author of Quickdraw and the main user interface designer, who was by far the most important Lisa implementer, thought that lines of code was a silly measure of software productivity. He thought his goal was to write as small and fast a program as possible, and that the lines of code metric only encouraged writing sloppy, bloated, broken code.

He recently was working on optimizing Quickdraw's region calculation machinery, and had completely rewritten the region engine using a simpler, more general algorithm which, after some tweaking, made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code.

-2000 Lines Of Code (Andy Hertzfeld/Folklore.org)

I'm afraid that the diligence and craft displayed by Bill Atkinson would not be rewarded today when developers are encouraged to crank out as much code as possible using GitHub Copilot or some other AI assistant.

MacRumors reported that all first generation Apple Watch models were going to be added to the obsolete products list according to an internal memo. This includes the gold edition which cost $17,000 when released 8 years ago.

When a product is added to the obsolete product list "Apple discontinues all hardware service for obsolete products, and service providers cannot order parts for obsolete products" according to Apple support. This means there are no more repairs, system updates or security patches. The product should still work as long as the hardware holds up. Once it breaks, that's it.

Kyle Wiens, the CEO of iFixit, gave a great response to Motherboard about this story.

“It's ludicrous,” Kyle Wiens, CEO of iFixit, told Motherboard in an email. “High end watches are heirlooms. You can, and should, pass them down to your kids. Technology the way Apple builds it is a flash in the pan. Civilizations thousands of years from now will laugh at how short-sighted we are. Batteries that wear out in two years? Service networks that shut down after seven? That's not how you build a society that values craftsmanship.”

'It's Ludicrous': Those $17K Gold Apple Watches Are Now Obsolete - Jordan Pearson (Vice Motherboard)

I came across this story of Tim Mackinnon recently. It provided a valuable reminder of the importance of looking at your vision of success and how you structure incentives to realise that vision.

You see, the reason that Tim’s productivity score was zero, was that he never signed up for any stories. Instead he would spend his day pairing with different teammates. With less experienced developers he would patiently let them drive whilst nudging them towards a solution. He would not crowd them or railroad them, but let them take the time to learn whilst carefully crafting moments of insight and learning, often as Socratic questions, what ifs, how elses.

With seniors it was more like co-creating or sparring; bringing different worldviews to bear on a problem, to produce something better than either of us would have thought of on our own. Tim is a heck of a programmer, and you always learn something pairing with him.

Tim wasn’t delivering software; Tim was delivering a team that was delivering software. The entire team became more effective, more productive, more aligned, more idiomatic, more fun, because Tim was in the team.

The Worst Programmer I Know

There is a concept on sports teams of a glue guy. Someone who isn't a star but provides the foundation for teammates to thrive.

Shane Battier was the epitome of a glue guy when he played in the NBA. He wrote of what it took on The Players' Tribune. One part that stuck out was:

One way is by never worrying about looking cool. (Not that I was ever mistaken for cool.)

I knew my value was helping us notch victories however I could. So there were certain things that I did to ensure that my team was always as prepared as possible. For example, I used to ask really basic questions during film room sessions.

“Coach, can we run through that last set one more time?”

“Hold up coach, which direction do I roll out of this pick?”

“Wait coach, which player is supposed to switch here if the point guard drives?”

“Sorry, can you run through that set just one more time?”

Yeah, I was that guy.

Nobody likes that guy. I know that.

But there was always a strategy behind why I did it: I always knew that if I had a certain question about a game plan, there was almost always going to be a younger, less experienced player on the team who had the same question but was too intimidated to speak up. Having that question answered could ultimately pay dividends during a game. If the moment of truth comes and that player is prepared, that’s a plus for our team.

Elite 'Glue Guys' 101 - Shane Battier (The Players' Tribune)

This is difficult to capture in metrics. It's more of an eye test or a gut feeling. The team plays better when they're on the floor. Sometimes it's providing support for less experienced colleagues.

If everyone is trying to be a star then the team won't win. Players take possessions off on defence and are disengaged on offence when the ball isn't in their hands. People will look for credit in a win but avoid responsibility in a loss. They will expend time and energy blaming others instead of looking at how to fix the situation. The team will fall apart. They won't reach their goal.

The incentive of winning a championship provides the opportunity for people to find their role in the collective that will provide the platform for success. The incentive of "I need to put myself in the best position to get a new contract somewhere else" will lead to division and losses. A team full of stars rarely wins. Just ask Kevin Durant, Kyrie Irving and James Harden on their experience on the Brooklyn Nets.

You won't win a title without stars but glue guys need their flowers too.

I was also reminded of the Bill Atkinson -2000 lines of code story in Apple from the early 1980s. The story goes that managers decided to track productivity by asking engineers to fill in a form at the end of each week. In the first week of this change Atkinson was working on QuickDraw, a 2D graphics library that he had wrote.

Bill Atkinson, the author of Quickdraw and the main user interface designer, who was by far the most important Lisa implementer, thought that lines of code was a silly measure of software productivity. He thought his goal was to write as small and fast a program as possible, and that the lines of code metric only encouraged writing sloppy, bloated, broken code.

He recently was working on optimizing Quickdraw's region calculation machinery, and had completely rewritten the region engine using a simpler, more general algorithm which, after some tweaking, made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code.

He was just putting the finishing touches on the optimization when it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2000.

-2000 Lines Of Code - folklore.org

The idea of using lines of code written as a metric makes sense in a blunt force trauma sort of way. You can use a hammer to open a door when you forget your keys or you could call a locksmith or pick the lock yourself. The first option may be the quickest to route in and may be necessary in some cases. However, you're going to need a new door afterwards.

Incentives can work in a similar manner. Reward people bugs fixed and there is an incentive to write bugs to fix them later. Track lines of code written and the incentive is to write more code, not better code.

This is why the story of Twitter engineers printing out their code for evaluation by Elon Musk and Tesla engineers made no sense. I didn't care much about Elon Musk before that point but when I saw that story, my feelings were summed up perfectly in this post on Mastodon.

Accountability is important and it is important to measure what is and isn't working. Just don't pick the easiest tool you can think of. Pick the right one.

Take the time to think about how I want my team or company to run. What behaviour do I see providing the most value? How can I reward it so other people will be incentivised to copy it? It's not easy and it will require iterations to make it better.

It will require trust. That can mean giving your team some time to experiment with different approaches to the work. It's not efficient at the beginning. But it will pay in the long run.

It won't require bossware or expensive consultants. We know their answers already. Fire people. Hire contractors, preferably from somewhere cheap. Make your service worse for your customers by investing less time and effort into it. Just don't make it so bad that they leave. Buy competitors to lock up the market. If they don't sell, sue them. Cut prices to starve them out. Jack up the prices when they leave the market. If someone offers to buy you, take the money. Don't bother building a business. That's too hard. Take the money and call yourself an entrepreneur. Pretend that you run a business. Write a book.

While reading Kashmir Hill's profile of Mike Masnick I was reminded of the series she did on "Life Without the Tech Giants" while she was working for Gizmodo in 2019.

It was eye opening to see how much of the digital infrastructure runs through such a small number of companies. Sometimes there is no alternative as their services have been embedded into business and government systems and can't be avoided.

I remember being surprised at how many services ran through AWS. I thought someone with the size of Netflix would be running their own infrastructure.

I'd be interested to see how many services are being run through the 3 largest cloud providers today: Amazon Web Services, Microsoft Azure and Google Cloud Platform.

The series is still worth reading and viewing today.

• Life Without the Tech Giants
• I Tried to Block Amazon From My Life. It Was Impossible
• I Cut Facebook Out of My Life. Surprisingly, I Missed It
• I Cut Google Out Of My Life. It Screwed Up Everything
• I Cut Microsoft Out of My Life—or So I Thought
• I Cut Apple Out of My Life. It Was Devastating
• I Cut the 'Big Five' Tech Giants From My Life. It Was Hell