I think that You have encountered typical issues that May rise when you use the language at low level without any frameworks, libraries or even Just patterns.
I am a developer since 20 years now and I can tell you that at the beginning - especially languages such as PHP, now JavaScript - you build your own tools tailored to a specific domain and that Is fine, but It Is not so portable as you May think.
When you are using a framework (a real One such as Ror, laravel, Adonis, masonite, etc.) You are automatically (and sometimes automagically) inhereting well tailored and robust patterns and "solutions" that are engineered by a lot of developers that have struggled against the Same challenges.
I understand what you are talking about, but I will tell you so that you should not educate programmers who will not be a php programmer, but a laravel programmer. That is, you say that I should not reinvent the wheel, since there are already all the solutions, and I am talking about the fact that you have to go through everything yourself in order to become a specialist, and not use ready-made solutions. There is nothing wrong with ready-made solutions, it is just that the degradation of a specialist follows their use.
Moreover, there will be no development in the case of using ready-made solutions. Of course, the result will be better and faster, but it looks like google programmers, stackoverflow gurus and other people who do not know how to solve problems on their own, but only look for answers and copy them.
Mmm... well... no, but this is just my opinion: believe me, there are no "ready-made solutions" out there, at least for "non-fake-developers" or if You are really developing "something" in order to solve a feat/issue (I've encountered so many peoples that install Wordpress themes/plugins and call themself "developers").
You asked for advices and I am giving some, but You don't have to do what I am telling You, I am just outlinining some points that came from experience:
What I am talking about is at a lower level: if you are using a package manager such as Composer, NPM, Cargo, etc. You are "injecting" a piece of software into your software (that is an approach that even OS - Linux - use very widely).
The package's content is not made by a holy ghost, so You have to always check what it does at its root, or at least have a general idea: it could impact compatibility, security and performance very badly and, from a developer point-of-view, is always worthed checking code made by others, simply because You are always learning or even just stating to approve or reject that package.
On the other hand we WANT/NEED those packages because the process described above it has probably been iterated over and over by other developers that came from different background and different experience.
Every single developer could potentially spot/fix something that the previous creator did not know: the problem is that every developer has his/hers way of building/organizing things that can be productive only for him/her and this - believe me - can be a mess.
That concept may apply at a "code" level (ways of doing a operation by enhancing its performance or readiness) or mostly at an "architecture" level (for example Your solution may work in an Nginx/Apache environment, but what happen when You are using something like Swoole or RoadRunner? and what about containers? tests? code standards?)
Moreover if You are in the loop and see things at higher level, You'll realize that very different "packages"/"frameworks"/"libraries" re-use (or just simply re-write) something that has been first developed in an other language/platform, and that is powerfull because You are not tied to a single language, but You understand the engineering process behind.
For example the frameworks that I've mentioned in my earlier comment were not random (ROR, Laravel, Adonis, Masonite, etc.). If You look at them you'll see that they all use same concepts and even "syntax" of calling things, even if the underlying implementation and language feats is very different: if You came from Laravel and You know what a "migration" or a "seeder" does, You will probably understand the some concept in Adonis (Node) but so other people around the world.
When You use these tools it is your wisdom or experience that tells You the proper way to use a tool (a hammer can't do the work of a screwdriver and viceversa).
It is imperative that before even approaching a package or an entire framework You DO need to know the vanilla language very well (for example real React developers are really good at vanilla Javascript): so I don't think that - on a productive point-of-view - there is such thing like "Laravel developer" VS "PHP developer" and if there is probably someone will "pay the bill" sooner or later.
I simply think that "strictness" (in the code or in the architecture) is there for a reason, and on a long term is very productive, resilient and portable: but there is nothing wrong in writing your own stuff if You feel confident and productive - however is always worthing analyzing how other devs who encountered the same issue/challenge solved or just organized things.
Bye
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think that You have encountered typical issues that May rise when you use the language at low level without any frameworks, libraries or even Just patterns.
I am a developer since 20 years now and I can tell you that at the beginning - especially languages such as PHP, now JavaScript - you build your own tools tailored to a specific domain and that Is fine, but It Is not so portable as you May think.
When you are using a framework (a real One such as Ror, laravel, Adonis, masonite, etc.) You are automatically (and sometimes automagically) inhereting well tailored and robust patterns and "solutions" that are engineered by a lot of developers that have struggled against the Same challenges.
Taking a further step I really advice you to look at this: github.com/Mahmoudz/Porto
I understand what you are talking about, but I will tell you so that you should not educate programmers who will not be a php programmer, but a laravel programmer. That is, you say that I should not reinvent the wheel, since there are already all the solutions, and I am talking about the fact that you have to go through everything yourself in order to become a specialist, and not use ready-made solutions. There is nothing wrong with ready-made solutions, it is just that the degradation of a specialist follows their use.
Moreover, there will be no development in the case of using ready-made solutions. Of course, the result will be better and faster, but it looks like google programmers, stackoverflow gurus and other people who do not know how to solve problems on their own, but only look for answers and copy them.
Mmm... well... no, but this is just my opinion: believe me, there are no "ready-made solutions" out there, at least for "non-fake-developers" or if You are really developing "something" in order to solve a feat/issue (I've encountered so many peoples that install Wordpress themes/plugins and call themself "developers").
You asked for advices and I am giving some, but You don't have to do what I am telling You, I am just outlinining some points that came from experience:
What I am talking about is at a lower level: if you are using a package manager such as Composer, NPM, Cargo, etc. You are "injecting" a piece of software into your software (that is an approach that even OS - Linux - use very widely).
The package's content is not made by a holy ghost, so You have to always check what it does at its root, or at least have a general idea: it could impact compatibility, security and performance very badly and, from a developer point-of-view, is always worthed checking code made by others, simply because You are always learning or even just stating to approve or reject that package.
On the other hand we WANT/NEED those packages because the process described above it has probably been iterated over and over by other developers that came from different background and different experience.
Every single developer could potentially spot/fix something that the previous creator did not know: the problem is that every developer has his/hers way of building/organizing things that can be productive only for him/her and this - believe me - can be a mess.
That concept may apply at a "code" level (ways of doing a operation by enhancing its performance or readiness) or mostly at an "architecture" level (for example Your solution may work in an Nginx/Apache environment, but what happen when You are using something like Swoole or RoadRunner? and what about containers? tests? code standards?)
Moreover if You are in the loop and see things at higher level, You'll realize that very different "packages"/"frameworks"/"libraries" re-use (or just simply re-write) something that has been first developed in an other language/platform, and that is powerfull because You are not tied to a single language, but You understand the engineering process behind.
For example the frameworks that I've mentioned in my earlier comment were not random (ROR, Laravel, Adonis, Masonite, etc.). If You look at them you'll see that they all use same concepts and even "syntax" of calling things, even if the underlying implementation and language feats is very different: if You came from Laravel and You know what a "migration" or a "seeder" does, You will probably understand the some concept in Adonis (Node) but so other people around the world.
When You use these tools it is your wisdom or experience that tells You the proper way to use a tool (a hammer can't do the work of a screwdriver and viceversa).
It is imperative that before even approaching a package or an entire framework You DO need to know the vanilla language very well (for example real React developers are really good at vanilla Javascript): so I don't think that - on a productive point-of-view - there is such thing like "Laravel developer" VS "PHP developer" and if there is probably someone will "pay the bill" sooner or later.
I simply think that "strictness" (in the code or in the architecture) is there for a reason, and on a long term is very productive, resilient and portable: but there is nothing wrong in writing your own stuff if You feel confident and productive - however is always worthing analyzing how other devs who encountered the same issue/challenge solved or just organized things.
Bye