The next paper selected for me was by Adrian and Bronk. They demonstrated that nerve impulses were sharp, single-pulse phenomena. They had done experiments with cats in which they had measured voltages on nerves.

I began to read the paper. It kept talking about extensors and flexors, the gastrocnemius muscle, and so on. This and that muscle were named, but I hadn’t the foggiest idea of where they were located in relation to the nerves or to the cat. So I went to the librarian in the biology section and asked her if she could find me a map of the cat.

“A map of the cat, sir?” she asked, horrified. “You mean a zoological chart!” From then on there were rumors about some dumb biology graduate student who was looking for a “map of the cat.”

1. Be good. Be very good. Don’t be the “front-end guy” or the “back-end guy”, or some other “guy”. Once you know what you want to build, building software is about five things: algorithms that solve your problem, programming languages that express your algorithms, computer architecture that makes your algorithms run efficiently on real hardware, the practical toolchain, and the management of complexity of real software. So study algorithms, and then graduate algorithms, and then advanced graduate algorithms. Do every challenge problem online. Study programming languages to express those algorithms. You can get away with three: C, Lisp, Haskell. Everything else is crud. Study computer architecture and compilers to see how your programs run efficiently. Learn great tools (Emacs/Vim/Visual Studio/bash/Linux/OS X/Windows whatever – just great ones that you’re damn good at). Learn how complexity is managed. Look at lare open source projects, study how they’re organized, and contribute patches to understand how small changes can effect a large system.

2. Learn what to build. Once you get really good, your time starts to be more valuable than gold. There will be very few people in the world who are as good (the internet will bias you to think that the world is full of great people – this ain’t so, there isn’t enough of ‘em). You owe it to people and to yourself not to bother with improving something by 1% or 10% because you’re wasting time in opportunity cost and could be improving something by 1000%. Make sure what you’re building is worth building, and make sure every line of code you write is worth writing, otherwise you will fail. Break the NIH syndrome in yourselves now (all good people have it, phenomenal people that build successful companies broke it in themselves). Learn to infer what people want.

3. If you’re that good, you will easily get a $100k job after graduation (probably more by then), and grow to $180k in a few years. That’s very, very comfortable. It’s not worth busting your ass 16 hours a day to build another CRM tool when you can have a $180k job. So don’t start a business to start a business. Start a business to bring a meaningful change in the world. A huge change. A 1000% change. There are lots of hugely successful companies out there that do what’s not meaningful to you – ignore them. But do make sure that what’s meaningful to you is also meaningful to millions (hopefully billions) of others. You won’t get rich writing Lisp compilers.

This is what matters. Most everything else is fluff.

The problem is that it’s relatively easy to brute-force attack even a salted hash today.

On the first day, people stored passwords in plain text. If someone got access to your database, they had all the passwords.

On the second day, people decided to hash the passwords so that people couldn’t unencrypt them. Then the attackers created rainbow tables that correlated each hash with its associated password since the password would always hash to the same value (so you have “109BCA” in your database, but they have a table that has that hash and that “12345” hashes to that value).

On the third day, people decided to salt the hashes to render the rainbow tables ineffective. Now, each password would hash to a different value so they couldn’t just look up the password for a given hash. However, as computing power increased it became easy to just brute-force the password. You have the hash and you have the salt so you can just try every password with the hash until you get a match.

  hashed_password = "ACBDEF1234567890"
  salt = "12345"
  possible_passwords = ["password1", "ilikesheep", "micro$oft"]
  possible_passwords.each do |pass|
    if Digest::SHA1.hexdigest("#{pass}#{salt}") == hashed_password
      real_password = pass
    end
  end

The problem is that code like that has gotten really cheap to run and it’s incredibly parallel (you can have loads of machines each take a piece of the workload – oh, and hopefully no one will make a joke that you’d never write that in Ruby; I just felt that would be easy pseudo-code to demonstrate). You can just try combinations of passwords at random, but there are lists of more common passwords that you can try first making it go even faster. Hashing algorithms are meant to be fast because they’re meant to be usable on a large piece of data. As such, it also becomes fast to brute force check all sorts of combinations.

On the fourth day, people started using things like bcrypt because bcrypt was made to be slow. The fact that bcrypt is slow means that if someone wants to brute force it, it will be very slow going for them. If one can check 10,000 SHA1 hashes in a second, but only 10 bcrypt hashes in a second, it will take 1,000x longer to crack the bcrypt stored password (those are just made-up numbers as an example).

Salting is better than not salting because they have to brute force the password. However, as computing power increases it isn’t so much better because brute forcing is becoming easy. One needs to use a slow algorithm to make sure that cracking it will also be slow (prohibitively slow). Bcrypt also allows you to specify how much work you want it to have to do. This way, as computing power increases, you can increase the amount of computing power needed to compute the bcrypt. By contrast, hashes are meant to go fast and so every day they’re getting less secure.

Bobby Fischer was completely obsessed with chess and played and studied it incessantly.

9 years of manic dedication and he “suddenly” got good.

His mother spoke something like 8 languages and his father was a Hungarian physicist who headed the Theoretical Mechanics section of the Naval Ordnance Laboratory and was an expert in elasticity and fluid dynamics.

One famous story about his memory:

“One day when he was in Iceland, Fischer called Frederick Olaffson, Iceland’s only Grandmaster. Olaffson’s Icelandic-speaking daughter answered the phone and explained her parents were out and would return at suppertime. Fischer understood nothing that was said because he did not know the language. But he listened, apologized and hung up. Later that day Fischer met with another Icelandic player who spoke English. He explained what had happened and repeated every Icelandic word he had heard on the phone, imitating the sounds with perfect inflection. The Icelandic player translated the message word for word for Fischer.”

Despite being prodigiously “intelligent”, it still took years of dedication to get good, and years more to get really good.

Plenty of average people undoubtedly beat him at chess when he was a kid. When you think about it, it should be obvious that he was always that smart. Just because you’re a kid and don’t know anything yet doesn’t mean you aren’t smart. “Smarts” is not the same as skill.

Incidentally, his record as the youngest grandmaster in history lasted for many years until it was broken by Judit Polgar, whose father was explicitly running an experiment with his daughters to prove that prodigies are made, not born. All three daughters became chess experts. He explained that Judit, the youngest, was the most successful because she worked the hardest. She’s the only female ever ranked in the top-10 of the “Men’s” ratings list.