If this is the intended meaning then I disagree. The problem is that the kind of code most of us write isn't pure implementations of algorithms backed by formal proofs. In that case the code is the documentation because it is an expression of a mathematical description of something.
The code most of us write is a hodgepodge of business logic, frontend code, and a bunch of glue to make it all work together. In the case of business logic context is highly important. Just looking at the code doesn't convey the whole story or the "why" this code does what it does. In this specific case comments are the difference between saying "we don't know why this works," and "according to BUG-#### we need to send the counterparty this field as a logon credential otherwise their system behavior is undefined."
A caveat here as well is you also need to make sure your various clocks in the data center are synched. This is one of those common but overlooked scenarios which lead to hilarious discussions about latency when really there was just a clock synch problem. Additionally the fallacies of distributed computing come into play here (namely, transport cost is 0) so you need to take extra care when looking at measurements across different systems and machines. Even machines in the same data center. The pipe that you are communicating across could be oversubscribed for example.
Logically it would seem that the company would provide counsel because at the time of the alleged incident you were conducting business for the company. This is all laymen speculation of course. Any lawyers around?
I agree. Anything that gets people interested in programming is good for the industry. Typically I try to steer people who are interested in trying out programming to scripting languages first. The benefit here is the learners get an expedient path to gratification. It's important that people experience the gratification that comes from building something before the ugly truth about how horribly complex these systems are sets in.
I believe a more formal definition of realtime is: When missing a deadline constitutes a system failure. Given this definition realtime systems are not bucketed in such a way that they invite a false dichotomy. For instance on one end of the spectrum you would have hard realtime systems (e.g. a pacemakers) where missing a deadline means death of the patient or serious financial loss. On the other end of the spectrum you would have soft realtime systems (e.g. facebook) where missing a deadline of say displaying a web page in under a second would constitute a system failure (revenue/engagement decrease), but still be valuable (people will put up with slow page loads, look at reddit).
This sounds like a maintenance programmers worst nightmare. Although I'm coming from a Java background so naturally I have accrued an unhealthy amount of bias.
Anybody from the more dynamic languages have any war stories about debugging/maintaining this sort of thing?
Didn't Paul breakout the outcomes of Y Combinator companies a while back (e.g. acquired, sold, in business, etc)? It would be interesting to see if anything has dramatically changed.
Could somebody please enlighten me as to how one would go about utilizing 100% of the bevy of high caliber design talent that Facebook has amassed? Facebook products don't change very often, I'm rather curious as what it is they plan to do there.
Depending on who hosts your content, these sites are fairly cheap to make and maintain. I have a few friends who make these sorts of websites and use imgur and other free services to host content. They cost on the order of tens of dollars a month. As for profits just look at their visitor stats and compare it to adwords.