I believe learning these before getting into coding will help beginners tremendously. The more backstory they know, the better, because they tend to have these unanswered questions in their mind and they either don’t ask them or they get buried with some answer they came up with on their own to them. I call these gaps of knowledge that eventually get filled in time piece by piece, but ideally some of them should be learned at the foundation level. It’s related to “learn concepts, not technologies”; when you know how different things function at a lower level, you can pick up new technologies because they are all tied to those concepts.

A programming language is a tool. Different languages have their own advantages and disadvantages depending on their purposes. You learn programming concepts prevalent in all languages and make a calculated decision to use a specific language for a business requirement when you need to. When you’re building an application, you will have state; data that can be in-memory or written somewhere more persistent like a database. You can think of data as input, and whatever you to that input or with that input to achieve a certain goal is output. developer, you deal with data via data structures, you mold data into a shape that makes sense for the application requirements.

There are principles that are generally agreed upon, in order to achieve maximum efficiency as a developer, for both the developers’ sake as well as business requirements’ sake. The following is my own list of software philosophies which may or may not include the aforementioned principles:

Avoid side-effects

Avoid non-standard fallbacks

Avoid magic

Explicit over implicit, verbose and direct over short and polluted

Hierarchical organization and structure

You can never have too much decoupling or too many pure functions

Self-explanatory code via aptly named variables and minimal comments, also quality of code and consistent data structures that act as living documentation

Convention over Configuration (provide configuration but ditch it where it interrupts convention)

Principle of Least Surprise (provide what the developer would expect, i.e. the standard)

Proper testing, knowing what to test, etc.

These principles can never be absolute and fit any situation and in maximum capacity. This is a common problem in software.

A design pattern is a solution to a common problem. A problem common enough to warrant a universal solution.