"Most optimization is radically premature." Too many developers get obsessed with micro-performance details before they've even determined if their approach solves the business problem in front of them. We should first apply 100% of our brainpower to writing clear, correct, maintainable code that solves the business problem; only then should we ask whether we need to improve its performance -- and if so, by how much -- before attempting to optimize. Very often, clear, well-written code is already fast enough. "There's no such thing as magic performance dust." Parallelism is a useful tool for extracting performance when applied correctly, but it is still on us to understand the problem, cost model, and tradeoffs. "Just because you can, doesn't mean you should." The Java Streams API makes it easy to turn a computation parallel, but that doesn't mean parallelism is the right tool for all -- or even most -- problems. You still have to do the work to determine whether parallelism is going to get you a speedup. (If you even need a speedup.)

The audience should come away with a better understanding of what parallelism will, and won't offer them. This talk focuses on analysis, rather than measurement; it should be practical to analyze whether a problem (and the implementation of a solution) admits exploitable parallelism, and to identify the many possible sources through which impediments to parallel execution can sneak into our solution.