Really noticed a difference in priority between professional and end-user programming this week. Where the pro may have reason to optimize performance of a computation, an end-user wants to optimize time-to-answer. At the end of the day, a 10,000x performance hit of doing the first dumb thing that comes to mind is fine since you can leave it running run overnight. On the other extreme, when superior performance gives you answers as fast as you can pose questions, you can potentially start asking in a qualitatively different way. It can get downright silly, "let the machine ask the questions while we figure out how to filter the answers." (I guess this ties into the data/information conversation.)

On multiple occasions in my life I've run a command at the terminal, gotten impatient at how long it was taking to run and opened a second window to create a faster version of it. In a substantial fraction of these cases, time to develop the faster version + time to run the faster version just once was lower than my original (ridiculously inefficient) command, and so the faster version immediately paid for itself. (Though there's still value in leaving the slow version running to double-check the more complex optimized version.)

One approach here is to make programs fast by construction, i.e. make slow programs unrepresentable in the language.