54 Matching Annotations
  1. Nov 2024
    1. I've applied to YC 11 times over 5 years, which demonstrates both my persistence and how deeply I value what YC offers. Building startups is incredibly challenging - I see YC as a force multiplier that can significantly accelerate our growth through its proven methodology, network, and advice.

      (Fix typos.) This is great, and best of luck!

    2. We charge a $20 subscription fee from individual engineers and a custom fee from enterprises starting at $20 per engineer per month. We also intend to have a free tier. At 1,000,000 engineers, we could make $240,000,000 ARR
      1. Don't talk about a free tier in this question.
      2. The subscription fee for individual engineers is per what? Month? Year?÷
    3. Most open source robotics projects today are either linked to Github ( for software and file management ) + onshape ( for hardware designs ) or linked to a software documentation template (See K-Scale Lab's (YC W24) Documentation ). Closed source teams say they use tools like Notion and Confluence for their documentation. While these tools are great at what they do, they represent "hacky" ways to get the job done for teams building robots. Hence, they take significant time and effort.Engineers want to focus on what they do best ( building cool things ) and the tools that exist today force them to spend significant time describing things they have built already. We believe that there is a need for a new kind of knowledge management tool for robotics teams one that can be integrated deeply with tools they already use to do their work and automate the long and tedious documentation process.

      Answer this more directly. "They represent hacky ways to get the job done" isn't a great way to explain what you really understand. From what you have here, it's something more like:

      1. Engineers don't want to spend significant time documenting things they've already built.
      2. LLMs have made it possible to auto-document robotics projects.
      3. Documentation tools have to be deeply integrated with software that robotics teams already use for them to be useful.
    4. Competitor 2. Software documentation templates.

      I'm actually not sure templates is a good way to answer the question of competitors. What kind of templates are these? How are they created and where are they stored?

    5. We chose to work on improving robot documentation because we've personally faced the challenges it presents. 7 months ago, Olu and I attempted to build an open-source robot and found that existing documentation tools—primarily designed for software—were ill-suited for robotics projects. This made it difficult to understand the robot's design and functionality, leading to numerous questions and delays.Our co-founder, Naveen, is a robotics product designer, who has helped multiple robotics companies develop advanced industrial robotic arms and humanoid robots. In his experience, he has consistently found documentation to be one of the most daunting yet essential tasks.To validate the need for a better solution, we spoke with over 70 engineers who echoed our frustrations. They reported spending about 25% of their project time on documentation and an additional 10% answering questions from others who are less familiar with their work.Through our personal experiences and these conversations, we realized there's a significant demand for a specialized tool to streamline robot documentation. By addressing this pain point, we aim to save engineers time and improve collaboration within the robotics community.

      This is very good.

    6. We have 5 robotics companies in our pipeline ( 4 open source, 1 closed source ) giving us access to 2,000 engineers ahead of our launch next year. We expect to be at $250k ARR by June next year.

      Say something about what you'd charge to get to 250k ARR. Something like:

      "We'll charge $x, expect to convert y% of them, and aim to reach at least $z ARR by June next year."

    7. We have 5 robotics companies in our pipeline ( 4 open source, 1 closed source ) giving us access to 2,000 engineers ahead of our launch next year. We expect to be at $250k ARR by June next year.

      When you say pipeline, are they on a waitlist and actually confirmed they're interested? Or do you mean a sales pipeline?

    8. Revenue came from the 25 users that paid 20 dollars to use our web-based robot explorer to learn about the Parol 6 robot arm and the RX1 humanoid robot.

      This explanation is better than the one in the second paragraph of the question about active users.

    9. Revenue came from the 25 users that paid 20 dollars to use our web-based robot explorer to learn about the Parol 6 robot arm and the RX1 humanoid robot.

      Is this a one-time payment or subscription?

    10. These 25 users paid us $20 to get access to the explorer and learn about specific projects on our platform as they prepare to build it. They are majorly software engineers and product designers who have always had a knack for robotics but never had a clear and easy way to get started.

      The explanation here is a bit unclear and I think makes this answer a bit noisy. What does "access to the explorer to learn about specific projects on our platform as they prepare to build it" really mean?

      It's a bit of a red flag if they paid for resources but not the product, which is what this sounds like. Might be better to refine/remove details about "learn about xyz as they prepare to build it".

    11. We have over 100 active users in our Discord community, 25 of which are now paying customers and actively use our most recently launched explorer ( They have used it more than 5 times in the last month ).

      "In our Discord community" is a bit of a red flag.

      "We have over 100 active users, 25 of which are paying (active = used the product more than five times in the last month)."

    12. We've launched twice and are currently on a third iteration of the product. We generated $500 in revenue from our most recent launch, received feedback from engineers on what we need to focus on to make the product more valuable and now, we're working on a new iteration to serve engineering teams.

      Focus on the most recent launch, rather than the number of times you've launched.

      "We launched our latest version x weeks ago and have made $500 in revenue from y users. We're working towards an update in z weeks based on feedback received from the launch."

      (It's not a problem if y is small.)

    13. We understand the need to be in San Francisco to build our product

      Say something specific about why you would move to SF. Say for talent, proximity to customers, or something else.

      Also it's a bit clearer to say you're considering it than "you understand the need".

      "We're considering staying in SF after YC for x and y."

    14. Olu and I have known each other the for more than 5 years. We've known Naveen for about 3 months. Naveen was one of our first and most active users.

      Could you say something about how you and Olu met, or something about what you've done together.

      Also, typo with "other the for more".

  2. Jul 2023
    1. It is worth pointing out again that there are other ways to get this information, e.g. instrumentation, core dumps debugging, etc. This is for those who can’t modify the application, but also can’t hinder performance. It’s also useful for maintainers who want to do this without deploying code changes.

      This bit was really helpful to know early.

  3. Apr 2022
    1. P.S. I initially planned to walk through the AST at the start of this post and interpret it with the code. But, I think it’d be an interesting exercise for you to see if you understand how the Visitor pattern works. Fancy trying it?

      Yes boss

    2. In the accept method for Literal we have visitor.visitLiteralExpr(this);. We know from Literal(9).accept(Interpeter()) that the current visitor is an interpeter object, therefore visitor.visitLiteralExpr(this); can be represented as Interpreter().visitLiteralExpr(this) for clarity. Also, as before this refers to the current object which is a literal object: Literal(9). So Interpreter().visitLiteralExpr(this) becomes Interpreter().visitLiteralExpr(Literal(9)).

      Can this be a bit clearer? 😩

    3. In the Interpreter class, create a method to evaluate each type of expression and then use conditionals to call the correct method

      Interestingly enough, I used this in the post I'm writing. There's a little trick you can do with this to implement tail-call optimization. You'll probably find it really interesting when you read lol.

    4. Binary(Binary(Literal(120), PLUS, Binary(Literal(12.3), STAR, Literal(53))), MINUS, Literal(9))

      I think the image does the job much better. This isn't easy for my brain to (lol) parse.

    1. Overall, I thought the post was really good and the pictures were easy to understand. But like I mentioned in the comments, the texts about "parsing steps" are pretty long and difficult to follow.

    2. This point is critical because it highlights how we enforce precedence. Remember that we were trying to resolve the term’s right operand from 7, but because we found ‘*’ (i.e. a factor expression) in the path at 10, we resolved it first!

      Exactly, like this point is important. But it's hidden between so much going on in the steps.

    3. Here’s a diagram detailing the parsing steps:

      hmm. i can't see the picture. wondering if it's possible to just highlight (either in text or image), the key part (how the precedence is handled recursively) and leave out the rest. As it is, there's just a lot going on everywhere and tempting to skip.

    4. parse() gets called and it calls expression()expression() expands to term()At term(), the first thing we need to do is to evaluate the left operand. To do this: a. term() calls factor() b. factor() calls power() c. factor() calls primary().At primary, we see a NUMBER token at index 0, so we create a Literal expression and increment the index to 1. After that, we return Literal(53) up the stack to power()At power(), we check to see if we have a POWER operator at index 1, but there’s none, so we return Literal(53) back up the stack to factor().At factor(), we check to see if we have a STAR or SLASH operator at index 1, but there’s none, so we return Literal(53) back up the stack to term().We’re back at term() and find a MINUS operator at index 1, so we enter term’s while loop and increment the index to 2. To resolve the right operand, a. term() makes another call to factor() b. factor() calls power() c. power() calls primary()At primary(), we see a NUMBER token at index 2, so we create a Literal expression and increment the index to 3 ( which indicates the expression has been completely evaluated). After that, we return Literal(9) up the stack to power()At power(), we don’t check for any operator since the expression has been completely evaluated. So, we return Literal(9) back up the stack to factor().At factor(), we don’t check for any operator since the expression has been completely evaluated. So, we return Literal(9) back up the stack to term().Now, we are back at term. We have Literal(53) as the left operand, Literal(9) as the right operand and MINUS and the operator between them, so we create a Binary object like Binary(Literal(53), MINUS, Literal(9)) and return that to expression().

      Yeah, so personally, if I was reading this, I'd just read through the picture and once I understand it, skip the text explanation 😭

    5. Here’s a diagram detailing the parsing steps:

      This diagram is really helpful, but the explanation below it is pretty confusing. Picture seems like the best way to explain the recursion and I think it already did a good job.

    6. // Checks if the next token is a particular token type // If it is, it moves the index by one step private boolean nextToken(TokenType type){} // Returns the most recently consumed token private Token previous(){}

      Hmm. Looks like it'll probably take as much space to write out the implementation of the methods as comments are already taking.

  4. Mar 2022
    1. A rule name is defined as a non-terminal because it’s not a final state. As in, it is not terminating. As in, it produces other things.A terminal is defines a final “state”. As in, it terminates. As in, it does not produce other things.

      Minor: The "as in" said here four times feels a bit too repetitive.

  5. Feb 2022
    1. We spoke briefly about the MySQL server being sharded by workspace. Say this mechanism created too many hotspots; how do we adjust it?

      Ah, okay. I'd added this as a comment earlier.

    2. Answered Questions From The Space 🔗

      Not sure if the answers here should be bullet points. I think they can be inlined with the questions, like:

      1. Are they load balancers on any level? Yes, the HAProxy (see [image] above).

      I think it might be a little easier to read that way.

    3. This Flannel instance in that region that stores the snapshot is the instance that will respond to any future requests in that region from users in that workspace - in this way, we say Flannel has workspace affinity.

      When a new request comes in, how does the GeoDNS know which Flannel to send it to?

    4. Issues

      I think another issue that might be worth talking (or at least thinking) about is how the architecture handles workspaces that are much larger than the average workspace size. How do the sharded message servers and DBs handle that?