zalzal

You probably know this, but just want to say, founder to founder: don't listen to this argument at all.

People are so fond of saying "just wait and the new model will do this." And very smart people I know say it (especially when they work for OpenAI or Anthropic!).

It might be partly true (of course it's situational). But it's a glib and irrelevant thing to say. Model capabilities do not advance like some continuous exponential across all domains and skills. Not even close.

Product design is exploring the solution to human problems in a way that you can bundle and sell. Novel solutions to human problems tend to come from humans, applying effort over time (with the help of models of course) to understand the problem and separate out what's essential and what's irrelevant to the solution.

(A related comment on the adjacent thread.)

100% agree. There is a bigger point too: People assume LLM capabilities are like FLOPs or something, as if they are a single number.

In reality, building products is an exploration of a complex state space of _human_ needs and possible solutions. This complexity doesn't go away. The hard part of being an engineer is not writing JavaScript. It is building a solution that addresses the essential complexity of a problem without adding accidental complexity.

The reason this is relevant is that it's just the same for LLMs! They are tripped up just like human engineers into adding accidental complexity when they don't understand the problem well enough and then they don't solve the real problem. So saying "just wait, LLMs will do that in the future" is not much different than saying "just wait, some smarter human engineer might come along and solve that problem better than you". It's possibly true, possibly false. And certainly not helpful.

If you work on a problem over time, sometimes you'll do much better than smarter person who has the wrong tools or doesn't understand the problem. And that's no different for LLMs.

I'm curious, if you have that philosophy (which makes a lot of sense), you must have considered building is a sort of more abstract (but extensible) UI toolkit language and library and you could code in that then compile it down to React? Or have you found the benefit of large LLMs already having detailed React training is just too high?

It doesn't deal with images at all, but depending on what you're doing it might be useful in cleaning up the OCR text, e.g. asking LLMs to fix errors and then filtering the diffs.

I'm curious if it's useful! How do others try to solve use cases like this of mapping data between docs or strictly controlling LLM edits?

Hey appreciate the note. You can always see the full table of contents here on the about page for the book: https://www.holloway.com/b/making-things-think

And fair point about the login-wall obscuring the TOC. We'll look for a way to avoid that frustration.

There will be shortly. The Holloway format has more features (comments, search, infographic, etc.) than an epub so we launch web at first (today). If you purchase now it includes instant online access and future updates, and that includes upcoming epub and other download formats too.

Josh with the publisher (Holloway) here. Yes, indeed, that's a key feature of our format. Especially expect we can see updates on the chapter on recent/emerging developments and companies/teams.

Readers can also make marginal comments. Do feel free to use these to suggest corrections or additions for the future!

Josh here (one of the authors). Do also feel free to read the latest version of this at https://www.holloway.com/g/equity-compensation

It's the same source as what you can find on GitHub but at Holloway we're working to make long-form docs like this easier to read on the web. PRs or feedback here on the Holloway reader welcome. :)

(Josh, co-founder of Holloway here.)

There are a couple sides to this. No company should or will tell every financial detail to every candidate. On the other hand, if a company has given you an offer and really wants to hire you, yet is very evasive about all the info you need to evaluate your offer, it can be a warning sign; it's likely indicative of the level of transparency you'll get as an employee, too. The 409A is material to understand your stock options, so very fair to ask about before signing.

Also—we'd love more questions like this in the marginal notes in the Guide, so it improves iteratively! If you (or anyone else) wants early access to that feature shoot an e-mail to josh@holloway.com

Josh, co-founder at Holloway here. That's the original content, yes, but we've augmented a lot on Holloway, added comments and search features, etc. Having a couple traffic hiccoughs but try it soon as you get in, and look forward to feedback.

Yes, true. At the moment we don't have any OpsWorks expert contributors. Hope one of you can change that! https://github.com/open-guides/og-aws/issues/123

Those of use contributing on the Guide so far have generally been companies where it's not used. I'd love to see a contribution (a few bullet points and/or links) that better covers the basics and reflects how/when it's useful.

Let us know if you find the PDF helpful? We could post one on the GitHub repo too — though it's so full of links I'm not sure how useful it is.

I understand the concern. We'll try doing something about that. That said, single page on GitHub for the moment means (1) discoverability directly on github.com, which helps everyone and (2) browser search on the whole guide (which actually is more helpful than you might think!).

Very glad to hear. Its this sentiment exactly that led us to get this started. We all have 100s of valuable tricks and gotchas we learn over the years, but 99% of the time fail to write down and share them helpfully. Do join us on Slack/GitHub and help us get your tips included, too.

Thanks for the comment. Added an issue with this thread: https://github.com/open-guides/og-aws/issues/98

If you'd like to PR or discuss there it'd def help us cover this better.

Remember, this isn't a blog, it's living GitHub project: If you see value in info like this, consider contributing or giving feedback to improve it. :)

Thanks! Do join us, even small PRs and or feedback in our Slack group helps!

There is a bigger debate on micropackages, for sure. But even in the sort term, breaking your build instantly every time third parties make changes is just madness. Reduce operational dependencies as well as library dependencies.

This is one approach we used to deal with this last year, for example, on build/devops side: https://medium.com/@ojoshe/fast-reproducible-node-builds-c02...

Separate from the discussion of whether super small modules and hundreds or thousands of deps are a good idea, is the point of operational stability.

Putting on your devops hat, whatever your dependencies, from a reliability and reproducibility point of view, you should control your reliance on unexpected decisions of npm or third-party developers. A lot of the panic with npm issues comes from people blindly using the npm registry and then seeing breakages, with no safety net. I hate to say "I told you so" but this is an issue we worried about a lot when considering Node productionization last year: https://medium.com/@ojoshe/fast-reproducible-node-builds-c02...

The value of shares in most private companies can't be assigned a dollar value (since you can't sell it easily), so that column is meaningless for a lot of rows, including most startups. Also it's important to remember cash salary is often discounted in favor of higher equity at startups.

I think a more relevant column to add would be percentage equity for startups/private companies (subject to vesting). And if you're at a private company and you don't know the percentage, you should ask.

The guide should cover more on this, yes.

Added an issue to track. Please comment there if you have more details. https://github.com/jlevy/og-equity-compensation/issues/31

It's a bit messy to do this, but yes. See comment above.

We'd love to make it more general, yes. But it's a difficult task since taxation and law interact a lot with equity comp.

In the short term, it's just for the US, but this could change.

Probably the best approach would be for someone knowledgeable in European law to write an addendum in the same style for Europeans, listing info and differences specific to EU or specific countries. Then in the future, perhaps we could have linked subsections devoted to different regions or countries (and perhaps even split out the US). If anyone here would like to help with this, please file an issue to coordinate it!

Thank you! Love HN discussions but also want to see corrections and comments work their way back to the original doc.

Thanks for the correction. I've created an issue with the entire comment so we're sure to correct it, and perhaps include more explanation based on this and the helpful background you've written. https://github.com/jlevy/og-equity-compensation/issues/24

This is Josh, of the authors of the Guide. First, thanks to everyone for the comments and feedback.

Also, please remember this is a GitHub project for a reason! This guide has a lot of shortcomings as it's very new, but our goal for this is to be a "living" guide, not yet another read-and-comment blog post. After commenting here, please consider filing an issue or PR with questions or suggested improvements. A community as talented as this one knows vastly more collectively than any individual authors. We can then discuss and work to get suggestions incorporated.