This article is less about specifically running 100 mile-races and more about doing something that requires self-control; and the claim is that doing so will make anyone a more successful person.
> ”Bill Gates spent thousands of hours learning to program”
Here's the full quote: "Bill Gates spent thousands of hours learning how to program computers—but he only had that opportunity because he had the good fortune of having parents who supported his education."
I think you're in violent agreement that 10,000 hours isn't sufficient.
> There is virtually zero use for this capability [running 100 mile races]
That's a major point of the article, given it's discussion of the spillover effect: "The bottom line: Practice self-control in one area of your life, and you can apply it in other parts, too."
> Seems like way too much work for an attacker to try to figure out.
I dunno, seems like way more work to come up with, maintain, and actually use the generator. Seems easier to just click a bunch in my vault to generate and copy, although I guess you're protected from vault-theft?
Given your example, I had already figured out all the way up to ies/otto are probably foreign numbers (more specifically, otto looks like 8 and 16 looks like double of 8) before even seeing that you just gave the answer away.
Of these, 1: Chose the project you want to contribute to (and 1.5: Choose the issue to work on) and 9: Follow up are the hard ones. Both are primarily social problems.
For 1, it's mostly about knowing yourself. What projects interest you, and where can you contribute?
For 9, it's convincing the owners that your contribution is a net positive. Start with 2: Check out how to contribute, and proactively reach out so your pull request doesn't come out of the blue.
Oh, and be willing to put your ego aside -- it can be tough to defend your work, particularly if you're a new (and thus haven't built up trust) contributor. It gets easier, both as the project learns to trust you and as you learn the work within their practices.
If you're hourly, of course it's a different thing.
But if you're salaried, it's an arms race. Employees willing to work extra hours get more done (or at worst, only appear to get more done), and thus will get the rewards and promotions.
It's even worse than that -- kill is just a command that sends signals to a program, some of which happen to (gracefully or not) stop the program. You can even define your own!
He's probably talking about client-side IDS, such as in a corporate environment.
It's worth noting that in such an environment, he likely controls the client machines themselves (ie, only corporate machines on the corporate network), so it's straightforward to just push out a trusted Certificate Authority and intercept anyways.
Why would technology be any different from anything else? The prosecution and defense are free to call on expert witnesses to explain SSL and heart surgery to the judge and jury.
> It either relies on a waterfall-like process where the full design is known before-hand and therefore what tests have to be written,
This is that fuzzy line between behavior driven development and test driven development. Sure, you may not be able to write cukes to test how that your social mortgage site is going to work, but you probably should be writing tests to ensure that your internal compound interest code is correct.
Yes, if you can't solve a problem, you certainly can't solve a problem in a supportable manner.
Agile has the concept of Spikes (http://www.scaledagileframework.com/spikes/) for researching new problems. The key point that code is thrown away after completion -- this gives you the freedom to ignore normal methodologies and not have to worry about technical debt.
Presumably, you then go back with this new knowledge and only now concern yourself with writing supportable code.
> However, I've used Royal Mail (postal service in UK) all my life without thinking that I needed to worry about what I said
This is true for the United States Postal Service as well. I've always thought it'd be interesting to look at what historically brought about the strong privacy expectations to postal mail when it's technically so easy to intercept.