Daniel's been sending us questions for a long time now, and this one arrived less like a question and more like a confession about how he relates to technology.
Which is a very different thing to answer.
It is. So here's what he wrote. He says the AI questions he sends in he buckets under personal continuous professional development, because they sharpen tools he works with every day and raise his professional value proposition. The inventory tool questions are more personal, more practical. And what amazes him about the show is that we solve problems intuitively in ways he can't get out of ChatGPT, that he can throw something at us like, how do I do this on Android, and whether it's solvable or not, he comes away feeling thoroughly briefed.
That's a nice thing to hear, and also slightly terrifying.
Then he gets to the real thing. He's always thought technology should be fun, and the AI era has finally liberated him from the tedious part, namely writing code. He knows a few programming languages. But he suspects he's in the minority of technologists who are happy to let models write it and free their brains for bigger, funner things.
He's not in as small a minority as he thinks.
We'll get to that. He names Linus Sebastian as a top inspiration. Not the better-known Linus who contributed more to Linux specifically, but the YouTube Linus, whose contribution he thinks is purer. Playing around, real camaraderie with the team, a bunch of guys doing what technology should look like at its best. He wonders how they afford the gear, assumes hard work. He shares his own technical writing on blogs and YouTube, and his channel actually started as a note-to-self for an Ubuntu fix so he'd have somewhere to reference it later. His observation is that most good technical documentation ends up devoid of emotion and fun. And he's not into gaming, so he's always felt a bit alienated from that part of the technology landscape.
Which matters for the recommendations.
It does. So the two asks. First: who are other creators and technologists he might connect with who elevated our relationship with technology from a serious subject to be mastered into something fun that serves us and is meant to be played with. Second: for those deep into tech and AI who feel it's become all hard work and less fun, how do we relate to it, and communicate about it, in a way that puts the magic back.
Two halves.
Two halves. So let's take them separately. The people who model play, and the thing that's been draining it out of the rest of us.
The thing I want to be careful about here is that this could very easily become a listicle. Ten YouTube channels for people who like computers. And that would waste the question, because what Daniel's actually describing is two different postures toward technology.
Mastery versus play.
And the reason the second one is interesting is that it's much harder to sustain the deeper you go. Anybody can be playful with a Raspberry Pi in their first month. Very few people are still playful about it after ten years of production incidents.
Which is exactly why the Linus comparison is doing more work than Daniel probably realizes. He frames it as one Linus being more pure than the other, and I don't think that's quite the right frame.
No. Torvalds' contribution is load-bearing infrastructure. The kernel, Git. You never think about the kernel. That's the point of it. It's the substrate everyone else builds on, and it's serious and consequential and he's famously abrasive about it. Sebastian's contribution is cultural and demonstrative. He models what curiosity looks like when it's filmed. Those are different kinds of contribution. They're not competing.
One optimizes for being forgotten. The other optimizes for being watched.
That's the whole distinction in one line, yes.
I want to flag the honest counterweight early, because I don't want it to arrive later as a gotcha. Linus Tech Tips is not a frictionless operation. Twenty twenty-three was a rough year for that channel. There was a GamersNexus exposé, an ex-employee alleging mistreatment and poor working conditions, a production pause amid the controversy, and the channel got hacked in March of that year. Linus stepped down as CEO in May to focus on content.
And none of that contradicts the affection Daniel has for the content. It complicates it. The camaraderie is real. It's also earned, and it was earned through institutional strain that got documented publicly.
Good. Second thread.
The AI era has removed a lot of the tedium that made technology feel like work. That's real. But the relief is uneven, and for some people the fun has been taken rather than restored. That's the part I want to make sure we don't skip.
So start with the framing move itself. Because the interesting thing about a challenge episode isn't the result. It's the shape of the problem.
Take Daniel's own example. Getting absurdly fast internet into a home office. On paper that's a procurement task. You call the ISP, you argue about the install date, you run a cable, you're done. What makes it a game is the framing. There's a goal. There are constraints. There are stakes. There's visible failure, because if it doesn't work you have to show the audience that it didn't work. And there's a team solving it on camera.
The narrative is the product.
And that's different from a review, where the product is the verdict and the process is completely invisible. If a review is good, you never see how the sausage got made. If a challenge episode is good, the sausage-making is the entire point.
A tutorial hides the dead ends.
A challenge episode is made of them. That's why it reads as play rather than instruction. The failure is the content.
Which is a strange thing to say about a technical video, because most technical media is optimized to remove failure. You watch a tutorial so you don't make the mistake. You watch a challenge episode so you can watch someone make the mistake and then get out of it.
And there's something useful in that, beyond the entertainment. Watching someone competent hit a wall and reason their way past it is how you learn to reason. Watching someone competent execute a known procedure perfectly teaches you the procedure and nothing else.
So the two Linuses again, deeper this time. Torvalds' work is invisible when it works. You never think about the kernel. Sebastian's work is visible precisely when it's messy.
One optimizes for the substrate being forgotten. The other optimizes for the process being watched. Both are contributions. Only one of them is legible as fun.
And that's not a knock on Torvalds. It's an observation about what kinds of work can be filmed.
Right. You cannot make a compelling video about a kernel patch that fixes a race condition in the scheduler. Well. You can. I would watch it. But you cannot make a broadly compelling video about it, because the drama is invisible.
Now the camaraderie claim. Daniel says it seems real, and I think he's right, but I want to examine what's actually making it feel real.
It's a team with roles. That's the thing. It's not a solo presenter with a camera operator. There are people whose job is to be wrong about something so somebody else can correct them. There are running jokes that only work because they've been running for years. There's shared failure, which is the big one. When the thing doesn't work, everybody in the frame is in it together.
And that's much harder to fake than people think. You can fake enthusiasm. You cannot fake the specific texture of a group of people who have been annoyed at each other and gotten over it.
But here's the counterweight, and I want to sit on it for a second. The vibe is a product of hard work and real institutional strain. Twenty twenty-three documented the strain. An ex-employee saying conditions were bad, a production pause, a public reckoning. The affection is still legitimate. It just isn't free.
Nothing that looks effortless is. So the budget question. Daniel wonders how they afford the gear. Part of the answer is that they built real infrastructure. Floatplane, their own video hosting platform, launched in December twenty nineteen. That's not a channel that spends money on gear. That's a company that built a distribution business so it could spend money on gear.
Which is a much less romantic answer than the question deserves, and also the true one.
There's also a lovely piece of evidence about their cultural reach. KDE made a video in December twenty twenty-one titled, fixing every Linus Tech Tips complaint. An actual open source desktop project making content about a YouTube channel's criticisms.
That's the tell. When the software project starts responding to the reviewer, the reviewer has become part of the culture.
So let me name the criteria Daniel actually gave us, because I want to apply them rather than just gesture at them. Not into gaming. Camaraderie that feels real. Challenges framed as games. Technology as servant and toy rather than subject to be mastered.
Four criteria. And I want to say something about the last one, because it's the one people get wrong. Technology as servant and toy doesn't mean technology as trivial. It means the technology is in service of something that isn't the technology. The absurdly fast internet isn't about the internet. It's about the fact that a group of people wanted to see if they could do it.
The internet is the excuse. That's the play posture modeled by people who film it. Now the harder question. What happens when the work itself stops feeling like play, and the machine takes the tedious part.
So the strongest evidence for Daniel's position isn't a study. It's practitioners saying it in their own words. There's a Hacker News thread from October twenty twenty-five literally titled, Ask HN, has AI stolen the satisfaction from programming. And the top comment is basically Daniel's exact feeling, independently arrived at.
Read it.
The commenter says, and I'm quoting, in the past I gave up programming because of the endless repetitive tasks. You want to build something cool, but wait, you first need to make an auth system, and by the time you finish that the cool idea is already dead because of how boring and repetitive it all is. AI coding made it fun again.
That's the whole thesis in one paragraph.
It's the whole thesis. And there's a companion framing from a July twenty twenty-six discussion called, engineering management after the cost of code collapsed. The observation there is that repositories have grown rapidly with AI coding, which is evidence that people wanted to build things and were thirsting for the means to do it. The desire was always there. The friction was the blocker.
The cost of code collapsed.
And when the cost of a thing collapses, you find out how much latent demand there was.
Somebody in one of those threads put it more simply. It's quite fun to remove the boring part in programming with AI.
Which is a very unglamorous sentence and also completely true. Nobody's claiming the AI writes the interesting part. They're claiming it writes the boring part, and the boring part was eating the whole day.
Now I want the dissenting camp, because I think the episode is weaker without it.
Agreed, and it's a real camp. There's a December twenty twenty-five essay titled, LLMs Are Not Fun, which argues the field has become, quoting, a hack on top of yet another LLM. There's a commenter on antirez's January twenty twenty-six piece, don't fall into the anti-AI hype, who says LLM output beyond stack overflow autocomplete is abysmal, with subtle insanity. And there's a tenured computer science professor from March twenty twenty-five who says traditional learning programming is toast, because core projects now take students thirty minutes.
Toast.
Toast. His word.
So for some technologists the fun was taken, not restored.
For some, yes. And I think the mechanism is different depending on what part of the work you actually enjoyed. If you enjoyed building things, AI is a gift. If you enjoyed the craft of writing the code itself, AI is a demotion. You've been moved from craftsperson to reviewer.
That's the real split.
And it explains why the same tool makes one person ecstatic and another person miserable. They were doing different jobs with the same title.
Now the research nuance, because I think this is where the honest version of the story lives. The IBM watsonx Code Assistant study, Weisz and colleagues, six hundred and sixty-nine participants plus fifteen usability tests, found that AI assistants often do provide net productivity increases, but, quoting, these benefits may not always be experienced by all users.
Which is the most carefully worded way of saying, it depends.
And the systematic review of in-IDE human-AI experience, Sergeyuk and colleagues, ninety studies, published in Empirical Software Engineering, found that AI-assisted coding enhances developer productivity but also introduces challenges such as verification overhead and over-reliance.
Verification overhead. That's the phrase I want to hold onto. Because it's the answer to the question Daniel didn't quite ask. The tedium doesn't vanish. It moves. It moves from writing the code to checking the code.
So you trade writing boilerplate for reviewing boilerplate.
You trade writing boilerplate for reviewing boilerplate. And whether that's a good trade depends entirely on which one you hated more.
For Daniel it's obviously a good trade, because he said so. He'd rather think about bigger things.
And for a lot of people it is. But I want to be precise about the mechanism, because I think the reason it feels like liberation is subtler than just speed. There's a code review assistant deployed at TATA 1mg, DeputyDev, two hundred plus engineers, A/B tested. Twenty-three percent reduction in per-pull-request review time, forty percent per line. And in that same work they cite UC Irvine research that interruptions cost roughly twenty-three minutes of lost focus.
Twenty-three minutes.
That's the number that matters. Because the win isn't just that the task got faster. The win is that you don't get yanked out of deep focus as often. That's what free up our brains actually means, mechanically. It's not that you have more hours. It's that the hours you have are less fragmented.
That's a much better answer than, it's faster.
It's a much better answer. And it's the one that explains why Daniel feels liberated rather than just more productive. He's not doing more. He's doing the same amount with fewer interruptions.
And for the concrete numbers on the does-it-actually-help question. GitHub Copilot at Zoominfo, four hundred plus developers. Thirty-three percent suggestion acceptance rate, twenty percent of lines accepted, seventy-two percent developer satisfaction.
Seventy-two percent satisfaction is the interesting number there, because it's high but it's not universal. Almost a third of developers in that deployment were not satisfied. Which lines up with everything else we've said.
Now the documentation thread, because I think this is the part of Daniel's prompt that's most under-discussed and most interesting.
It's the part I want to spend the most time on, actually. His observation is that most people who do technical writing and are good at documentation end up writing stuff that's very good but also a little devoid of emotion and fun.
And I think that's structurally true, not a failure of the writers.
It's structurally true. Documentation optimized for completeness and neutrality is hostile to voice by design. A manual, an API reference, an RFC. Those documents are written to be unambiguous and to outlive the person who wrote them. Voice is a liability in that context. If your API docs have a personality, somebody's going to complain that they're unprofessional.
So the format selects against fun.
The format selects against fun. Which means the fix isn't to try harder to be fun in a spec. The fix is to write in a different format. Narrative structure. A problem, a failed attempt, a fix, a feeling. That's where voice survives.
And Daniel's own origin story is the proof. His channel started as a note-to-self for an Ubuntu fix, so he'd have somewhere to reference it in a few months.
Which is exactly the archetype. The best technical writing starts as a note-to-self, and that's precisely why it can carry voice, because it was written for a person. It was written for one specific person, who happened to be the author, and that person is allowed to have feelings about the problem.
Whereas a spec is written for nobody in particular, which is why it sounds like it was written by nobody in particular.
That's the whole thing. Write it for a person. Ideally yourself, six months from now, who has forgotten everything and is mildly annoyed.
Now the AI-era twist that ties both threads together. As AI writes more boilerplate docs, the human differentiator becomes voice, story, and judgment. The parts the model can't fake.
And I want to flag something honestly here. When we went looking for discussion of this, technical writing, documentation, the boring-personality-voice problem, there was essentially nothing. No thread, no essay, no argument. Which is a mild signal that this is an under-discussed topic. I want to be careful and call that an observation rather than an established fact, because absence of discussion isn't proof of anything. But it's suggestive.
It's suggestive. And it tracks with Daniel's experience, which is that the good documentation is emotionally flat and nobody seems to think that's a problem worth solving.
Nobody's writing about it because the people who are good at it are busy writing specs.
The arc closes here. The play doesn't come back automatically when the tedium leaves.
It doesn't. That's the part I want to be very clear about. Removing the boring part is necessary but not sufficient. If you remove the boring part and then point the freed attention at nothing in particular, you don't get play. You get scrolling.
You get the auth system replaced by the infinite feed.
The play comes back when you point the freed attention at something you actually wanted to build. And when you write about it like a person instead of a spec.
Hilbert: Question for the two of you.
Go ahead.
Hilbert: When you were describing the challenge episode, the one where they get the fast internet into the home office. Who do you think ran the cable?
I don't know. Somebody on the crew.
Hilbert: Right. I did a stint doing in-house A and V and network installs for a small production company. That was the job. Running cable through drop ceilings, terminating ends, labeling patch panels. And then somebody else would film the fifteen-minute video about the finished room. Nobody ever pointed a camera at me. I have opinions about this.
I imagine you do.
Hilbert: I don't think the show is fake. I want to be clear about that. The play is real. The camaraderie is real. But the fun on camera is downstream of a lot of people doing the boring part off camera. And the boring part is where I lived. Technology as play has a labor floor. Nobody films the labor floor.
That's a fair correction.
Hilbert: I still have the label maker from that job. Best object I've ever owned. You put a label on a patch panel and the ambiguity just leaves the room. I used to do it on my own time. After the job ended. Just for the pleasure of it.
A label maker.
Hilbert: Anyway. I'm needed to let somebody in somewhere. I'm the only one with the key.
Which leaves us with the question Hilbert just put on the table. Somebody has to terminate the ends.
Somebody does. And I think that's the thread to pull on as we close, because it reframes the whole thing. If the tedium is being removed, the question isn't whether that's good. It's what we're pointing the freed attention at. The liberation is only worth something if something gets built with it.
The verification overhead is the new tax. The tedium shifted rather than vanished. Whether that trade is good depends entirely on whether you'd rather write boilerplate or check somebody else's.
From Hilbert's thread, the filmed version of play has an unfilmed labor floor. Worth remembering the next time a challenge episode makes it look effortless.
The magic was never in the technology. It was in the posture. And posture is a choice you make again every time you sit down with the thing.
Thanks as always to our producer, Hilbert Flumingtop.
This has been My Weird Prompts. If you've got a question, email us at show at my weird prompts dot com. We read everything.
We'll be back soon.
See you tomorrow.
