This is probably my new favourite talk to point aspiring QAdevelopers 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/DCstrategy. 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/DCcoverage, 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 Ceglowskihas made a great living running a bookmarking site for the last decade and a half despite having 152 competitorsas 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 DOSsoftwarehe'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.

JangaFXis a company of like maybe 30 people programming in one of the founder's own languagesbecause they just decided they didn't want to use C++.

Fastmailis a company of about the same size whose business model is basically running Cyrus mail servers and writing a couple UIs for it.

Excalidrawis 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.

TinyPilotwas 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.

Nebulahas 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 SaaSequivalent 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 SaaSbusiness 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, boilermakermight 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.

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 importa 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.

Ninajirachi - Infohazard

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 toastersin 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.

If you wanted to read that paper, it's Out-sourced Profits – The Cornerstone Of Successful Subcontracting.

If you're interested in the state of the art, I know Fabrice Bellard released v3.3 of NNCPnot 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.

Abstract algebra strikes again. You should learn it. If you want a simpler introduction, the talk Add ALL The Things: Abstract Algebra Meets Analyticsis 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 P2Papplications 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 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 $U\left(1\right)$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.

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 AIbubble, 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.

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.

$\left(\mathrm{<abbr\; title="comparisons">C</abbr>}\right(n\left)\mathrm{<abbr\; title="moves/swaps">M</abbr>}\right(n\left)k\mathrm{<abbr\; title="average\; distance\; between\; two\; subsequent\; array\; accesses">D</abbr>}\right(n\left)\right)n$

I really like the idea of stealing the big ideas from a variety of fields and working hard at layering them into a lattice of ideas you can leverage. That's actually what lead me to these talks. Probably wouldn't have read it otherwise. It's what I've been trying to do for at least the last decade. Obviously I'm not a securities trader like Munger, but it still proves valuable in software development.

He's also right about decision trees, though these days you'd probably want at least a random forest. The bigger thing is statistics and how it's become too big to ignore. Learning how to properly build (or train as the kids call it) models on data, especially the instinct to collect such data is now a core skill you should know. You'll have a hard time keeping up with anyone who knows how to routinely do this if you remain math illiterate. Statistics especially, unlike geometry, is a branch of math our feeble human brains are really bad at intuiting. It's why there are so many gambling startups right now. It pays to run the house.