benmathes

The appearance of heroic efforts to get authoritative lists of what datasets went into which major model versions prevented actual data laundering (up to intent and mistakes). But don't attribute malice to that which is far far easier to explain with coordination headwinds: https://komoroske.com/slime-mold/

Don't attribute to malice what is better explained by coordination headwinds in extremely large companies.

The engineering around tooling wasn't remotely the issue. It's getting all the (thousands?) data researchers mostly iterating on fine tuning datasets that would get bristly if they couldn't work outside version control in a python notebook iteratively tweaking their dataset that processed and reprocessed a few datasets until a threshold was reached.

The only _guaranteed_ chains of custody are down at the compute job and file read level. Which in a massively distributed computing job is... [redacted] nodes reading [redacted] fanouts of "datasets" that is just an abstraction over [redacted] individual files.

There's no malice here. Just way way way more complex than you'd first think.

All of your points are valid, and believe me I was trying to make them. The problem is one of culture. Most of the people doing this kind of work didn't like version control, and their work was really just running notebooks (like iPython or Google Colab) until a number was good enough and they'd submit the file for inclusion into training runs.

You can call it a policy failure, but these people were in very high talent demand and so top down dictates would risk "X people leaving lab Y for lab Z" headlines and morale hits.

I am not saying this is good. I am telling you that on the ground it is so much messier than it should be.

I worked in the tracing and tracking all the thousands of data sets that got tweaked and permuted and changed hands between thousands of researchers and data engineers at a major lab. The data that goes into training runs is permuted so much from the OG data that tracing the lineage is not trivial (dramatic understatement).

And the difficulty is harder than just the extreme scale of text searching. but also explodes with organizational difficulty since there are so many people tweaking/shifting data independently upstream of the actual training run, and no they will not all add the telemetry you wish they did.

In the ideal, should it be this hard? Well, no, but that's org wrangling for you.

that many people likely live in different timezones, or have conflicting meetings, etc. etc.

One model I've seen is moving the review stage to the designs, not the code itself.

I.e. have a `planning/designs/unbuilt/...` folder that contains markdown descriptions of features/changes that would have gotten a PR. Now do the review at the design level.

in 2020 we lived through the extreme left's remedial lesson in public safety. Now we're living through the MAGA right's remedial lesson in trade policy.

(Most MAGA right know this, don't care, see tariffs as a hammer. But they are hitting all of us)

XKCD has a good video about this. The top of the water is remarkably safe, and a life vest would keep you up there! https://www.youtube.com/watch?v=EFRUL7vKdU8

I see the value here. The problem isn't just the search; it's the trust. The biggest hurdle for Zenode won't be the tech, but convincing an engineer that your AI's summary of a footnote is accurate enough to risk a $10,000 board spin. That's a high bar.

I'd argue the core value isn't just a better search or a faster reader. It's about providing a verified, reliable source of truth. This brings up a key tension: you say the AI isn't yet at your co-founder's level of accuracy, but is that precisely the level of confidence required to replace an engineer's manual check? How do you close that gap? You've got the data, but the trust factor is a different threshold?

I.e. maybe you've built the tool to make the problem faster, but the real win would be a tool that makes the problem safer? The killer feature might not be more speed, but rather a confidence score on every AI-generated fact, with a clear path to the source document so an engineer can verify it. It’s not about avoiding the document entirely; it’s about having a better starting point and knowing exactly what to double-check.

"personal" doing a lot of work there :-)

