If I could go my whole life and at the end have solved more problems than I created, I'd be really happy. Most solutions create new problems.
This is probably my new favourite talk to point aspiring QA developers at. It's comprehensive in a way that a lot of other testing talks are not. Others often focus on just one technique for testing software, while this shows what a whole testing methodology looks like. Excellent craftsmanship.
I do like the MC/DC strategy. I know I normally complain about unit tests, saying you should be spending your time fuzzing instead. But if you're using unit tests to actually do full MC/DC coverage, I'm back on board with your testing strategy.
The talk's advice on explicitly abstracting your platform layer so you can substitute simulations is also excellent. I think a well-designed platform would actually provide this out of the box (letting you substitute a syscall table during tests, for example). For a talk specifically about this sort of thing, see: Designing Dope Distributed Systems for Outer Space with High-Fidelity Simulation.
Maciej Ceglowski has made a great living running a bookmarking site for the last decade and a half despite having 152 competitors as of writing this post. I'm not sure why he stopped giving conference talks, but I suspect it's because he was using that as marketing and he's pretty happy with how many customers he has and would rather go enjoy his life.
Steve Gibson runs a company of 3 people on basically the same piece of DOS software he's been selling for the last forty years. He programs in assembly, takes years to ship new things, and spends most of his time making freeware and hosting a podcast for marketing. Pretty sweet gig.
JangaFX is a company of like maybe 30 people programming in one of the founder's own languages because they just decided they didn't want to use C++.
Fastmail is a company of about the same size whose business model is basically running Cyrus mail servers and writing a couple UIs for it.
Excalidraw is also roughly the same size and is probably one of the most widely used diagramming tools in software development precisely because they have great taste and didn't succumb to the temptation to try and cram every possible feature into it, destroying the effortless ease of use the tool provides, unlike their competitors.
TinyPilot was a one-person project until he sold it. Simple problem, simple solution. Niche market with mostly cheap junk for competitors. Welcome to the eternal cycle of a race to the bottom and rebirth by a premium competitor that you find again and again. If you think something you use sucks, prove you can do it better.
Nebula has basically become the YouTube alternative for educational content creators sick of saying dumb shit like "unalive" and "digital contraband" when discussing the world and its many problems.
Look, I could go on but the software development cultural narrative has just been thoroughly dominated by a rat race to pleasure venture capitalists ever since the dot-com bubble. There are more ways to start and run a successful company than to sell your company to investors. Like a lot more (cooperatives or partnership investment, contracting-to-cash-flow, crowdfunding/pre-commitments, research/innovation grants, etc.). Just pick any model where you get cash flow early and then use that to iteratively fund more ambitious projects. You also don't need to be a unicorn. Stop LARPing as Facebook and just design and build software and hardware people will actually pay for. Be too niche for the broligarchy to care about.
I also challenge the "wisdom" that customers always want more features in their software. It's the SaaS equivalent of the gaming industry idea that gamers just want bigger games that take longer to complete. Many people I speak to honestly want software to stop with all the updates. Solve a single problem extremely well and then just stop. They don't want to pay for TV/VCRs supporting dozens of barely used features. That's why people used to pay a premium for Apple products. They were by every measure less full of features and cost more than PCs, but they had everything you needed and "just worked." Lots of time spent redesigning it over and over again to remove everything that got in the way. It wasn't the round corners and whitespace that were easy to cargo cult.
The hard part of all of this is finding a genuine reason someone would pay you for a piece of software. What are you providing them they can't get from an LLM? If you think this is a tough question, I don't think you're cut out for this sort of thing. Like, this exact same problem is how the whole SaaS business model was invented. Everyone keeps pirating my software and open source versions exist. Innovate! The majority of people don't like running servers. If I did that for you and the software "just worked," you'd pay me a bunch of money to never have to think about how to do a database migration between updates ever again. You could even open source the thing. It's the database that's valuable (among other things depending on the business). We've just been reskinning databases for the last two decades. I'm not convinced that's really changed for everyday people or businesses who might try vibe coding an alternative. You can always save money by cutting your own hair. Running a long-lived database still seems hard. Having great taste in design still seems like a rare skill.
As anyone vying for a superstar job knows (actors, athletes, astronauts, orchestra musicians, writers, academics, etc.), having just one skill is maybe not a great long-term strategy. Diversify! Learn manufacturing, medicine, and agriculture. Learn philosophy, history, sociology, and fine arts. Learn naval, aeronautic, locomotive, and automotive engineering. If you're really done and want to go into the trades, boilermaker might be the least well-known and most in-demand. At least it has been for the last decade. Just spend some time learning new things, especially new skills. Things you can do, not just things you know.
It's weird seeing Mitchell Hashimoto's philosophy. I already kind of do a version of that for my own projects. I don't often fork but more often just learn from others and then create my own better version that fits the task at hand. It depends on what you count as a dependency, but I have some number you can count on two hands for this website including the OS and database and such. I've written my own tools for a number of things where I thought I could do a more minimal version for my needs. I just don't like bloat, so in a way I ended up at the same place as the fork model.
And yet, when it comes to third party dependencies I run, I advocate for basically running on their release branch. A dependency you suddenly need to update after being left fallow for some time generally involves major changes and risk. And because I only run a hand full of fairly large reputable dependencies with few transitives, it's pretty easy for me to trust the process.
The hardest thing I've come up against is that both of my philosophies are pretty unpopular where I've worked. It really is the case that dependence is a cultural phenomena. If I don't know exactly what it's doing, I get frustrated. Other people get frustrated if they can't import a solution to their problems and be done with them.
When it comes to security problems though, I've lost count of how many "security updates" I've had to patch that have nothing to do with the dependency as deployed in our application. Patching "critical" vulnerabilities for obscure non-default configurations in components we don't even enable. Fork and prune saves significant overhead on all of that. The code is now internally maintained. A real part of the software and not some box you call into and pretend has zero overhead. You also get to actually read the dependency. At least for source dependencies. You'd also be much more aware how many binary blobs you actually depend on. To any Python programmers reading, you might be surprised how many binary blobs you depend on.
It also means you're free to reshape it because it lives in your software, not along side it. You're also free from someone else arbitrarily imposing changes on you. You acknowledge that it's your responsibility. It always was. Adding any dependency to your code takes on the responsibility for the actions of its maintainers. You just pretend that it's a line in a dependency file and not really your problem.
One of the interesting ideas was how the number of dependencies for a project could be related to the tooling for this problem. I'd like more data to see if that's really a trend or if it's a sampling artifact in their data. The problem with the fork model could just be there isn't tooling that encourages it and makes it simple to maintain. Interesting problem space. It's possible LLMs could make it easier to let you fork a dependency, slim it down to just the things you need, then track security patches in the upstream and compare them to your fork to see if you need to fix anything.
There's a bunch of absolutely banging quotes in this. I'm also apt to agree. The post itself claims to talk about the internet, but I don't see the line between internet and real life anymore. The mantra of the 2020s is, "If I conned you, that's because I'm smart." It's a pretty degenerate way to run a society. It's also a case of bad money driving out good. An economy run on deception doesn't seem stable in the long run, but it will produce enough jackpots to keep the illusion alive up until a few people own just about everything. At that point the poor masses no longer matter because markets only count ballots in your wallet.
You'd think you'd want something in your society to counter balance exponential runaways like this, but most people gave up on government and political power in the 70s and 80s, self-assured that individualism could solve all problems thanks to the boom in superhero narratives of the 40s.
So many great takeaways in this. I spent a bunch of time "summarizing" for my post here but it practically became a text transcript with different words. Just hit after hit.
Yeah, this conference did not disappoint. This is huge! I run OpenBSD so I'm already totally fine to trade some performance for security. It's obviously not perfect (send patches), but this is one of the coolest projects I've seen in a long time. Like old school, you didn't think it was possible, well you're wrong because I did it.
It's not compiling the Linux kernel yet, but userland was covered for enough to do LibreOffice at least. Really exciting stuff for a spare time project. It'd be really cool if the Webkit, Firefox, or Chromium team took on the challenge of submitting patches to be able to compile those projects with Fil-C and have the first fully memory safe flagship browser (even if just as an optional build). OpenBSD might be easier than Linux given its smaller target, included userland, and still being just C for compilation.
You're seeing the same thing with the United States of America's attempt to re-industrialize. You can't just vertically integrate again after outsourcing. Once you outsource a business function, it has to be completely redeveloped in-house from scratch if you want it back. That's because all the process knowledge is lost. It sticks with the employee and doesn't transfer except through apprentice style, hands-on tutelage. That or you go the much slower trial and error route at even greater expense. At larger scales where a whole sector has deskilled, you run into missing supply chains which require you to bootstrap even taller verticals.
I think he overplays his, "No good engineer will want to work at your toaster company." It's not that good engineers will walk (some will but not all), but what would they practice all day? They'll spend all their time implementing product and marketing demands based on what they can source because that's what most of the company now does. They won't be tinkering with production lines, tooling, or fabrication where they would spend their time thinking about how to improve the things that make a more functional toaster. I mean, we had much better toasters in the past. You'll end up retraining your engineers who know how to build a toaster into engineers who know how to source a toaster.
I've dropped my Clownflare "CDN" mirror and plan to move my authoritative DNS off as soon as I find the time to do all the work involved (managing your own DNSSEC is a bit of a pain, but look what taking the lazy way out did). Really sorry for this gross invasion of privacy. If you've been using ve3zsh.ca you weren't impacted by this.
Most interesting to me was the claim that around a fifth of the system needs to be in exploration to prevent monoculture collapse. Their graph showed that at 30% you had 100% surviving diversity. Where exactly did this data come from? What was the methodology? Why is it so linear? I'm most curious because if it's a robust figure, it should translate to the myriad of systems we have plagued by diversity collapse.
Other than that, a lot of good data points under one roof looking at our monoculture problem across verticals.
I kind of feel bad sharing this from my lecture backlog because it seems every professional YouTube creator is suddenly talking about how AI and compression are related. However, here's a video not in that sphere of influence if you, like me, just really want to know more about the nerdy details involved in compression applications in real, well, applications. Things like using UDP packet lengths as a way of encoding extra zero bytes between packets.
If you're interested in the state of the art, I know Fabrice Bellard released v3.3 of NNCP not too long ago. Just know, it's probably not a good daily driver. It's designed for maximum compression over English text with less regard for the memory and time required. Again, compression is all an intelligence game.
I don't do a lot of animating, but this technique makes it really approachable. I love the game animator's Hippocratic Oath, "First, do no harm to the gameplay."
Can confirm, this is absolutely the way. Run events for communities you're involved with over years. It's totally worth it for all the social benefits it bestows even if it means donating half your PTO or some of your hobby money to make it happen.
In case you missed CRDTs when they got really popular a few years ago, this is a decent introduction.
Abstract algebra strikes again. You should learn it. If you want a simpler introduction, the talk Add ALL The Things: Abstract Algebra Meets Analytics is more approachable. In this talk you'll get exposure to the importance of lattice spaces, and specifically join lattices. These are useful not just because their symmetry is pleasing, but because they provide a tool to help you visualize all permutations of operations on the space. This lets you check your design for missed associativity, commutativity, and transitivity.
I'm not sure where I stand on CRDTs. If you're stuck with the space and time performance penalties they impose, it should be a problem where there really isn't an alternative. Very few applications really have to be offline-first. With most people limited to phones, there's not much call for P2P applications these days since their owners (Apple and Google) prohibit such uses. There's only so many people living on boats or battlefields.
I struggle to find a situation where you need disconnected concurrent editing of a shared data structure that merges without conflicts. Even in documents, who wants to write a bunch of stuff in a section someone else deleted, only for it to disappear when they come online? The section was deleted, that's the correct merge algebraically. Still doesn't seem right to the user.
So I'd suggest learning the algebra. Apply it in designing your systems. Don't think of using CRDTs as adding a feature. Think of them as a set of protocol properties, like idempotency, for solving distribution problems. That's why I think it's worth watching this talk. Understand how this sort of thing works so you can implement it if/when it makes sense in your work.
I mean, not a novel insight on my part, but Feynman really is an amazing explainer. This was so much fun to listen to. He's completely right too. Everything reduced to something so easy I think anyone could comprehend it. It's also great to dig back into the fundamentals. Always keep yourself in them. They often help you think novelly about something others are taking for granted.
I love that he stopped at the transistor and my brain just kept going. A transistor works because a voltage at the gate creates an electric field that opens or closes a channel for electrons. And an electric field works because charge creates a field that exerts force on other charges. And that works because of gauge symmetry, which requires the field as the price for local phase invariance.
The problem of pattern recognition is interesting. It's true that in the last 50 years since this talk we've made significant strides in solving such problems. We're at the point we have enough computing power we can work with natural language to a really impressive degree. I'm curious what pattern recognition problems still evade us at this point. The big one that comes to mind is in reducing the amount of input data required. Right now we need an enormous amount of training data for these models relative to what a human seems to need. Reinforcement learning always seems promising, but existing techniques are so fragile and slow compared to supervised learning.
It's at least refreshing to see people freaking out about computers taking jobs a half a century ago and watching someone else try and explain to them they're asking the wrong question. I find it so exhausting being asked if the word guesser will turn us all into paperclips. Same for the question about if the computer will become Big Brother. I mean, a Manhattan Project contributor is maybe not your best steward of ethical philosophy. That said, humans are adaptive adversaries, so while more surveillance is happening than ever before, it still hasn't stopped dissent or régime change. We're just better now at distracting ourselves to death.
We're still trying to fix the mess we created with the car over the last century. We haven't even begun to undo the mess we've made with the smartphone. Let's give chatbots to everyone! To be clear, these technologies can be great when used in their ideal niche, but it's the forced mass adoption that unlocks chronic problems. Monied interests bending the fabric of society to perpetuate them. Large monocultures are inherently fragile. When faults occur the shock ripples system-wide, with no alternatives to absorb it.
The comments about how clueless Americans are about the rule of law being like an infallible law of physics is funny in hindsight now they have an active paramilitary kidnapping their neighbours, run concentration camps across the country, and are building out one of the largest dragnet surveillance networks in history.
With the AI bubble, maybe we're at the end of investor story time? We've got every investor locked into a race for a commodity based on the story that computers will soon become god. Sounds like we're at the end of a JRPG. I'd speculate it's the end of the road for tech VCs but it looks like they're trying to unload those assets onto pensions and retail investors.
Decentralization is the right goal, but it will require regulation to scale. Left unchecked, markets naturally concentrate power. Any initial advantage lets a player absorb competitors, compound their strength, and repeat. If we want to stop monopolies from swallowing our institutions, we need to act soon, before policy-making and even enforcement are fully outsourced.
That comment about recognizing a problem, and agreeing on the problem, is absolutely the first most important step. Without consensus that a problem exists, any attempt to fix it is doomed to derail. I have seen this fail too many times. Everyone must agree on the diagnosis and be willing to act. This will be difficult. Powerful interests profit from the status quo and will actively resist recognition, let alone solutions. The decades-long fights over the greenhouse effect and tobacco prove how hard it is. Today, manufacturers add a battery to rebrand cigarettes as blueberry vapes, while bookies run apps or games to call it a prediction market or loot boxes rather than illegal gambling. As long as exploitation is profitable, these battles will continue.
I've gone on record before to say, stop teaching sorting algorithms. They're not interesting. Teaching early Computer Science students sorting algorithms is a form of ritualistic hazing at this point. Teach them convex hulls instead. Full of graphics and tons of obvious practical applications to the beginner or interdisciplinary studier. However, this is a great talk. So watch it anyway.
The big reason is that this is what real performance looks like. This isn't some theoretical big-O notation view of the world. This is how real computers work and how they really don't align with that simple model everyone was taught.
