0: Don't optimize anything, it's too difficult, just hack on the code until it produces correct answers without regard to performance.

1: Optimization takes time, so optimize the critical sections (by choosing appropriate algorithms + data structures) and don't worry about the rest.

2: Don't optimize anything, just write code naturally. The libraries your code calls into are already fast enough because they're written by experts.

3: Optimizing makes code more complicated, so only optimize the critical sections (e.g. with vector intrinsics or atomic memory operations).

4: Just write the code naturally and avoid writing any slow code.

You could create many Twitter-appropriate bell-curve images out of a single real-life distribution of skills/experience.

Same with the "technical debt" one. The midwit opinion is that you should take it on in the short term so it can be paid off by the business later on. But experts tend to just want to do the right thing(s) faster because they have the capacity to do so and don't sacrifice future speed towards often unjustified short-term goals.

IIRC, the midwit opinion was the original idea of technical debt. To you, is the beginner/expert version a misuse of the term, or has the thinking on technical debt changed?

Basically I wouldn't say that the idea of taking on technical debt in order to pay it off at a later date is beginner or expert. It's simply the norm within most businesses.

The expert probably goes deep on some problems and punts on others depending on how intractable or voidable they might be in future, but I wouldn't say there is a hard/fast rule they can apply. Also, I suspect they probably avoid the worse technical debts you get in weaker teams, so even if they appear to leave technical debt in some cases these are rarer or mitigatable. We can look at their actions instead of their words to see what side of the divide they are truly on...