Great post! I've worked on a few query generating systems of varying degrees of complexity, and SQL is pretty rough as a compilation target. I've spent more time than I'd have liked wrestling with queries as comparably ungodly as the beauty you have presented.
One trick that I always find helpful is to unroll the subqueries into a long sequence of CTEs. You can do a depth first traversal of whatever data structure produces your subqueries and build a list of CTEs as you go (and track of all the CTE names of course). The ordering 'just works'!
Slightly nicer SQL doesn't seem important at first for stuff like this, but it's actually a godsend for debugging. Every operation in the query gets a name that's accessible in the outermost scope, so you can slap a `select * from cochoice_abc123` on the end and see what's going on.
Figuring out what's going on in those subqueries was no doubt hellish at times.
If you do backend web development in 99% of software companies then being very good at whatever your RDBMS is is a superpower.
It's definitely worth learning SQL very well, but you also need to learn the data structures your RDBMS uses, how queries translate into operations on that data, and what those operations look like in a query plan.
You can go surprisingly far with just that knowledge.
I don’t think this is confusing to the vast majority of people writing Go.
In my experience, the average programmer isn’t even aware of the stack vs heap distinction these days. If you learned to write code in something like Python then coming at Go from “above” this will just work the way you expect.
If you come at Go from “below” then yeah it’s a bit weird.
In my experience (I've put hundreds of billions of tokens through structured outputs over the last 18 months), I think the answer is yes, but only in edge cases.
It generally happens when the grammar is highly constrained, for example if a boolean is expected next.
If the model assigns a low probability to both true and false coming next, then the sampling strategy will pick whichever one happens to score highest. Most tokens have very similar probabilities close to 0 most of the time, and if you're picking between two of these then the result will often feel random.
It's always the result of a bad prompt though, if you improve the prompt so that the model understands the task better, then there will then be a clear difference in the scores the tokens get, and so it seems less random.
You're right that I didn't mean to communicate that, but it's a good point. I agree with you entirely that this is the big downside of YC and frankly all VC backed entrepreneurship. It is not the path of highest expected return for a founder. If you want a high expected return then a FAANG job or a bootstrapped SaaS product you can build yourself are good options. Some days that's what I wish I was doing to be honest.
I think a lot of VC backed founders aren't just in it because they want to get rich though. Sure, we all want that, but we're also all predisposed to irrationally believe that we're the exception. That trait (for better or worse) comes with implications, and many founders I speak to are simply compelled to try because it's hard, and it's theirs, and they're impatient.
I also very much agree with the sibling though. Getting rejected does not carry that much signal, because YC are wrong more than they're right. So just keep trying.
This was not my experience. I have no degree, I'm not American, and I applied back in October 2021 about 3 hours before the dead line and filmed my application video from a coffee shop. I didn't have a good network. I didn't have a product yet. I was accepted first time.
As you say, a lot of YC founders don't have a real business yet, but they're not there because they're well connected. They're there because YC thinks they fit the profile of someone who really wants to build a big business and might pull it off. They're wrong most of the time but it's a numbers game.
One trick that I always find helpful is to unroll the subqueries into a long sequence of CTEs. You can do a depth first traversal of whatever data structure produces your subqueries and build a list of CTEs as you go (and track of all the CTE names of course). The ordering 'just works'!
Slightly nicer SQL doesn't seem important at first for stuff like this, but it's actually a godsend for debugging. Every operation in the query gets a name that's accessible in the outermost scope, so you can slap a `select * from cochoice_abc123` on the end and see what's going on.
Figuring out what's going on in those subqueries was no doubt hellish at times.