And as far as under-specifying versus over-specifying, I find that understanding the domain problem is better inoculation against horribly written code than understanding "inefficient" boolean branching.
> lesser programmers are afraid to fix it
Red flag.
http://highscalability.com/numbers-everyone-should-know
If you just had to say "avoid nested loops" there would be no problem. Programming a solution that works at scale requires math and understanding where you will have bottlenecks before you write a single line of code.
>understanding the domain problem is better inoculation
How does one understand a problem without understanding boolean algebra?
Example. You have good/bad credit, car/motorcycle, new/used, drivers license yes/no. Which combinations allow testDrive()? Now add condition 'ok' to credit, moped and 18 wheeler to vehicles, and commercial to driver's license, because the boss forgot about those. Now how many combinations? Who is allowed to do what? How do you arrange the code so you don't spend time evaluating methods when driver's license of 'no' can short circuit the entire operation? (oh, except for moped, in certain states)
That's entirely boolean logic. If a person is not good at that, they suck at programming AND understanding domain problems.
Because in 12 months, nobody is going to know that you saved 2 operations by cleverly "arranging" your code.
I'm not saying you shouldn't arrange your code as best you can, but performance in this situation would absolutely be secondary to readability.
The link you give has nothing to do with the topic of math. It's mostly about knowing how your application is interacting with the system and a basic pragmatic approach to lock contention (also not math).