Through happenstance, my "first" specialization (subsequent experiences demote it to third place, as skills I discounted became more appreciated later in life) in the industry was performance analysis. Over time I came to understand the overlap between Knuths admonishments on optimization and "too clever by half" coding (ie, the large intersection between Knuth and Kernighan), and rather than abandoning it entirely I channeled that effort into finding more benign forms of optimization. There are code smells that are slow. There is slow code with higher cyclomatic complexity than a faster version. There is slow code that is less maintainable. These are not hard to find if you look for them.
The one that snuck up on me was sort of the corollary to Screechingly Obvious Code, and a cousin to Pandora's Box - which is, strictly speaking, and antipattern (except that in the end of the original story, Hope was left in the box).
If you have a function that is Obvious except for one small part, factor it out into its own function. The care comes in picking the incision points. The inputs and outputs to the new method need to be obvious (ie, don't factor out a function with side effects, that makes for spooky action at a distance), which may require some temporary data structures in order to iron out.
Going further, if you are considering a behavioral change that may not be obvious (performance optimization, error handling for very obscure cases) that has no prayer of being screechingly obvious, determine what lines will need to be changed, extract method on that code first, commit it, and only then make the change to the extracted code. Mikado method often comes into play here. Get used to revisionist commit history techniques.
What I've found through long observation is that people are more comfortable reverting such changes if they break when you are not there, which in turns make them more open to approving the change in the first place. "Will this bite me on the ass later?" is a pretty important consideration for most people. The commit history is very clean, and someone can revisit your decision years from now, when your user base and hardware are orders of magnitude bigger, when the runtime and hardware have very different timing ratios between different activities, and so on. And critically (for the optimization obsessed), compilers are very good at inlining leaf functions, which means the 'cost' of the context switch can be negligible in practice.
Also I don't know about anyone else but I've found that my attachment to such code is also fairly low. You are much more likely to get encouragement to 'go for it' when broaching the subject of undoing one of these changes, instead of a lecture about watching for regressions (I tend to "over-invest" in robustness, so deleting my code statistically represents a reversion to the mean wrt to code quality).
And perhaps more importantly to this conversation, they tend to tune out these leaf node methods when tracing code looking for bugs or trying to add new features, bugfixes. These structures don't nerdsnipe us, causing us to dump state on short term memory and have to start over. If I had a dollar for every time I said, "Aha! I found the place where we return null! Wait, why was I looking for that?" I could retire. This is, in my mind, the critical quality of Screechingly Obvious Code - in uses up a single slot of short term memory, facilitating code traversal.
