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 anywhere from slightly to very wrong for each section. Pretty cool as a tech demo but definitely should not be used to understand a legal document.
- In System Preferences -> Notifications & Focus you can switch any apps notifications from "Alerts" to "Banners" which will make them go away automatically when ignored.
Unfortunately the nearby headphone notifications are not generated by an app, so you can't use the normal notification banner settings. The only way I've found to disable them is to go to Bluetooth preferences (while the headphones are connected), click options next to the headphones, and change the "Connect to This Mac" dropdown from "Automatically" to "When Last Connected to This Mac".
I'm not satisfied with this solution since I enjoy the automatic switching between devices, but I'm driven crazy by the notifications that pop up on my mac literally as I'm listening to music with those headphones on my iPhone. C'mon Apple - this is all within your ecosystem!
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:
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?
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?
How sad. I got to hear him talk in person about functional reactive programing for musical interfaces, and it's a wonderful talk and really neat ideas. If you're interested, I believe this is the talk: https://vimeo.com/96744621. Rest in peace.
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`)
In my experience, a day spent pairing, while generally a sort of intense experience, is also filled with little breaks. Your pair gets up to grab a drink; you check your email; somebody turns on a Katy Perry single and you spin around to join a team-wide argument about its merits; etc, etc. :)
While nearly 100% of your time is _dedicated_ to pairing, I'd say the percentage of time you both spend actively sitting at the computer working on a task is roughly equivalent to what you'd do as an individual. Which is to say, it varies. But it never really feels like you can't do side things; the vibe is very flexible and casual.
For deploys and emergencies, it's almost always a pair attacking the problem. Even if just one developer is doing most of the driving, the pair is still able to learn, catch typos, diagnose, etc.
Meetings can definitely end up splitting pairs, which becomes yet another incentive to try to minimize them.
Usually pairing seems to work great to get you through things that seem like they're a slog. So you don't have to pair through everything, just the hard and boring bits. It helps to timebox it, and say it's going to be (e.g.) an hour long session to prevent it from taking forever and help focus. Even if you're not done, chances are you'll have made good progress. So, schedulingwise, it's a bit like a meeting.
The largest benefit I see is that having someone with you is like having more than double the focus and vigilance, since you're both there to help each other out and you'll both tell each other when you're leading yourselves astray, which doesn't happen when programming individually.
Pair-design also works great.
I think it's harder to be as productive in code review (and I think they aren't mutually exclusive anyway) because people tend to focus more on nitpick changes like style issues, and miss the larger design stuff.
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.
I've done pair programming extensively, both for personal projects and at work. Pair-programming sessions are not the time to process email; IMs/IRC are treated as interrupts (quickly check if an urgent response is needed and otherwise defer); meetings are something you schedule pair-programming sessions around; deployments are a great thing to do as a pair to reduce screwups.
> [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.