Some hot-takes:

• OOP and Functional are not bad, they are different.
• The best language for you is the one that solves your problem. Said language could be very different for someone else.
• Documentation should explain why.
• "Contributing" sections would be a lot more helpful if they also explained the directory structure and how to find things instead of just pointing to "good first issue"s. ("good first issue" is a great trend, not bashing here)
• Some people don't contribute a lot to open source or have a ton of side projects and that's okay.
• The best code is the code not written. (performance tip)

I took Intro C++ as my first academic dive into programming and it almost ruined me lol

Developers should understand that "hard" and "soft" skills are a false dichotomy. The skills some folks call "soft" - communication, cooperation, etc. - are the core skills necessary to any kind of collaborative work, including ours. If you can't effectively communicate with humans, you will never reach the top of your field.

When I started my studies in CS, all our courses were meant to teach us concepts, paradigms, sometimes they would even involve an obscure language to force us to use a certain concept as there was no other way around.

At first I hated it, I wanted to build things, learn to make software and applications and all I was doing was some exercices. Now, with a step back I really appreciate what I learned and understand why the courses were built that way and I use it as a strength, I can easily switch tools and languages, all I need is to learn the syntax and the specificities.

I think it really depends on what you want, learning that way can kill your motivation but if you overcome it you will end up with a great adaptability.

A developer as the creator of a system is very different from the typical user of the system and might indeed be the most atypical kind of user there is.

Style guides are so the code is consistent and easy to read. Not because spaces are actually any better/worse than tabs.

Refactoring is the process of changing code to make it easier to change (either in the immediate, near, or far future) without changing its current behavior. Refactoring is not "making the code pretty for pretty sake" or "getting it ready for code review."

Programming languages are tools; not religions.

The Blub Paradox is the answer to most programming language arguments/roasts/etc. It also applies to editors vs IDEs, Linux vs Windows vs Mac, OOP vs FP.

That experience or expertise in a specific domain of business or industry is more valuable than the ability to program. It's the 80/20 distribution again. For most developers, 20% of your programming output is unique code, while probably 80% of it is modeling the business domain into an established web framework.

The project manager is important, and not just there to bug you.

When building systems and applications, people don't care how you've done it; just that it works and they understand how to use it.

Understanding business rules DOES matter. Coding a solution for a problem you don't understand is an uphill battle. When you're questioned about the issue you coded to, it can sometimes be embarrassing to admit you didn't understand the problem to begin with but you knew what the solution was. It's too easy sometimes to go in and change a value or an if statement without comprehending the surrounding issue, but it's difficult to defend it in the long run.