I agree, and to amplify: while there are surely aspects of design that can be automated, the part that's difficult is that a design should actually mean something. Having an algorithmically designed logo tie the room together -- crystallize a company's business and culture, and provide a memorable rallying point -- that's the hard part. Computer-generated design is like a ghostly thread of expression of the design sensibilities of the writers of the software from which it emerges.
Consider the hidden arrow in the "Ex" of FedEx, when they rebranded from "Federal Express"; the rational propeller of BMW; even something as simple as the Burger King logo being sandwiched in a hamburger bun. Granted, logo design is just one small corner of design in general, but algorithmically generated logos do indeed result in a herd of swooshes, globes, and rings orbiting bold text (notwithstanding the similar designs of many humans who fail to recruit sufficient creativity or inspiration). Some of these can even be aesthetically pleasing, but it's so much better when a logo is retrospectively obvious and actually means something.
I love how, among the more strategic thoughts on life, he mixes in advice about how to play one specific point against Agassi in the 1995 Australian Open. 20 years later, a fierce competitor still litigating where he should have placed one serve.
I thought the same thing. Winning 4 out of 5 is pretty definitive -- you're going to obsess over some possible way to win the 5th all these years later?
I've heard it said that champions like Michael Jordan, Tiger Woods, Sampras, etc. are motivated more by avoiding the feeling of loss than by than having the feeling of winning. They are motivated by negative emotions rather than positive. That jibes with this anecdote IMO.
I would probably congratulate myself on 4 out of 5, which is why I'm not a champion :)
Champions don't fear loss otherwise they would never try for the last second winning shot. Champions like Michael Jordan, etc, believe they should win every single time because they are the best. When they take that last second shot, they believe it is going to score. A championship is theirs for the taking and if they lose, it's because they fucked up, not because someone else beat them.
I think this is true for many of us in our lives; we tend to remember and obsess over our failures more than our successes, particularly the large ones. If we learn from our mistakes, maybe we learn the most from our most expensive mistakes?
I think very often, such obsessing over the details of our failures is just wishful thinking. We are trying to rationalize our failure. Rationalizing is much easier if you distill the causes of failure to one simple event. In this specific case, that modification of strategy would have saved the set, perhaps, and given him a chance to continue fighting in the match. A win would be far from guaranteed, counterfactuals are hard to construct and almost always impossible to verify.
Tennis is a sport where you will rue every single point in a lost match. It lends itself particularly well to the if-only-I-did-that-one-thing-differently rationalization. It is due to the hierarchical (game-set-match) nature of the scoring and how one only needs to win one crucial point to get past their competitor (e.g. at 30-30, 30-15, the players are really sitting on a knife's edge).
cSubs is a small, fast-growing, award-winning SaaS company focused on the knowledge resource management space. Our service is delivered primarily through a B2B web application targeting enterprise clients.
At cSubs you'll work on large web applications for business, but help us bring a distinctly non-corporate user-focused sensibility to app design. We hold the occasionally contrary opinion that business people at work are still actual people, and we strive to make our web applications delight those people -- not just check the boxes on a corporate feature grid.
We care less about which specific languages you know than the fact that you have strong experience with more than one, and deep multi-year expertise with at least one. We'd love it if you have Python and CFML experience specifically, since we have a large CFML application running on the JVM using Railo/Lucee -- but we also use Python, and are planning to transition much of our architecture to Python and PostgreSQL. As an expert, you would help spearhead this effort, alongside day-to-day development.
You will have contact with clients and client stakeholders, so you're comfortable joining and occasionally leading calls and meetings. You're able to express yourself in clear and professional English, so writing effective email messages and reading, analyzing, and developing project requirements is second nature to you.
Interested? Contact me at firstname.lastname@example.org, and please let me know in the subject line that you're coming from the HN thread.
My own jazzy interpretation of this is that it means something like responsive design by constraint. Think struts and springs and juicy animations sensitive to user-controlled context and the viewport. So an edit button may rarely be in exactly the same place at the same time, given scrolling and device and window size differences, but rather appears, animates, and settles according to a script.
I have better things to do with my time than to give everyone the same amount of time and respect.
I understand that feeling. Life is short. But why take the time to respond at all, then, dismissively or otherwise?
"A wise man can learn more from a foolish question than a fool can learn from a wise answer." 
For me, sometimes a charitable interpretation of a "foolish" question or comment provides a framework to think about, or write about, what I see as the more salient point. Responding is optional, after all, so why not respond from the perspective of charitable discourse?
So, a sort of Sapir-Whorf hypothesis for the programming domain. It certainly feels true; living and breathing a language like Erlang would probably make one think very differently about what's possible than someone immersed in Fortran.