3 ms·

I saw an argument online about whether web development beginners should focus on learning a framework (like say React) or focus more (and longer) on browser and

by dgb23 3y ago

I saw an argument online about whether web development beginners should focus on learning a framework (like say React) or focus more (and longer) on browser and web technologies (HTTP, HTML, CSS, JS etc.) Anyone who's been around for long enough knows that: - Making an effort to learn at least some of the stuff one abstraction layer below you, pays out big time in the long run. - Paradigms, frameworks and tools come and go. Concepts, standards and protocols last. Both of these categories have an almost infinite ceiling. - Solutions that are found by taking things away instead of adding things are better _now_ and especially _later_. People can find themselves emotionally attached to their favorite paradigm, framework or tool and loose sight of what problem it's supposed to solve. Productivity, expertise and confidence are a function of deep understanding and practice. It's easy to distract ourselves. This blog post makes a good case of avoiding unnecessary complexity with what they describe as "shortcuts". But really what they do is _lean into_ and extend what's already there.

tamiral 3y ago
There are so many bootcamps and people coming into web dev thinking its an easy way to make money that actually knowing the fundamentals is CRUCIAL in my opinion.
viking123 3y ago
But in job interviews, at least for me I have been questioned more about React itself than the fundamentals under it
- dgb23 3y ago
  That's fair. If you're on job search, prepare for the interview at hand! I'm not saying people shouldn't learn about paradigms, frameworks and tools. Or that they should overly focus on understanding their internals. But there's _leverage_ here that some (including younger me) might miss: If I'm getting asked how to use a specific tool, and I understand the principles behind it, then the surface usage becomes much easier to understand as well. Often you can _infer_ specifics or at least make a good argument of what you expect how something works and how you would go about in general. In the absolute worst case you make assumptions based on conceptual knowledge and apply "wishful thinking" (SICP). YMMV but I personally find it very impressive and fun when someone applies problem solving skills and conceptual knowledge with a dash of curiosity. These qualities combined with a strong grounding in concepts, standards, protocols and so on, will help you understand and adopt the surface level things quicker and with more confidence. As a (mostly) self-taught programmer, I was somewhat trapped in black box understanding for a while. My technical preferences and decisions where largely based on cultural things instead of technical grounding. From that perspective everything seemed so different and idiosyncratic. But after gaining more fundamental knowledge, trying out different approaches and talking to veterans, I started to see that they're all surface level re-inventions of the same stuff. And that insight is both liberating and powerful.
calpaterson 3y ago
> really what they do is _lean into_ and extend what's already there. There are already so many features implemented in unix/the web/python/etc that it's easiest just to go along with what is there. For example, csvbase logs to the systemd journal (when run under systemd - stderr otherwise): https://github.com/calpaterson/csvbase/blob/c1523615f10bbaa7492d8c4e0e034c7515fac27e/csvbase/logging.py#L20 https://github.com/calpaterson/csvbase/blob/c1523615f10bbaa7... One under recognised thing about systemd is that it provides a mini-ELK stack - so now I have indexed, searchable logs that auto-rotate and whatever (the defaults are quite good). I realise a lot of people strongly dislike systemd but I think this is a very nice feature for running services of this scale. One more shortcut: the backend for the blog is a csvbase table. The "4" in the url here is a csvbase_row_id :)

by dgb23 3y ago

tamiral 3y ago

There are so many bootcamps and people coming into web dev thinking its an easy way to make money that actually knowing the fundamentals is CRUCIAL in my opinion.

viking123 3y ago

But in job interviews, at least for me I have been questioned more about React itself than the fundamentals under it

dgb23 3y ago
That's fair. If you're on job search, prepare for the interview at hand! I'm not saying people shouldn't learn about paradigms, frameworks and tools. Or that they should overly focus on understanding their internals. But there's _leverage_ here that some (including younger me) might miss: If I'm getting asked how to use a specific tool, and I understand the principles behind it, then the surface usage becomes much easier to understand as well. Often you can _infer_ specifics or at least make a good argument of what you expect how something works and how you would go about in general. In the absolute worst case you make assumptions based on conceptual knowledge and apply "wishful thinking" (SICP). YMMV but I personally find it very impressive and fun when someone applies problem solving skills and conceptual knowledge with a dash of curiosity. These qualities combined with a strong grounding in concepts, standards, protocols and so on, will help you understand and adopt the surface level things quicker and with more confidence. As a (mostly) self-taught programmer, I was somewhat trapped in black box understanding for a while. My technical preferences and decisions where largely based on cultural things instead of technical grounding. From that perspective everything seemed so different and idiosyncratic. But after gaining more fundamental knowledge, trying out different approaches and talking to veterans, I started to see that they're all surface level re-inventions of the same stuff. And that insight is both liberating and powerful.

calpaterson 3y ago

> really what they do is _lean into_ and extend what's already there. There are already so many features implemented in unix/the web/python/etc that it's easiest just to go along with what is there. For example, csvbase logs to the systemd journal (when run under systemd - stderr otherwise): https://github.com/calpaterson/csvbase/blob/c1523615f10bbaa7492d8c4e0e034c7515fac27e/csvbase/logging.py#L20 https://github.com/calpaterson/csvbase/blob/c1523615f10bbaa7... One under recognised thing about systemd is that it provides a mini-ELK stack - so now I have indexed, searchable logs that auto-rotate and whatever (the defaults are quite good). I realise a lot of people strongly dislike systemd but I think this is a very nice feature for running services of this scale. One more shortcut: the backend for the blog is a csvbase table. The "4" in the url here is a csvbase_row_id :)