I don't know that I have a big bag of "big concepts that emerge from experience in actual production", but I can think of a few things that I still encounter with inexperienced coders I work with.
The mistake of coding as if a back-end web app is a run-once kind of thing. No memoizing for repeated pure function calls, repeated instantiation of connections that should be pooled, globals being crapped out everywhere and functions that depend on their existence vs being passed in.
Giant clots of if/then blocks for application "logic" and implicit state or action-at-a-distance fun lead to doom.
Failure to understand the cost of over-the-wire vs localized data calls.
Separating reads vs writes and/or immediately performing time-expensive tasks in-line. Granted the dark side of this can be premature optimization or complexity, but it's a lot easier to scale out when you've actually thought about how to do it while building things.
Tracking performance changes as a part of basic testing. Granted, it can be hard enough just to get them to build unit tests but simply demonstrating successful execution doesn't mean you haven't negatively affected the codebase by decreasing the performance.
Profile your damned code. Over the years you'll develop the sense of smell required to pre-detect poor design choices, but without a real insight into what the code is actually doing you'll be shooting arrows in the air trying to hit the real problem.
While premature optimization is a known-evil, premature complexity is also a real danger. You don't need a big OOP implementation for a simple function, and abstraction layers can run the real risk of becoming distraction layers making things much harder to debug or decipher when things inevitably go astray.
The mistake of coding as if a back-end web app is a run-once kind of thing. No memoizing for repeated pure function calls, repeated instantiation of connections that should be pooled, globals being crapped out everywhere and functions that depend on their existence vs being passed in.
Giant clots of if/then blocks for application "logic" and implicit state or action-at-a-distance fun lead to doom.
Failure to understand the cost of over-the-wire vs localized data calls.
Separating reads vs writes and/or immediately performing time-expensive tasks in-line. Granted the dark side of this can be premature optimization or complexity, but it's a lot easier to scale out when you've actually thought about how to do it while building things.
Tracking performance changes as a part of basic testing. Granted, it can be hard enough just to get them to build unit tests but simply demonstrating successful execution doesn't mean you haven't negatively affected the codebase by decreasing the performance.
Profile your damned code. Over the years you'll develop the sense of smell required to pre-detect poor design choices, but without a real insight into what the code is actually doing you'll be shooting arrows in the air trying to hit the real problem.
While premature optimization is a known-evil, premature complexity is also a real danger. You don't need a big OOP implementation for a simple function, and abstraction layers can run the real risk of becoming distraction layers making things much harder to debug or decipher when things inevitably go astray.