nemild

I don't think your mom is irrational given what is covered - but the big mistake we often make is thinking that what we read is representative of what is going on. I want to use data to show this effect on a number of issues.

And the larger point I will make in a future post is that news covers what people want to read, which is problematic if the goal is good decisions.

(As an engineer, I often think about this as akin to sampling bias)

The other thing to be aware is that the rationalization may be different than the reality of why he didn't choose you. The CEO may have found this an easier way to reject you.

In YC, there was this saying (in the context of VCs): believe the rejection, but not the reason. There's little upside in being honest.

Noted below, but I'd also highly recommend Redis for clean code.

And even later it was someone like William Shockley, inventor of the transistor and Nobel prize winner.

Just upvoted.

New parties are hard. Still, I've found it interesting to think about a group that was only active in 3-5 evenly contested states, that collectively controlled a few percentage of the vote in those states.

This small group might have tremendous power to set the agenda, either as a distinct party or one that influenced the presidential candidates.

Is your experience emblematic of the that for most customers? Some of the things you mention seem like fundamental design flaws, so I'm curious if most customers have issues?

I'm sorry to hear the news - code annotation is something we need more of, especially for teaching and debating different design choices. I remember your posts on how MRI/Ruby worked from a few years back, which were always fun - and something that I thought other open source projects would have benefited from.

See my comment in this thread.

Telcordia/Bellcore was a spinout from Bell Labs after the DOJ antitrust action in the early 1980s. Bell Labs stayed with AT&T and Bellcore was the R&D lab for the newly created Baby Bells composed of many staff from Bell Labs.

Bellcore/Telcordia was spun out from Bell Labs as the R&D lab of the Baby Bells after the early 1980s antitrust suit against AT&T. Before the breakup, there were a number of labs that composed Bell Labs in NJ, not only in Holmdel.

My father worked in Morristown at Telcordia Technologies/Bellcore in the 1980s/90s and before that at Bell Labs in the 70s.

Thanks - I had put it in a footnote that got cut, but will edit.

You're absolutely right, but after so much success there also seems to be a fair amount of confidence/arrogance that set in at NASA regardless of other pressures.

Additionally, when you have a civilian on board, I think it really changes how you think about what an appropriate level of risk is (13% might have been ok with professional astronauts who knew the risks beforehand, but likely was too high for a civilian).

And the line engineers at Morton Thiokol fought back pretty hard on the decision, even if it might have impacted their careers negatively.

While the graphs I highlight don't show it, the broader paper uses both actual launch data AND experimental data to derive the regression. This experimental data presumably should be available regardless of if this reasoning had been used earlier on launch data. This is one good reason why experimental data is so critical, as real world data can be biased.

You're absolutely right though about this being "Monday morning quarterbacking" with any analysis after the events. That said, two things are clear:

1. The most knowledgeable engineers were strongly against launch (see Ebeling and Boisjoly at Morton Thiokol)

2. There were huge statistical flaws made by decision makers at NASA before launch (see Feynman as noted in this thread)

This is often taught in business schools and one case is called Carter Racing:

http://heller.brandeis.edu/executive-education/maine-2012/ma...

I'm the author of this piece, happy to answer questions.

I grew up with stories of the Challenger after my father - a statistician - and 2 of his co-authors were selected by National Academy of Sciences to study if the danger could have been predicted beforehand. They showed that the likelihood of failure was 13% at the launch temperature, but would have been negligible if NASA had waited just a few hours. (His co-author, Ed Fowlkes, was dying of AIDS at the time - and considered this paper one of his life's great achievements)

Bad statistical inferences were a huge part of the launch story, and you can see more in Richard Feynman's critiques:

https://en.wikipedia.org/wiki/Rogers_Commission_Report

Secondly, the effect I highlight (a biased data sample) is a key issue with news/social media - and can lead us to heavily flawed inferences if we don't correct for it.

I'll dig deep into this in future posts with a substantial amount of data and visualizations.

You'd be surprised - it often implies the lifetime value of the potential customer is exceptionally high, despite low conversion rates (a medical lawyer is a good example, as are insurance products with high stickiness).

Thanks, I modified the question to be more clear.

I often find that mistakes other make are valuable for me to learn from as well. I could make every one of these mistakes serially as well, but in some cases, learning from those of others is a good enough lesson for me.

And as context, Professor Dan Boneh teaches the main introductory crypto class at Stanford (CS255) - it's a great intro for someone with some good CS fundamentals. The course syllabus is here:

http://crypto.stanford.edu/~dabo/cs255/syllabus.html

(Disclosure, I took the class a few years ago)

Is your argument that Bangladesh would have been safe if they were using a blockchain? Given their revealed security practices, I'd be surprised if they had the ability to secure any private keys from being revealed - and they would have had even less recourse with a blockchain based system (though admittedly, their recourse is limited even now).

I'm sorry to hear about this. How do lawyer's think about this situation (up front vs potential earnings) for something that seems like it could be a sure thing?

Are there any legal financing options available to manage the fact that cash is needed up front?

I don't know the history of why design decisions were made in JSON, but one might be the allowance for spaces in keys and mirroring the usage within arrays (where commas and spaces may be used in a string, but shouldn't be confused with a record separator).

Per my other comment, there are a variety of plugins on the editor side that will make JSON look like this (e.g., vim-json ). To write out to JSON from that format, you can obviously just write a plugin (in JS this is one line).

Two quick observations:

- Getting standards passed is hard (especially for popularly used standards), but can be supported by latent usage in the community. You can create a plugin for a few languages that automatically allows the timestamps and doesn't require commas. Get a bunch of people using it, and you'll be on your way to actually getting it in the standard in the future (still debatable in this specific example, but broadly, usage never hurts for getting something into a standard)

- If your concern is your own frustrations (rather than benefits of the vast majority of people) - I highly recommend a simple editor-level mapping that translates from your preferred DSL to the underlying standard

I have to echo everything said by @jerf. One additional suggestion is to write a blog post highlighting ways to improve the workflow for go developers and help them to understand why certain things are better than others, as your work here slots in nicely.

You could also explain in detail what goes on behind the scenes in an incremental build.

Forgot to add to my original request: For yourself, what makes something "good documentation"? What makes bad documentation? Are there things you wish people did more of or less of?

I'm going to be putting one resource together in the next week- will ping you with a draft when it's done. Is there an easy way to reach out to you?

It'd also be helpful to better understand what is missing in the resources you've read.

You can email nemild at google's email service.

Real world financial transfer systems are often used for net settlements. And writing the entire history of the world's transactions on a single append-only ledger that has low throughput and costly storage may not be ideal, while approaches like Lightning might allow instantaneous transactions.

Still many ifs, but if it works, there could be some interesting advantages for speed and scalability.

I assume you have evidence backing up this correlation for large, mature tech companies, rather than startups?

I liked Github's new feature that prefills in the New Issue with the instructions. Maybe that cuts down on poorly specified issues?

Separately, was there ever demand for charging for non-standard support, a la Red Hat? I don't mean for those highlighting bugs, but for people who wanted more basic help. The world needs more open source and open source developers, and I wonder if models like that are both compatible with OSS and provide some support resources for the developer.

Spotify is one counter-example. Grow in a smaller market where you can do things that can't be done in larger markets (e.g., license streaming cheaply) - and then scale when you've proven the model.

And some of which will be rapidly deprecated.