simonista

I'm excited to see where this goes because I think it is a cool application of AI. That said, two of the first three paragraph summaries are wrong in this example:

> [Investor Name] gave [Company Name] the right to certain shares of its Capital Stock in exchange for [Amount] on [Date].

This is backwards

> The Post-Money Valuation Cap is a number that is written in Section 2.

This isn't true, the number is here, "additional defined terms" are later.

It's feeding stdin to ruby code you specify on the command line, either as an array of lines, or repeated strings. So in:

  docker ps | rb drop 1 | rb -l split[1]

The output of docker ps is passed as an array of lines to ruby, and the first line is dropped, and then that output is fed to ruby again, but line by line, so each line is split (which defaults to split on whitespace), and returns the second element. With parentheses for function calls it would be:

  docker ps | rb drop(1) | rb -l split()[1]

Looks very cool, thanks for posting!

Can you give some examples of actionable insights you've gained from having these graphs? Are you using them in acute problem solving or in longer term prioritization of where to spend effort improving? What does your pipeline look like for trying to drill into more detail for a potentially concerning metric?

Super excited for this, the last one (hackthe.computer) was really well done!

This seems to have changed recently. You can now remove the phone as soon as you add authenticator as an option.

Does anyone have suggested reading on what the estimates of 8% (or 7% or 5% or whatever gets used) are based on? Is there any data to support that the next 30 years will see those types of returns from the total market on average?

Lots of work has gone into making a sane testing story for ember, props to all the people who have worked so hard on this!

Sure, but my question was in the context of the OP definition of "pair programming culture" as "a team that does nearly 100% pairing ... The day-to-day experience of programming is that of a day-long conversation with your pair"

I'm curious how other things that are intrinsically non-pair activities fit in.

Great post!

In the pairing paradigm (say that 5 times fast), how much of a typical day is spent actually pairing? How do you manage email or other company wide communication? What happens when a server crashes or another emergency comes up? Or when another pair has a question that you can answer? Or when one member of the pair is also responsible for a deploying something? Or one member has a meeting?

Disclaimer: I've mostly been exposed to the code review paradigm (I work with Paul at `current_job`)

Wow, this is a great story. First of all, props to the writer for weaving a bunch of different threads together in a way that made sense and was understandable to non-mathematicians without dumbing it down too much. And this is why I love math. There are so many great characters and themes in this story.

I love problems that can be stated so simply and yet are so fiendishly difficult to prove.

I love the idea that there is room for everybody in mathematics, from the lone genius outside of academia, to the young post-doc, to the unlikely collaborators.

Most of all, I love the idea that it's okay to fail, to throw out dumb ideas along with brilliant ones and that everyone makes mistakes, even Ph.D.'s in mathematics. We need more of that in education and academia generally.