I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
What order you choose to learn thing in is your business, not anybody else's.
However, you need to keep in mind the two reasons why 'fundamentals first' is what so many people recommend:
There are many things that just don't make sense if you don't already have the background for them.
it's very important when using a complicated tool to understand how that tool actually works (not what it does, but how it does what it does).
The first point is just a non-issue for some people (they quite simply are fine with "because that's the way it's done" reasoning for why they should do things they way they need to do them), but even for those for whom it's an issue, it's just a side effect of how they learn.
The second point though is something that often gets neglected, even with 'fundamentals first' approaches, and it's a huge but often never discussed issue among software developers. Understanding how the tool/library/platform/framework you're using actually works is important for a couple of reasons:
It helps you understand when you actually need to use that tool. For example, many sites that use React or a similar framework don't actually need the framework, they would work just fine with a minimalistic in-house MVC or MVVM layer built on HTML <template> tags and the Fetch API. However, the developers quite often either just don't know this (they know how to use framework X, so that's what they'll use even if there are better choices) or they don't know enough about how the framework works to be able to prove to the people who are responsible for the decision that it's actually worth it (and it usually is, a truly minimal MVC layer is only a few thousand lines of code client side, compared to the almost 500k lines of code in React).
When something inevitably goes wrong, it helps you understand why it's gone wrong. Being able to differentiate from a limitation of the platform, a bug in your own code, and a bug in your dependencies is super important to efficiently debugging issues you run into, and it's exponentially easier if you have a proper understanding of how everything you're working with actually works.
It helps you avoid bugs in the first place. A pretty sizable percentage of bugs in software are a result of the developer not actually having a complete understanding of what the tools they were using do. This goes double for bugs in websites and web apps. Many of these could be completely avoided if developers actually properly understood what they were working with.
I agree with many things. One thing that helped me is to put the problem in the center of everything and always think about the frameworks and languages as a tool to solve them.
We sometimes just fall in love with coding and forget what we do it for.
I beg to disagree: in theory it would be perfect if you could gather all the knowledge to chose between let's say mini-homemade-MVC and React. In practice that is a very tough task for even the most seasoned devs/CTO, let alone a beginner.
I would rather say, the day you can make that, you have mastered the fundamentals. Before that, I think you're much better off trying something a bit blindly and learn from your mistakes.
I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
But that doesn't mean that knowing the fundamentals first can't help you significantly. I'll admit my particular example was a rather complex one, but there are plenty of simpler ones. For example, properly understanding the fundamentals helps you decide when it matters enough to use a more complex data structure than trivialities like a list or map.
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.
What order you choose to learn thing in is your business, not anybody else's.
However, you need to keep in mind the two reasons why 'fundamentals first' is what so many people recommend:
The first point is just a non-issue for some people (they quite simply are fine with "because that's the way it's done" reasoning for why they should do things they way they need to do them), but even for those for whom it's an issue, it's just a side effect of how they learn.
The second point though is something that often gets neglected, even with 'fundamentals first' approaches, and it's a huge but often never discussed issue among software developers. Understanding how the tool/library/platform/framework you're using actually works is important for a couple of reasons:
<template>tags and the Fetch API. However, the developers quite often either just don't know this (they know how to use framework X, so that's what they'll use even if there are better choices) or they don't know enough about how the framework works to be able to prove to the people who are responsible for the decision that it's actually worth it (and it usually is, a truly minimal MVC layer is only a few thousand lines of code client side, compared to the almost 500k lines of code in React).I agree with many things. One thing that helped me is to put the problem in the center of everything and always think about the frameworks and languages as a tool to solve them.
We sometimes just fall in love with coding and forget what we do it for.
I beg to disagree: in theory it would be perfect if you could gather all the knowledge to chose between let's say mini-homemade-MVC and React. In practice that is a very tough task for even the most seasoned devs/CTO, let alone a beginner.
I would rather say, the day you can make that, you have mastered the fundamentals. Before that, I think you're much better off trying something a bit blindly and learn from your mistakes.
But that doesn't mean that knowing the fundamentals first can't help you significantly. I'll admit my particular example was a rather complex one, but there are plenty of simpler ones. For example, properly understanding the fundamentals helps you decide when it matters enough to use a more complex data structure than trivialities like a list or map.