(And I'd be envious of your impact, of course)

With golf, there are other dimensions course designers could use to make the pro game less about distance. Tighter fairways, faster greens, etc.

I suspect this may result in more pitches away to these batters so they have to make contact on the narrower end of the bat.

I.e. it's a move that may well have a counter move.

descriptively: Apple has enough market clout so that it (implicitly) thinks developers will pay the time cost to overcome the lack of documentation and save apple the time it would take to write the documentation. The lever isn't good/bad docs, it's the market dominance apple has in controlling access to high-spend customers.

Similarly, MS was notoriously hard to dev on during MS's period of market dominance. It's a lot more dev-friendly now because it doesn't dominate as much anymore.

Well, sure, but then YC in the _present day_ is collecting value based on what YC was in the _past_.

I had a terrible time trying to find react performance _monitoring_. There's plenty of performance _troubleshooting_ once you already know what component is slow, but nothing that monitors.

Did I miss something? I see some `measureLifecycleperf` functions in the react source but those look like dead ends.

Uber has different share classes with different voting rights

https://www.nytimes.com/2017/06/12/technology/uber-chief-tra... ---------------------------------

Even if a worker sells only 10 percent of his or her stock back to the company, that worker agrees to give Mr. Kalanick the voting rights to 100 percent of his or her stock. Each share of Class A stock comes with one shareholder vote, while each share of Class B comes with 10 votes.

Uber had 545.8 million Class A shares at the end of last year, which included 43.4 million employee stock options that had been issued, according to financial statements obtained by The Times. If all of the early employees who owned those options sold even a small part of their stock to Uber, Mr. Kalanick could control the votes of up to 43.4 million shares, or an additional 7.9 percent of that stock class.

Uber also had 459.7 million Class B common shares at the end of 2016, which included 9.9 million employee stock options that had been issued. If all of the holders of those options sold even part of their stock to Uber, Mr. Kalanick could control the votes of up to 9.9 million shares, or an additional 2.2 percent of that stock class.

Mr. Kalanick does not control those votes until he issues something called a “voting notice,” which requires the employee to vote all of his or her remaining stock in accordance with Mr. Kalanick’s wishes on all matters submitted to a vote of stockholders, according to the agreement. If Mr. Kalanick issued such a notice to a Class B shareholder, the stock gets only one vote a share, which goes to Mr. Kalanick.

Hi Eric, Tiho, Marcus, etc.

This is a fantastic start. Yes, angel.co/clear was complicated. I hope you have better luck driving adoption.

What you are charting at the top is the company exit value. But the UI controls enter info tied to the employee. You should chart the employee's exit value.

You should also put the "or not*" controls as totally optional toggles as an exploratory UI. I.e. the user can toggle "preference" and see what it does to their value.

Is that real return? (i.e. adjusted for inflation)

Or even better, is that comparative performance, i.e. 10% better than a vanguard index fund?

Some of the earliest work that Kahneman and Taversky (think behavioral economics or biases) stumbled upon that told them the brain was filtering/processing unconsciously and incorrectly was hearing focus. Different people would be able to recall strings of numbers played into each ear at varying levels of ability. The better you were at picking up more input streams, the better a bus driver, fighter pilot, or tank captain you would be.

Just have to put away 5k/month to afford a barebones downpayment... in 5 years.

IIRC (8+ years ago), athenahealth was very open with internal data, as part of building an internal culture of honesty and trust. The Exec team walked the walk and showed us very detailed financial info during all-hands.

Fair. I went too terse with the title.

That experience was the instigator. It's why I wanted to make the product.

yeah, hence "at best". There are bigco's where you'll stagnate. There are startups where you'll only learn how to make CRUD apps in rails.

Author here. Yes, that was my stupidity at 24 that cost me over $100k. Woohoo!

Ask away. This is early, feedback welcome.

Loads of edge cases to explore and catch. For the most part, saves the 30-minutes “this is how equity works” conversation, and tries to prevents mistakes on both sides.

True, but startup employees shouldn't be effectively penalized for inexperience in arcane startup securities and tax law.

Yes. Nobody who understands the risk-adjusted rewards of startups does it for the money. Best odds of getting rich? Go work at Google and bank your check/bonus. At best, startups are a faster way of getting experience. [1]

Employees don't even know they are making that bet, though! Most don't even know the details of what they are getting, let alone how to evaluate it. I've been working with AngelList to help fix this, much more coming very soon.

[1]: http://startupljackson.com/post/135800367395/how-to-get-rich...

yeah, log is largely just a cute approximation of that stepwise reality.

"china" and "bubble" makes for more clickable headlines?

The article quotes CB Insights. CB Insights covers all dealflow (that they know of), not just AngelList.