Software Sucks Now - CourtneyR.dev's 2nd Brain

Software Sucks Now 🔗 **Source:** [Software Sucks Now](https://www.youtube.com/watch?v=FI5ba4RRE8U) > [!note]+ Document Notes > tags: [software-quality, tech-industry, software-development] > author: Theo - t3․gg > source: YouTube > reference: https://www.youtube.com/watch?v=FI5ba4RRE8U > date created: 2024-12-19 10:30 > > # 🏷️ Title: Software Sucks Now >  ## 🧰 Action Inbox - [H1] Evaluate current software stack for bloat — consider smaller alternatives #software-audit - [H2] Support independent developers creating focused tools — donate to projects you rely on #indie-support - [H3] Push for stability-focused updates over feature additions — advocate with vendors #stability-first ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Convex Database](https://convex.dev) - [Ghostty Terminal](https://github.com/ghostty-org/ghostty) - [LosslessCut](https://github.com/mifi/lossless-cut) ## 📝 Summary - Software quality is deteriorating across platforms (Windows, iOS, web apps) with frequent crashes and bugs - The root cause isn't AI, programming languages, or frameworks but rather software complexity and age - Projects that work well share common traits: open source, small teams, passionate maintainers, adequate funding - The software we rely on daily (iOS, Windows, social media) hasn't fundamentally changed in 10+ years but has grown exponentially in size - Solutions involve supporting smaller, focused tools by independent developers rather than relying on bloated legacy systems ## 📖 Main Content Theo argues that modern software quality has significantly declined, citing personal experiences with crashes and bugs across Windows, iOS, PlayStation, and web applications. However, he identifies that the commonly blamed culprits - AI code generation, JavaScript/Electron, or lack of memory-safe languages - are not the real issue. The video presents three examples of stable software: Ghostty (terminal), LosslessCut (video editor), and Helium (browser). These share key characteristics: open source, small passionate teams, and maintainers with adequate funding from other sources. Notably, they use diverse technologies (Zig, Electron, Chromium patches) disproving technology-focused explanations. The core problem identified is software aging and bloat. Modern applications we depend on daily are built on decade-old codebases that have grown exponentially. iOS has grown from under 1GB to 13+ GB. These systems now must support multiple platforms, maintain backward compatibility, and integrate countless features added over years of competitive pressure. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/FI5ba4RRE8U?t=0) — [H1] Software reliability crisis across platforms - Key idea: Multiple major platforms experiencing frequent crashes and unpredictable behavior - Evidence: "Windows crashes randomly, iOS bugs constantly, PlayStation won't boot reliably" #### ⏱️ [02:15](https://youtu.be/FI5ba4RRE8U?t=135) — [H2] Daily software failures accumulating - Key idea: Simple tasks failing across multiple applications in short timeframes - Evidence: "Twitter blacking out screen chunks, Uber trips disappearing, YouTube picture-in-picture freezing" #### ⏱️ [04:30](https://youtu.be/FI5ba4RRE8U?t=270) — [H3] Examples of reliable software share common traits - Key idea: Ghostty, LosslessCut, and Helium demonstrate consistent stability - Evidence: "Open source, mostly one person, passion project, maintainer already wealthy" #### ⏱️ [08:45](https://youtu.be/FI5ba4RRE8U?t=525) — [H2] Technology stack doesn't determine stability - Key idea: Programming language and framework choices don't correlate with software quality - Evidence: "Ghostty uses Zig, LosslessCut is Electron, Helium patches Chromium - completely different tech" #### ⏱️ [11:20](https://youtu.be/FI5ba4RRE8U?t=680) — [H3] Rust and memory safety aren't magic bullets - Key idea: Even memory-safe languages can produce unstable software with poor practices - Evidence: "Cloudflare's major outage was caused by Rust code with improper error handling" #### ⏱️ [15:10](https://youtu.be/FI5ba4RRE8U?t=910) — [H1] Software complexity driving instability - Key idea: Increasing expectations and feature competition create bloated, complex systems - Evidence: "Companies rush to add features competitors have, often implementing them poorly" #### ⏱️ [18:30](https://youtu.be/FI5ba4RRE8U?t=1110) — [H2] Broken feature implementations across major platforms - Key idea: Even simple features like chat branching fail in major applications - Evidence: "ChatGPT's branching opens broken tabs, creates non-functional conversation threads" #### ⏱️ [22:15](https://youtu.be/FI5ba4RRE8U?t=1335) — [H3] Scaling problems in engineering teams - Key idea: Code review, QA, and management haven't scaled with engineering team growth - Evidence: "Too few incentives for polish work, massive underinvestment in quality assurance" #### ⏱️ [24:45](https://youtu.be/FI5ba4RRE8U?t=1485) — [H1] Decade-old software stacks creating problems - Key idea: We're using the same core software platforms from 2012-2017 but much larger versions - Evidence: "iOS since 2012, Uber since 2014, Twitter since 2014, VS Code since 2017" #### ⏱️ [27:30](https://youtu.be/FI5ba4RRE8U?t=1650) — [H2] Historical software turnover vs current stagnation - Key idea: Past eras saw frequent platform changes, current era shows unprecedented stability - Evidence: "We switched platforms constantly before settling on current stack for 10+ years" #### ⏱️ [30:10](https://youtu.be/FI5ba4RRE8U?t=1810) — [H3] Software size explosion over time - Key idea: Modern software has grown exponentially while maintaining same basic functionality - Evidence: "iOS 7 was 2.5GB, iOS 18.1 is 13GB - software under 1GB before iOS 7" #### ⏱️ [32:20](https://youtu.be/FI5ba4RRE8U?t=1940) — [H2] Multi-platform complexity multiplying problems - Key idea: Software must now work across dozens of different environments and devices - Evidence: "YouTube changes affect web, iOS, Android, Apple TV, Kindle, Fire TV, Roku apps" #### ⏱️ [35:15](https://youtu.be/FI5ba4RRE8U?t=2115) — [H1] Solutions require supporting independent software - Key idea: Quality improvements come from passionate small teams, not fixing large legacy systems - Evidence: "Support independent developers, use smaller focused tools, demand stability-focused updates" ## 📚 References - [Ghostty Terminal](https://github.com/ghostty-org/ghostty) - [LosslessCut Video Editor](https://github.com/mifi/lossless-cut) - [Helium Browser](https://github.com/helium/helium) - [Cloudflare Outage Report](https://blog.cloudflare.com/cloudflare-outage-on-november-2-2023/) ## 🗣️ Paraphrase - Modern software across all major platforms has become unreliable due to accumulated complexity rather than specific technology choices - Small, passionate development teams with adequate funding consistently produce more stable software than large corporate teams - The software ecosystem has stagnated for over a decade while individual applications have grown exponentially in size and complexity ## 📰 Newsletter **The Hidden Cost of Software Stability** This week's deep dive explores why your favorite apps keep crashing - and it's not what you think. While debates rage about AI-generated code or programming languages, the real culprit is simpler: the software we depend on daily has grown massive while staying fundamentally unchanged for over a decade. **Key Insight**: The most stable software today comes from small, passionate teams building focused tools - not from choosing the "right" technology stack. **What This Means**: Consider diversifying your toolkit. That indie app built by two developers who care deeply about the problem might serve you better than the feature-bloated alternative from Big Tech. **Action Items**: Audit your current software stack, support independent developers financially, and advocate for stability over new features when providing feedback to vendors. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Create content about software stability best practices, showcase indie developer success stories - Education: Workshop on technical debt management and when to choose focused tools over full-featured platforms - Developer experience: Audit documentation tools for bloat, prioritize stability in SDK design #### Community - Maintainers: Establish funding models that support focused development without feature creep pressure - Contributors: Create guidelines for evaluating when projects are becoming too complex - Sponsors: Direct funding toward stability improvements rather than just new features #### WordPress - Core: Implement performance budgets to prevent unchecked growth, establish stability-first release cycles - Core Performance: Profile and optimize existing features before adding new ones - Plugins: Create review criteria that considers long-term maintainability over feature richness - Themes: Develop guidelines for theme complexity limits ## 🧪 Hypotheses - Small development teams (1-3 people) produce more stable software than large teams due to reduced communication overhead - Software stability decreases proportionally with codebase age and size regardless of underlying technology - Economic pressure to match competitor features drives instability more than technical debt - Open source projects with financially independent maintainers show higher stability than venture-funded alternatives ### 📊 Methodology - Comparative analysis of crash rates between applications by team size and age - Longitudinal study tracking software stability metrics as codebases grow - Survey of developer priorities in feature-driven vs stability-focused development environments ### ❓ Questions - What metrics best predict when software will become unreliably complex? - How can large organizations maintain small-team development practices? - What economic models sustainably support focused, stable software development? ### 🔮 Future Research - Analysis of successful platform migrations and ecosystem transitions - Study of development practices that maintain stability during rapid growth - Investigation of funding models that prioritize long-term stability over short-term features ### 💡 Implications - Practice: Prioritize tool selection based on team size and maintainer motivation over feature lists - Policy: Create procurement guidelines that weight stability and maintainability - Security: Recognize that bloated legacy systems present larger attack surfaces regardless of memory safety - Education: Train developers to resist feature creep and complexity accumulation - Funding: Support business models that allow maintainers to focus on quality over growth ### 🧠 Learning Styles Assessment Reading level estimate: 10th Grade (Flesch-Kincaid) #### 👀 Visual learners - Present: Software size growth charts, platform evolution timeline - Improve: Architecture diagrams showing complexity growth, visual comparison of stable vs bloated systems #### 🔊 Aural learners - Present: Video format with clear narration and examples - Improve: Audio-only version focusing on core arguments without visual dependencies #### 🗣️ Verbal learners - Present: Clear definitions of technical terms, relatable analogies - Improve: Glossary of terms like "bloat," "technical debt," comparison frameworks #### 🧩 Kinesthetic learners - Present: Concrete examples with specific software mentioned - Improve: Hands-on exercise comparing indie vs corporate software stability #### 🧠 Logical learners - Present: Clear cause-and-effect relationships, data about software sizes - Improve: Structured framework for evaluating software complexity, decision trees #### 🧑‍🤝‍🧑 Social learners - Present: Community discussion prompts, shared experiences - Improve: Forum for sharing stable software recommendations, collaborative evaluation criteria #### 🧘‍♀️ Solitary learners - Present: Self-contained analysis with clear conclusions - Improve: Personal software audit checklist, reflection questions about tool choices #### 🌿 Naturalistic learners - Present: Ecosystem metaphors for software environments - Improve: Analogies to natural selection and sustainability in software evolution ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, descriptive content - Improve: Add alt text for any software screenshots, describe visual elements #### Keyboard navigation - Present: Video player supports keyboard controls - Improve: Transcript with timestamp links for easy navigation #### Contrast and readability - Present: High contrast video presentation - Improve: Ensure transcript meets contrast requirements #### Text resizing and reflow - Present: YouTube's responsive design handles resizing - Improve: Provide separate transcript page with reflow support #### Media and captions - Present: Video content with generated captions - Improve: Human-reviewed captions, downloadable transcript #### Forms and interactions - Present: Standard YouTube interface - Improve: No additional forms needed ### 🌍 DEIB Assessment #### Cultural breadth - Present: Examples from globally-used software platforms - Improve: Include perspectives from developers in different economic contexts #### Inclusive language - Present: Technical terms are defined, minimal jargon - Improve: Avoid casual profanity, provide content warnings #### Neurodiversity support - Present: Clear structure with timestamped sections - Improve: More frequent headings, consistent formatting #### Representation - Present: Focus on technical issues rather than identity - Improve: Include examples from diverse developer communities #### Psychological safety - Present: Respectful discussion of technical trade-offs - Improve: Content warning for strong language, establish community guidelines ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear logical progression from complexity to instability - Inductive strength: Multiple examples supporting pattern recognition - Causal reasoning: Well-established connection between software age/size and bugs - Analogical strength: Effective comparison between stable indie and unstable corporate software #### Fallacies - Ad hominem: Occasional dismissive language toward competing viewpoints, could be more charitable - False dichotomy: Presents AI/Rust criticism vs support as binary when positions are more nuanced #### Tone of voice - Overall tone: Frustrated but analytical, uses strong language but backs claims with evidence ### 🛡️ DARVO Analysis - Deny: No denial patterns detected - acknowledges software problems directly - Attack: No attacks on accusers - focuses on technical and structural issues - Reverse victim/offender: No victim/offender reversal present - Emotional cues and rhetoric: Uses frustration to emphasize points but maintains focus on evidence-based arguments ## 🎯 Conclusion The software reliability crisis stems from decade-old platforms that have grown exponentially in complexity while remaining fundamentally unchanged. Rather than blaming specific technologies or development practices, users and organizations should support smaller, focused tools built by passionate maintainers with sustainable funding models. The path forward requires conscious choices to prioritize stability over features and invest in alternatives to bloated legacy systems. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] Small passionate teams consistently produce stable software > [!quote] [Software Sucks Now](https://www.youtube.com/watch?v=F --- ## Full Transcript [00:00] Have you noticed that software kind of [00:01] sucks right now? Like in the most [00:03] literal sense. When I use Windows, I [00:05] never know if my computer is going to [00:07] crash randomly when I open a file. My [00:09] desktop started having an SSD disconnect [00:12] randomly. iOS is a total mess. I can't [00:14] even edit a message until it's verified [00:16] that it sent and done a fancy little [00:18] animation when it's done. I have [00:20] everything I'm using just crashing [00:21] constantly. I swear every time I turn on [00:23] my PlayStation, I don't actually know if [00:25] it's going to boot, if it's going to [00:26] crash, if I'm going to have to format [00:28] it, or if my controller won't connect [00:29] because it needs another firmware [00:30] update, like the third one this month. [00:32] What's going on? Why is everything [00:35] falling apart? I tweeted about this a [00:37] few days ago because I had a a rough day [00:39] with software. Twitter was not loading [00:42] when I scrolled. It would just black out [00:43] a chunk of the screen. iOS was bugging [00:45] me constantly. My Uber trips would [00:48] disappear right after I booked them. I [00:50] still can't get picturein picture [00:52] working properly for YouTube. It just [00:53] freezes the video. The audio keeps [00:55] playing at least for like what? How is [00:57] that a problem? This existed for months [00:58] now and the cursor agents failing [01:00] randomly. Thankfully, the cursor team's [01:02] on top of it, but like that was all like [01:04] a few hours. I feel like I'm watching [01:07] the software world crumble in front of [01:09] me and it's getting terrifying because [01:12] software is important for a lot of the [01:14] things I do. And I've not really talked [01:16] about this part of it. I haven't talked [01:19] about this slow spiral of [01:20] inshitification and things just falling [01:23] apart until now. I'm tired. I'm [01:27] frustrated and I want to complain a bit. [01:30] But I have one thing I don't want to [01:32] complain about, which is today's [01:33] sponsor. Today's sponsor is a database [01:35] that's so incredibly flexible that it's [01:37] changed how I build. Much like their [01:38] flexibility with data management, [01:40] they're also quite flexible with how I [01:41] do these ads. So, I'm going to not [01:43] mention them for a bit and talk about [01:44] the shirt I'm wearing. This is the [01:46] Pioneer Way shirt from Y Combinator. I [01:48] got this one of the most recent alumni [01:50] demo day event. Alumni demo day is an [01:52] awesome opportunity for existing [01:53] founders to come meet the new ones as [01:55] they're presenting the things they're [01:56] building. And I noticed a trend. [01:58] Historically, a lot of these companies [01:59] have used the databases that came from Y [02:02] Combinator. There's one particularly [02:03] popular green one that people really [02:05] like that has not been the best solution [02:07] for a lot of these Y Combinator [02:09] companies. I spent far too much time [02:11] talking about data management with all [02:13] of the companies in the current batch [02:15] and ended up just pulling out my laptop [02:16] and demoing today's sponsor, Convex. I [02:19] [ __ ] you not, after doing like a 10 to [02:22] 15 minute here's why I like Convex pitch [02:24] to a handful of founders, one in [02:26] particular just kept asking more and [02:28] more questions because he was so curious [02:31] about it. I got a text at 5 in the [02:33] morning the next day. Hey Theo, I stayed [02:36] up all night because I was so nerd [02:37] sniped by Convex. It solved all of the [02:39] problems we were having and I just [02:41] stayed up porting to it. The port went [02:44] live and I couldn't be happier. Thank [02:45] you for taking the time to explain it to [02:47] me. If you want to better understand all [02:49] the reasons why I love Convex, feel free [02:50] to check out any of the like 12 or so [02:53] videos I've done because I thought it [02:54] was too good to be true and also thought [02:56] that it wasn't really going to be good [02:58] at all. Eventually, after the founders, [03:00] Tanner Lindsley, and webdev Cody all [03:02] independently took time to try and [03:03] convince me to give it another shot, I [03:06] did. And within a month, I had ported [03:08] all of T3 chat over. There's a reason [03:10] that everybody who looks at Convex ends [03:12] up falling for Convex. And it's really [03:14] hard to convey in 2 minutes. So, what [03:16] I'm going to convey instead is that it [03:17] happened to me. It's happening to all my [03:19] friends around me, and it really should [03:20] happen to you, too. Stop building [03:22] databases like it's the 1980s. Build [03:25] something modern that lives in your [03:26] codebase today at soyv.link. [03:28] Blink/convex. So, what is going so [03:30] wrong? Why does so much software suck to [03:34] use right now? I'm going to start by [03:36] going in a slightly different direction. [03:39] What are some programs and some pieces [03:40] of software that don't hurt me every [03:43] time I have to touch them? I wish I [03:45] could put T3 chat here, but we've had [03:46] enough bugs recently. I don't feel good [03:47] doing it. We're working on it. We have [03:49] some really cool stuff coming that [03:50] should smooth it out. But my examples [03:52] are going to be a bit different than [03:54] y'all might think. Ghosty is a great [03:57] one. If you're not familiar, Ghosty is [03:59] my terminal written in Zigg by the [04:02] creator of all of the cool Terraform [04:04] stuff over at Hashi Corp. He left and [04:06] this has been his new pet project. [04:08] Another weird one, Lossless Cut. If [04:12] you're not familiar, it's a huge part of [04:14] how we do our content on this channel. [04:17] It's an open source video editing [04:19] software that is apparently sponsored by [04:21] Warp, which is cool. is a very simple, [04:24] not necessarily the prettiest looking [04:25] app that lets you losslessly cut pieces [04:28] out of a video. So, if you want to chop [04:30] a few segments and save them and then [04:33] have them to use for other things, it [04:35] makes life much easier. We use this a [04:38] ton for my content pipeline. Whenever [04:40] I'm done streaming, I take the VOD, I [04:42] drop it in lossless cut. I take a CSV [04:45] that I make for my website marker thing [04:47] that takes all the topics I cover and [04:49] puts them in timestamp formats. Drop [04:51] that in lossless cut, hit export, and it [04:54] just does the thing. It's incredible. It [04:56] makes our lives much easier, and it just [04:58] [ __ ] works. The one or two bugs I've [05:01] had with it were because of Windows file [05:03] system changes, and the maintainer, as [05:05] soon as he saw them, had a fix up within [05:07] hours. I donated a bunch of money to [05:09] them because I was really pumped. Miffy [05:10] is incredible, and I'm very thankful [05:12] that he is working as hard as he is to [05:14] make something this good. Another I've [05:16] been enjoying a lot is Helium. also Zen [05:19] to be fair, but I found Helium to be a [05:21] surprisingly not buggy experience. The [05:24] first couple releases had their issues. [05:26] Believe me, I complained a lot to the [05:29] team, but they've been resolved for the [05:31] most part. Just yesterday, I had a bug [05:33] that I was convinced was Helium where [05:35] when I use my hotkeys through uh I use [05:38] rectangle for my window management [05:39] hotkeys. Control option left and right [05:42] does split views and then enter does [05:44] full screen. Whenever I did this, I'd [05:46] get a little error popping up saying the [05:48] window can't be focused. And I was [05:50] convinced that the update I had just [05:51] done on Helium was the cause of it. So, [05:54] I went and I flamed Wo for it. Wo had no [05:56] idea what could have possibly changed. [05:58] So, I decided to reboot my computer and [05:59] see. And I couldn't reboot because there [06:02] was some weird app or some thing that [06:04] had happened to maybe Helium that was [06:06] keeping it from being able to boot or [06:08] focus or really use my computer. hard [06:10] reboot later by holding down the power [06:12] button and everything is fine because [06:14] the bug was not Helium. The bug was Mac [06:17] OS because this platform is [ __ ] [06:19] crumbling. Not only is Mac OS slowly [06:22] falling apart, I actually learned [06:24] earlier today that they cut the bug [06:26] bounty payouts for security research on [06:28] Mac OS by over 75%. [06:30] So, if you do find issues in Mac OS, in [06:33] particular, security issues, you're [06:34] going to be paid significantly less than [06:36] you used to be, despite the fact that [06:38] Apple's a multi- trillion dollar company [06:39] with a shitload of money in the bank. [06:41] Yeah, iOS and Mac OS were like the two [06:44] stable things in my life, and they're [06:45] going to [ __ ] too. Here's a fun one I [06:47] had yesterday on my iPhone, the one [06:49] device that used to be stable. Watch the [06:51] top bar when I unlock the phone. [06:54] Do you see that? Do you see how it [06:57] stayed in the blur state? I unlocked my [07:00] phone and the topnav went blurry and I [07:04] could open up control sensor to make it [07:06] unblur temporarily and it would reblur [07:08] itself. I had to reboot my phone to fix [07:11] this. That's some Android [ __ ] We're [07:15] not talking about the bad things. They [07:16] were supposed to focus on the good ones. [07:18] So Ghosty, Los Cut, and Helium are the [07:20] first things that come to mind when I'm [07:21] trying to think of software that is [07:23] stable and reliable and making my life [07:25] better. I really sat here trying to [07:28] think of other things that are good [07:29] enough to hit my bar here. Chad even [07:32] gave a bunch of suggestions and none of [07:33] those quite met either. It's kind of [07:36] tough out there. So, what do these [07:39] projects have in common that aren't the [07:42] case for other things that might be part [07:45] of why I'm having a much better [07:46] experience with them? Let's start with [07:48] Ghosty. It's open source. It's mostly [07:52] one dude. It's a passion project. And [07:55] the dude is already wealthy. He has made [07:58] his money elsewhere. Lossless cut open [08:02] source mostly one dude passion project [08:06] deserves more money. That's why I [08:08] donated. And if you're interested in [08:09] lossless cut, you should too. Helium [08:13] open source. Mostly two dudes passion [08:16] project deserves more money. [snorts] [08:20] Huh. Interesting. Weird. That's a lot of [08:24] things they have in common. Now, I see [08:26] chat suggesting other things right here, [08:29] like um they're native apps. No, they're [08:34] not. Ghost is written in Zigg and he had [08:37] to do a ton of crazy [ __ ] to make that [08:38] work. Lossless cuts an Electron app. [08:42] It's hilarious how good it is, but it is [08:45] Electron and Helium. Oh, Helium. The [08:50] repo. a bunch of patch files on [08:52] Chromium. [08:54] Yes, it's patches all the way down. The [08:56] composition of these projects on a [08:59] technical level couldn't be more [09:01] different. Another thing that couldn't [09:02] be more different is the way they all [09:04] use AI. They vary wildly in how much the [09:07] maintainers like, use, and support the [09:10] use of AI stuff in their development [09:12] work. The reason I wanted to highlight [09:14] this distinction is because a lot of [09:16] people are thinking that this column is [09:19] the reason we have problems. And I want [09:21] to tell all of you to shut the [ __ ] up [09:23] because you have no idea what you're [09:24] talking about. Two of the three projects [09:26] here are heavily based on Chromium. One [09:29] is Electron and the other is a bunch of [09:31] patches on Chromium. Zigg's really cool, [09:34] too. But the point of Ghost isn't to be [09:35] the best possible experience of all the [09:37] features or even the prettiest UI is to [09:39] be really fast and local and also is an [09:42] experiment by the author who was curious [09:44] about Zigg and wanted to explore it in [09:45] this way. You'll also notice something [09:47] else about this list. None of these are [09:49] Rust based. So, if you think switching [09:51] to the right native language is going to [09:53] solve all your problems, you're [09:54] delusional. Go a step further. None of [09:58] these use Swift UI either. I am so [10:00] [ __ ] tired of the Swift UI brain rot. [10:02] Swift seems like a fine language. Swift [10:05] UI seems like a [ __ ] disaster that [10:07] Apple doesn't know what to do about. If [10:09] you have a list with enough things in a [10:10] Swift UI project, that list will make [10:13] the app barely perform. One of the [10:15] reasons I had to move off of Arc is [10:17] because I had too many files in my [10:18] download folder. And when you had too [10:20] many files in their rudimentary Swift UI [10:23] list, it would crash the browser. [10:25] Someone mentioned Flutter in chat, but [10:26] we're talking about software, not hopes [10:29] and dreams. The technology that you use [10:31] to build your project does not determine [10:33] the stability of the project in any way, [10:35] shape, or form. Rust makes it more [10:37] likely that your project is stable. Part [10:39] of that is because Rust as a language, [10:40] makes it easier to do that. But the [10:42] bigger part of that is because Rust the [10:44] community and Rust the people who pick [10:46] the language are much more likely to [10:49] write software in that way. If you care [10:51] enough to pick Rust, you probably care [10:52] enough to write stable software. And [10:54] good stuff. Thank you for doing that. [10:56] But that doesn't mean Rust is the [10:58] solution to our software quality [10:59] problems. You cannot take an unmotivated [11:02] developer, hand them better tools, and [11:04] get meaningfully better software. The [11:06] problem has almost nothing to do with [11:08] the tooling being used. If you're [11:10] listening to people who are out here [11:11] saying everything sucks because [11:13] Electron, because React, because [11:15] JavaScript is too easy and everybody's [11:17] learning it because y'all need to start [11:18] using Rust, that person doesn't [11:20] understand anything that's going on and [11:22] they're using the state of software to [11:23] get gripes out that they personally [11:25] have. I wish I could sit here and blame [11:28] Swift UI and Flutter for all the [11:29] problems in software. There are problems [11:32] that those things specifically cause, [11:33] but those aren't why my phone sucks to [11:36] use right now. Swift UI is not why iOS [11:38] 26 is garbage. And now for the next [11:41] suggestion, the reason most people think [11:43] this is happening. Artificial [11:45] intelligence. [11:46] Almost every time I hear people talk [11:48] about initification, [11:50] they say this is because nobody is [11:52] reading the outputs of their AI [11:53] generated software and it's the AI [11:56] causing the problems. No, it's not. You [11:59] might remember that massive Cloudflare [12:01] outage that happened in November. Here [12:04] are some fun facts about that outage. It [12:06] was caused by code that happened to be [12:07] written in Rust. A lot of people who [12:09] aren't very intelligent and a handful [12:11] that aren't even developers tried to [12:13] blame Rust for this. Rust is not why [12:15] this happened. Unwrap is why this [12:18] happened. Each module running on our [12:20] proxy server had a number of limits in [12:22] place to avoid unbound memory [12:24] consumption to pre-allocate memory as a [12:26] performance optimization. In this [12:27] specific instance, the bot management [12:29] system has a limit on the number of [12:30] machine learning features that can be [12:32] used at runtime. Currently the limit set [12:34] to 200 which is well above the current [12:35] use of 60 features. Limit exists for [12:37] performance reasons when they a bad file [12:39] that had more than 200 features [12:41] propagated on the servers. The limit was [12:42] hit which would result in system [12:44] panicking. The FL2 Rust code that makes [12:46] the check and was the source of the [12:47] unhandled error is shown below. This [12:49] unwrap call would cause a panic because [12:52] too much memory would be used is my [12:54] understanding. And this unwrap would [12:56] result with an error value that was [12:57] unexpected and unhandled here. This is [13:00] the thing that propagated that caused [13:02] everything to go down. This code was not [13:04] generated by AI. It was written and read [13:06] and reviewed by humans and no human had [13:09] any issue with it. And it was written in [13:11] Rust which should magically solve all [13:13] these problems. Right? This is one of [13:15] the biggest outages that has ever [13:16] occurred in the history of the internet. [13:18] And it did all of the things the people [13:20] bitching about in shitification say that [13:22] you should do. They didn't write it with [13:24] AI and they were using Rust, a memory [13:27] safe language. You would think this type [13:30] of thing wouldn't happen when you do all [13:32] of that, right? Right. No. Lots of other [13:37] things feed into and out of this, but [13:39] there is one thing that is actually [13:42] causing the problems that we're [13:43] experiencing. Software is getting more [13:45] complex. The expectations users have of [13:48] their software go up constantly. The [13:52] size of the projects that people are [13:53] contributing to are growing rapidly. AI [13:57] does play into this because it makes it [13:58] easier to make your project bigger. [14:00] Technology choices play into this [14:01] because when you switch technologies, [14:03] you're probably going to double the size [14:04] of your codebase because you're going to [14:05] use the new one, but also maintain the [14:07] old one because you're not quite feature [14:08] pair yet and now you have way more code. [14:11] The economic incentives that exist [14:13] across these businesses are also driving [14:15] this really hard. When one company [14:17] releases a new feature and their [14:19] competitors don't have it yet, all those [14:21] competitors rush to add it in and they [14:24] often don't do it well. It's a silly [14:26] feature, but when branching was [14:27] introduced as a thing people wanted in [14:29] AI chat apps, both OpenAI and Google [14:32] rushed to add it. In T3 Chat, our [14:35] branching works pretty well. I click [14:37] branch. I click the model I want to [14:39] branch with. And now I have my branch. I [14:42] have my little branch icon that I can [14:44] collect to go back to the original. [14:45] Nice, simple, reliable. And what's [14:47] really cool with this implementation is [14:49] if you branch off of your message, it [14:52] will regenerate using the message that [14:53] you're branching to. So if I want to [14:56] compare how this image gen looks with OG [15:00] Nano Banana, go to Gemini Nanobanana. [15:04] Now it is generating using the new [15:06] model. [15:08] This was not too too hard to implement. [15:11] The team went pretty hard to get it nice [15:13] and smooth and I'm pumped with the [15:14] results of how well it works. But if you [15:16] compare this with how it works in other [15:18] places, it's almost funny. Just last [15:20] month, I was trying ChBT. I did a a [15:23] sbatical effectively where I just used [15:26] chat GBT for the month to figure out [15:27] what features and pieces we needed for [15:30] T3 chat. And holy [ __ ] the branching is [15:33] so broken. Watch what happened when I [15:35] tried here. [15:37] Branch, it opens a new tab with a broken [15:42] view. That button doesn't show anything. [15:44] The menu just renders empty. [15:49] And then when I try doing a follow-up [15:50] generation, it doesn't have a convo ID [15:52] because it didn't create the new branch [15:55] thread properly. And this thread, this [15:58] branch that I created literally just [16:00] doesn't [ __ ] work at all at all. And [16:03] don't get me started. I'm not even going [16:04] to pull up the AI Studio one. Just just [16:06] trust me. However broken you think it [16:08] is, it is worse. And these companies all [16:11] rushed it out because people were [16:12] talking about the feature and some [16:14] engineer wanted the feature. And more [16:16] than ever, the willingness for a company [16:18] to merge things is high. On one hand, [16:21] this excites me because when I was at a [16:24] company like Amazon, when I made a [16:26] change that was useful and exciting both [16:28] to me and to many users like me, getting [16:31] permission to merge it and ship it was [16:32] hard. But as the size of these projects [16:35] grows, as the oversight goes down and [16:37] the desire to keep up goes up, the [16:40] willingness to merge things does too. [16:42] The number of PRs being merged in the [16:45] average project has gone up meaningfully [16:48] if you limit it to projects that are [16:49] actually shipping to users. I don't [16:50] count your vibe coded [ __ ] that only [16:52] you use, if you even use it. I'm talking [16:54] about real software from real companies. [16:56] More companies are shipping more [16:58] software. AI does assist in shipping [17:00] some amount, but the number of PRs [17:02] merging is a thing that is constantly [17:04] going up as the number of employees goes [17:05] up, as the economic incentives go up, [17:07] and as the competition gets harder to [17:09] fight. The desire to ship has never been [17:11] higher. And you can blame AI for some [17:14] amount of this. Like sure, AI does make [17:18] us move faster and it is incentivizing [17:20] the whole industry to accelerate and [17:22] ship more, but that doesn't excuse [17:24] certain things from happening. The [17:26] complexity of the average piece of [17:28] software we use is going up like mad. [17:32] The number of lines of code that Gmail [17:34] was when it first shipped is probably a [17:36] hundred to a thousand times smaller than [17:39] it is today. Almost certainly. The [17:42] amount of layers you have to go through [17:44] to even find where the bug might be, [17:47] much less fix it and ship it is insane. [17:50] And the incentives to do this type of [17:52] work are very low. There are way too few [17:55] incentives for the types of people who [17:57] want to come in and polish. There is a [18:00] super low investment in things like QA. [18:02] Quality assurance is just massively [18:05] underinvested in. Even when I was at [18:07] Twitch, the willingness for us to block [18:09] a release until QA was completed with it [18:12] was relatively low. Engineering teams [18:15] and code bases have scaled like mad, [18:18] even though nothing else has. the amount [18:20] of QA people, security researchers, even [18:22] just engineering managers and people [18:24] willing to spend time reviewing code. [18:26] Those numbers aren't going up anywhere [18:28] near as fast as the number of engineers [18:30] are. Sure, we're having a bit of a [18:32] layoff culture where like 5% of [18:34] engineers at some companies are being [18:36] laid off, but they were doubling the [18:38] number of engineers every year up until [18:39] that point. There are too many engineers [18:42] working on too many things in too many [18:43] places that we all rely on, and the [18:45] complexity of these things has gone up a [18:47] ton. But there's one other really big [18:50] piece here. Our software stacks haven't [18:53] changed in a decade. Let's go back to my [18:56] tweet that kicked all this off. iOS 26 [18:59] is a buggy mess. I've been using iOS [19:01] since 2012. My Uber trips disappear [19:04] after booking. I've been using Uber [19:06] since 2014. Twitter's blacking out a [19:09] third of the screen. I've been using [19:10] Twitter since 2014. And the engineers [19:13] who built the Twitter app I use every [19:15] day quit a long time ago. Cursor agents [19:18] are failing randomly. This is a new [19:21] piece of software that is different, but [19:24] also the only reason cursor could [19:25] succeed is because it's building into [19:27] the VS Code ecosystem by forking VS [19:29] Code. And VS Code has been my editor [19:31] since 2017. YouTube picture and picture [19:34] video freezing is insane, but I've been [19:36] watching YouTube for almost 20 years. [19:38] The software I'm talking about here [19:40] either is over 10 years old or is built [19:44] on top of software that is over 10 years [19:46] old. The trenches have never been [19:48] deeper. The things that we use every [19:50] day, the things that we're complaining [19:51] about the buggess of every day are [19:53] pieces of software that we've been [19:55] relying on for a decade plus. As [19:58] software gets older, it gets bigger. And [20:00] as software gets bigger, it gets worse. [20:03] We've never had an era where the [20:05] software we rely on every day is the [20:07] same as the software we relied on 10 [20:09] years ago. Things normally change much [20:11] faster than that. We went from Outlook [20:14] to AOL email to Gmail and now we've been [20:17] on Gmail for 20 years. We went from the [20:20] original Apple software to DOSs to Mac [20:23] OS to Windows to OSX to Windows to Mac [20:28] OS again. We went from like 500 [20:31] different mobile platforms to iOS and [20:33] Android. We went from tons of different [20:36] social media apps and websites to [20:38] Twitter, Facebook, Instagram, YouTube, [20:41] Tik Tok. The only newish one there is [20:43] Tik Tok. And you know what? Tik Tok [20:45] seems a lot more stable than the others. [20:47] As software gets older, it gets worse. [20:50] And the software we're using today is [20:53] very old. I know the hype's all around [20:56] AI everything. And sure, some of these [20:59] AI things that we use are new and cool, [21:01] but a lot of them are built on top of [21:02] old stuff. It's crazy to think something [21:05] as essential as like Git was changing [21:08] constantly before Git. We changed the [21:10] solution for source control dozens of [21:13] times before we settled as an industry [21:15] on Git. There were tons of different [21:17] operating systems before we settled on [21:18] Mac, Linux, Windows. There were way too [21:21] many mobile platforms. There were so [21:23] many mobile platforms that Java won [21:26] because Java could work on all the [21:27] different mobile platforms with a single [21:28] codebase. The problem isn't that the [21:30] software we're using is made by the [21:33] wrong people or use the wrong [21:34] technologies or AI is taking it all [21:37] over. It's that we have hit a critical [21:39] mass, a point at which we can't really [21:41] return from where the things we use all [21:43] the time are just too big and have too [21:46] much [ __ ] going on in them and they're [21:48] falling apart as a result. And nobody [21:50] wants to move to a new solution because [21:52] part of how these things were built was [21:54] to encapsulate you within them. But [21:57] there are some places that I'm seeing a [21:59] lot of progress here. A huge part of why [22:01] we're stuck on Windows is because of the [22:04] software that only runs on Windows, [22:06] which is why things happening in Steam [22:08] and Valve's ecosystem are so exciting. [22:10] Things like Proton are huge because they [22:12] let us use a stable open platform to run [22:15] software that was previously restricted [22:17] to Windows. And that software fits a lot [22:20] of the stuff here where it's open [22:22] source. It's a passion project and it's [22:24] people who are either already wealthy or [22:26] are getting money from other sources. [22:27] Like Valve makes disgusting amount of [22:28] money and they're pouring it into this [22:30] open stuff because it will let them make [22:33] software that's more stable on devices [22:34] and products that they care about. [22:36] Meanwhile, on the Google side, I'm not [22:38] even using YouTube chat right now [22:40] because whenever the YouTube chat is on, [22:43] it oos my computer on a browser that [22:46] Google made. I use a Google browser on a [22:49] Google media platform with a Google [22:50] stream and it crashes because the chat [22:53] code is broken. On one hand, that's a [22:56] [ __ ] culture problem for sure. On the [22:58] other hand, if YouTube wasn't a bloated [23:00] mess of code, it would be relatively [23:03] easy for them to make a good chat. [23:05] Nobody at YouTube is intentionally [23:07] making the chat [ __ ] The YouTube chat [23:09] sucks because the YouTube codebase sucks [23:11] and there aren't enough engineers [23:12] allocated to work on this. And even if [23:14] there were, the codebase they're stuck [23:16] in is a shitow. And then they have to [23:18] make it work in other places as well. [23:20] You no longer have to just make your [23:21] software for one thing. When you make an [23:24] update for Windows, you have to account [23:26] for all the new Windows computers being [23:28] sold, all of the ARMbased Windows [23:30] computers that now exist and all the [23:32] ancient Windows computers that are still [23:33] getting updates for some reason. When [23:35] you make a change to YouTube, you're not [23:37] just making a change to youtube.com. You [23:39] have to deal with the iOS app and the [23:41] Android app and the Apple TV app and the [23:43] Kindle app and the Amazon Fire TV app [23:46] and the Roku app and the Roku ecosystem [23:48] is a [ __ ] disaster. One of the worst [23:49] things I've ever had to touch. Your [23:51] software now lives in more places, which [23:54] means it's harder to fix, maintain, and [23:56] change. Your software is now much [23:58] bigger, which means it's harder to fix, [24:00] maintain, and change. Your teams are now [24:02] much larger, which makes it harder to [24:04] fix, maintain, and change. Notice how [24:06] none of this has anything to do with AI, [24:09] Rust, memory safe languages, Electron, [24:12] or any of the things most people are [24:13] bitching about. Nothing gets better if [24:16] we start using Rust more. Nothing gets [24:19] better if we stop using AI to help us [24:21] with the code. Things only get better if [24:24] we start diversifying our software stack [24:27] more and taking more opportunities to [24:28] adopt things built by passionate [24:31] individuals instead of staying on the [24:33] things built by these giant companies on [24:35] rotting code bases. AI isn't going to [24:37] save us here, but it's not the cause of [24:39] the problem either. And it seems like [24:41] everybody is on one or the other side [24:43] here where either AI is the reason this [24:45] is happening or AI is going to keep this [24:47] from happening. One of the few people I [24:49] see who seems to get this is actually [24:52] Dax, specifically this tweet. He made [24:54] two points here that people struggle to [24:56] understand both. You either believe one [24:58] or the other, but it's rare people see [25:00] both. And even prime tries to say that [25:02] the two are feeding into each other. The [25:05] first point is that software quality is [25:06] pretty bad. We need to make it better. [25:08] And the second is that there's so much [25:09] software that needs to be built. Making [25:11] it more accessible with higher level [25:12] languages, frameworks, AI services, etc. [25:15] is a good thing. And very few people [25:17] could accept that these are two true [25:19] statements. I couldn't agree with this [25:20] more. That all said, a lot of people are [25:23] blaming software accessibility for [25:25] things going to [ __ ] Spoiler alert, [25:27] software getting easier to write is not [25:29] why iOS 26 is garbage. They weren't even [25:32] allowed to use good AI models at Apple [25:34] until very recently. iOS 26 wasn't [25:37] written with AI or higher level APIs. [25:40] iOS 26 was an attempt to rewrite the [25:42] user layer on top of a gigantic old [25:45] rotting oper operating system. The [25:48] problem with iOS 26 has nothing to do [25:50] with the tech choices. It has nothing to [25:52] do with the engineers they hired. It has [25:53] nothing to do with AI at all. iOS 26 [25:56] sucks because it's the first time they [25:58] did a big overhaul like that on top of [26:00] iOS 18 or anything even vaguely close to [26:03] that. The iOS 7 release was blamed for a [26:07] lot of problems when it happened, and [26:09] the codebase they were building on top [26:10] of was probably 1,000th the size of iOS [26:13] today. Apparently, the iOS 7 operating [26:15] system installed size was 2.5 gigs. iOS [26:19] 26.1 is almost 13 gigs. Do you [26:23] understand? 2.5 gigs, [26:27] 12.7 to 14. iOS was under a gig before [26:30] iOS 7. The problem has nothing to [26:33] [ __ ] do with AI. Anybody saying that [26:35] is being dishonest or is just being [26:37] [ __ ] stupid. The problem here is that [26:39] the stuff we use is massive now. The [26:41] sizes of the code bases for the software [26:43] that we rely on has been going up [26:45] exponentially for a decade. And since we [26:47] haven't changed the software we use for [26:48] a decade, maybe you hop between one of [26:50] the two major options. No one's trying a [26:53] new mobile OS. You might move from [26:54] Android to iPhone and iPhone to Android, [26:56] but you're not trying a new third [26:57] option. Nobody's using a new desktop OS. [26:59] You might try a new flavor of Linux [27:02] every once in a while. And that flavor [27:04] might just be a bunch of bash scripts [27:05] you're running on top of another flavor. [27:07] No one's using new operating systems. [27:09] Nobody's using new software. Nobody's [27:10] using new [ __ ] anything. We're all [27:12] building on top of the same [ __ ] that we [27:14] used 10 years ago. And if you look at [27:15] the tech I use today and compare it to [27:17] what I used 10 years ago, there's barely [27:19] any difference in the things I choose to [27:20] use. But the things I'm using are now [27:23] way bigger than they've ever been. And [27:24] as a result, they are way less stable [27:26] than they've ever been. This is why [27:28] software has gone to [ __ ] And anybody [27:30] who says anything else is trying to sell [27:32] you something or trying to justify their [27:34] own existence. Software has gotten old. [27:36] As such, it has gotten big. And as it [27:38] gets big, it gets worse. It really is [27:41] that simple. And I don't really know how [27:43] we solve it other than to start using [27:45] newer, smaller things that are way more [27:47] limited in what they can do because [27:49] they're going to be more stable. [27:50] Programs that do everything that have [27:52] existed for 10 years will never be as [27:54] stable as an adequately obsessed one to [27:57] three person team building the thing out [27:59] of a passion for it. Support more [28:01] independent software. Use more things [28:03] made by independent passionate people [28:05] built to solve problems that they [28:06] actually have. And keep yelling at Apple [28:09] until they do a couple more OS updates [28:10] that are focused entirely on patching. I [28:12] don't know what else we could do here. [28:14] That's all I got on this one. I'm sorry [28:16] your software is [ __ ] and I'm sorry mine [28:17] is too. Hopefully in the future things [28:19] will start to get better, but until [28:21] then, every time we do an update, we're [28:22] making our things more bloated and [28:24] they're going to keep getting worse. I [28:25] have a feeling it's going to get much [28:27] worse before we start to see it get any [28:28] better at all. Let me know how y'all [28:30] feel about this and I'm sure the [28:31] comments aren't a flame war at all here. [28:33] Have fun with that. And until next time, [28:35] peace nerds.