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.
