These results were expected by neuroscientists. Different senses are encoded differently in the brain. So, the subjects were unable to link them at first. The surprising thing here is the speed the association between tactile and visual encodings happened, and the article makes that clear.
The primary function of sleep is to permanently store the things learned during the day (long-term potentiation). Although different people need different amounts of sleep, those who need less usually find that they sleep longer if they learn challenging new material (e.g. a new language). That is the reason why babies sleep the most. Their brains are empty sponges constantly absorbing new information.
I think the real gem is at the end of the article:
"Many things that don’t look optimal are in fact optimal once you take the necessary constraints into account. For example, software that seems poorly designed may in fact have been brilliantly designed when you consider its economic and historical constraints. (This may even be the norm. Nobody complains about how badly obscure software was designed. We complain about software that has been successful enough to criticize.)"
If everyone is complaining about a different part of your software, that probably means just nitpicking. If the complaints converge on a feature or two, then you should absolutely listen to what they have to say. King is right on the money on this one.
Although there is clearly a grade inflation, the correlation between student selectivity and average GPA should also be noted:
"As a rough rule of thumb, the average GPA of a school today can be estimated by the rejection percentage of its applicant pool:
GPA = 2.8 + Rejection Percentage /200 + (if the school is private add 0.2)
Non-selective public schools (typically with 15 percent rejection rates or less) with GPAs in the 2.8 range or less tend to have only modest grade inflation. Some have none."
I don't want to discourage anyone, but you are practically distracting yourself from building a product by learning how to program. Getting really good at something takes many years of practice, and the program you write will likely be full of problems you are ill-equipped to fix.
I agree with this, but I think putting in the effort to learn the language or the infrastructure enough to be able to manage a contractor or distinguish between crap code and good code will not only serve you well in the tech startup world but also win you accolades from your team/peers.
I strongly believe being really good at one thing means you shouldn't try to multi-task or wear too many hats. That's counter-productive and recipe for moderate work quality. At the same time, the early days of the startup are the most fragile times. The business guy who speaks engineering or visa-versa will have a huge competitive advantage.
