They do, but only for specific definitions of "work". Like, benevolent dictators in Cuba 100% raised the literacy rate by an insane amount in just a few years (something like 20% => 80%").
If you define work as "literacy", they no doubt succeeded. But if you consider the people (and children) they tortured, raped, and murdered, suddenly literacy doesn't seem so important.
> Turns out, the friction I felt around picking one thing may have actually been beneficial. Perhaps it was actually helping me stay focused. Even if it cost just a bit of extra time before I sat down and worked.
It's point is highlighting a common issue that is becoming widespread due to AI tool proliferation. I have the same exact issues. I used to love sinking into deep work mode but now that's gone.
The dude was born incredibly wealthy: that is how he became successful (not because he's some genius who raised himself up by his bootstraps, and therefore we should follow all his advice).
Ummm ... isn't Selenium technology from the 90's? We've already got tons of alternatives to it (Playwright, Puppeteer, etc.).
If you're making a new product in that space, instead of referencing ancient technology, it'd make much more sense to present it as an alternative to them. Otherwise it's like saying "I've got a great alternative to QBasic!" Great, but I'm already using Python, I don't care about your alternative to dead/old tech.
I'd be more curious as to whether you will need a lawyer for anything else in your business in the future?
If you plan to make a one-man SASS product you might be able to get by without one, and maybe the mailbox makes sense. But if you plan to build a real company (with employees, terms of service, contracts, legal counsel to avoid getting sued, etc.) you're going to need a healthy relationship with a lawyer anyway, so why not start one now?
I am sure I will. But Incorporating seems so easy. There is a five line / half-page certificate of incorporation template provided by Delaware. Easy to do myself if I just get the address worked out.
Before LLMs, learning on the job looked like reading documentation. Now it’s a guided tour with verification. When I produce things in this way, I’m not just blindly accepting it. The goal is that by the end of it I have learned more about the codebase and architecture, not less. I feel that’s important.
Many people don't understand this, even big tech engineers. They see LLMs as a bottleneck. It's more that they don't understand how to use it to multiply their skills, just basics and code gen.
I use multiple Claudes at a time, daily. It's precisely because of that experience that I wrote:
LLM + framework you don't understand goes in ... unmaintainable garbage comes out.
Claude follows code patterns and structure. If you setup that structure and those patterns properly, it will produce great code. If not, it will follow ... whatever it feels like, with each commit.
If you just have it built something with a framework you don't understand, it will do so just fine! But over time every "vibe coded" change you make will drift it further and further, until you are left with a mess of vibe-coded spaghetti.
I agree that's fine in that at least it's doesn't cause unmaintainable garbage. And might even get you up to speed quicker that reading the docs old school.
But the GP point, that you're better off finding people that already, truly understand and are familiar with the tech (ie. Astro), imo still stands.
I read a fun comment the other day from a frustrated windows user who failed to configure linux in previous attempts but now with LLMs it was very easy for him.
I read the first part of this article, then gave up and Googled "Test-case Reducers".
I'm not sure if that's an article failure (that I didn't want to read a whole ton of text and C code details), or a success (as it got me interested in the topic). I guess both?
I read the whole article, and I am still confused. I get that test case reducers find the smallest error causing string. I don't understand why that is particularly valuable.
Also, do test case reducers work on integers or other numbers? What about reducing some other complexity? Is this for developing unit tests or just debugging?
A reduced test case means you run less code to process the test case, which means your breakpoints trigger less frequently (and the remaining breakpoint triggers are more likely to be relevant to the actual bug). It also means all your debugging steps are likely to run faster and produce less data to sort through. Your log files will be shorter and easier to read/grep, etc.
Imagine being handed a sheet of 10 equations and being told "1 of these equations is wrong." Now imagine that someone came in and erased 8 of the correct equations - they just saved you a bunch of time.
Making the smallest test case that reproduces some bug is hugely valuable when debugging complex systems, especially if you have a wierd heisenbug that is hard to manifest reliably. Having a small reproducible case massively narrows the scope of the search for the bug.
Similarly, narrowing test cases to the smallest case that reproduces a particular behaviour so you're only actually testing a very targeted thing will make the test suite faster and also make it easier to fix tests which break because they exercise a very narrow path.
Reduced test cases make it way easier to figure out what the actual bug is. E.g. a real world example is when I tested a "slugify" function with hypothesis. It almost immediately spat out this failing test case:
reply