This page is heavily inspired from gwern.net/notes, it is a collection of things I found interesting enough to store somewhere
Half the challenge of fighting procrastination is the pain of starting—I find when I actually get into the swing of working on even dull tasks, it’s not so bad. So this suggests a solution: never start. Merely have perpetual drafts, which one tweaks from time to time. And the rest takes care of itself.
Why does software seemingly fail more often than other engineering artifacts ?
It really boils down to two things:
One of the first things I thought about is its very immaterial nature: computer systems are far less limited in the growth of their complexity compared to the physical ones that have characterized engineering as a whole for centuries. Such over-linear growth has systematically made our systems grow in their complexity at a much faster rate at which we comprehend them. Meltdown, Rowhammer, et al. are prime examples. Moreover, @halvarflake in his keynote went over to explain an even more fundamental way in which complexity is not bounded: it is much more expensive to build a special purpose machine than it is to use a general simulate the necessary needed. This effectively makes every special purpose machine (i.e. program) inherit the entire jungle in which the general one lives. (this is not too clear unless one goes over ot explain the entire OOP banana/jungle analogy)
Computer security is the epitome of such phenomena as security vulnerabilities are all about 1 leveraging broken assumptions and deeper understanding of the underlying system.
Infosec is all about the mismatch between our intuition and the actual behavior of the systems we build. That makes it harmful to study the field as an abstract, isolated domain. To truly master it, dive into how computers work, then make a habit of asking yourself “okay, but what if assumption X does not hold true?” every step along the way. ~ lcamtuf
“In any field, find the strangest thing and then explore it.” ~ John Archibald Wheeler
If I reacall correctly, this is close to what Paul Graham calls a good heuristic to identify interesting problems
“When you are overloaded, don’t think of it as not having enough time; think of it as having too much to do. You can’t give yourself more time, but you can give yourself less to do, at least for the moment.” ~ @KentBeck and @martinfowler
“A very useful heuristic, a potent filter: When someone criticizes you, train to immediately ask yourself: “Would I rather be him/her, or I’d rather be me?” before taking the remark at face value.” - Nassim Nicholas Taleb
Needless to say, primitive and hard to reason about tools do play their role. But it goes much much further than that. Producing secure software is really hard. ↩