3 ms·

How would you describe a path to learn this kind of things ? (Even just dropping a link would be appreciated). Indeed typical education is about algos and prog

How would you describe a path to learn this kind of things ? (Even just dropping a link would be appreciated). Indeed typical education is about algos and programing paradigm (like procedural, functional, OO, etc) and context (system, native apps, web, data), but I don't remember/understand much about what you describe (but definitely faced it on toy projects and reacted like the "junior way" you describe). Heck we even did some deep stuff like language grammar / compiler design / and this thing with the petri boxes but it's a lot less practical and actionable I find.

Groxx 2y ago
Frankly: a comprehensive book about the language / subject is generally the best source. Fixing those foundational knowledge gaps takes time, because it's often not clear to anyone exactly what the gaps are - better to be exhaustive and fix it for real rather than thinking the "ah hah!" moment they just had was the only issue. Not because I think ink on paper is superior somehow, but because books go in depth in ways that blog posts almost never do - if they did, they'd be as large as a book, and nobody reads or writes those. Narrow, highly technical ones exist and are fantastic, but they largely assume foundational knowledge, they don't generally teach it. --- Learners are stuck in a weird place with programming. At the extreme beginning there's an unbelievable amount of high-quality information, guided lessons, etc, it's one of the best subjects to self-learn on period. I love it. Experts also have a lot excellent material because there are a lot of highly technical blogs about almost anything under the sun, and many of them are relevant for years if not decades. Programmers are extremely open about sharing their knowledge at the fringes, and the whole ecosystem puts in a lot of effort to make it discoverable. The middle ground though, where you know how to put words in a text file and have it run, but don't know how to go beyond that, is... pretty much just "get some experience". Write more code, read more code, do more coding at work. It's highly unstructured and highly varied because you've left the well-trodden beginning and have not yet found your niche (nor do you have the knowledge needed to even find your niche). It's this middle-ground where I see a lot of people get stuck and churn out, or just haphazardly struggle forever, especially if they lack a solid foundation to build on, because every new thing they learn doesn't quite fit with anything else and they just memorize patterns rather than thinking. Which I do not claim is the wrong choice: if that's all you need, then that's likely (by far) the best effort/reward payoff, and I think that's where the vast majority of people can stop and be happy. But if you want to go further, it's soul-draining and often looks like there's no escape from the chaotic drudgery. Making completely sure the basics are in place and that you think about everything added on top of that is the only real way I've seen people make progress. Whether that's through a mentor, or a book, or just brute-forcing it by hand on your own doesn't seem to matter at all, you just have to find one that works for you. The good news though is that after you've got "I can put words in a text file and it runs" figured out, it goes a lot faster than it does when you're starting in the beginning. And a lot of what you've already learned will be reinforced or slightly corrected in ways that often make immediate sense, because you have a lot of context for how it has failed or worked in the past.
- bionsystem 2y ago
  Thanks a lot for the detailed answer. Would you recommend specific publishers or it's a book-by-book basis ? I heard good things about manning.
  - Groxx 2y ago
    Very much book-by-book in my experience :\ Historically I would've recommended O'Reilly, but they've been absolutely trashing their brand by publishing everything under the sun without decent editing (bad english, outrageously clear flaws in code, entire missing paragraphs, you name it - editing matters). Manning has some real gems too, but I've flipped through enough mediocre ones that I can't make any broad claims (beyond "buyer beware" but it's worth checking anyway). Which is not particularly useful advice, I know. It's hard to judge quality before you know what quality looks like, at which point you're probably done with the book and maybe much further. So concretely I can really only recommend: 0) Hit a bookstore or library, browse through the books a bit. 1) Don't buy any giant books (unless you like them). They usually waste absurd amounts of space on stuff that won't remain true in the long run (e.g. individual libraries), and the sheer size means people tend to churn out and not read enough of it to get much of a benefit. Larger also often means worse editing, more mistakes per page, etc because it costs more to check more :\ If you want a physical reference for stuff the book covers, then it can be worth it, but otherwise no. Reference-like material is generally available online, but more up to date. 2) Actually try to build things the book guides you through. Then change it. Break it, debug it, fix it, etc. Make 100% sure what you wrote and why it broke makes sense, not that the book has convinced you that what they wrote is reasonable, which are very different things. The latter is just a sign of good writing, and is useless otherwise. 3) The more-detailed first-party docs in ~all popular languages are at least as good as most books (and sometimes much better), are more likely to be up to date, and are absolutely worth reading. Read the language spec, read the technical blog articles and guides, they're generally truly excellent. Even if you don't understand it all yet, it's exposure to quality code and patterns and concerns you haven't seen, from what are almost always literal experts + edited by literal experts.

Groxx 2y ago

Frankly: a comprehensive book about the language / subject is generally the best source. Fixing those foundational knowledge gaps takes time, because it's often not clear to anyone exactly what the gaps are - better to be exhaustive and fix it for real rather than thinking the "ah hah!" moment they just had was the only issue. Not because I think ink on paper is superior somehow, but because books go in depth in ways that blog posts almost never do - if they did, they'd be as large as a book, and nobody reads or writes those. Narrow, highly technical ones exist and are fantastic, but they largely assume foundational knowledge, they don't generally teach it. --- Learners are stuck in a weird place with programming. At the extreme beginning there's an unbelievable amount of high-quality information, guided lessons, etc, it's one of the best subjects to self-learn on period. I love it. Experts also have a lot excellent material because there are a lot of highly technical blogs about almost anything under the sun, and many of them are relevant for years if not decades. Programmers are extremely open about sharing their knowledge at the fringes, and the whole ecosystem puts in a lot of effort to make it discoverable. The middle ground though, where you know how to put words in a text file and have it run, but don't know how to go beyond that, is... pretty much just "get some experience". Write more code, read more code, do more coding at work. It's highly unstructured and highly varied because you've left the well-trodden beginning and have not yet found your niche (nor do you have the knowledge needed to even find your niche). It's this middle-ground where I see a lot of people get stuck and churn out, or just haphazardly struggle forever, especially if they lack a solid foundation to build on, because every new thing they learn doesn't quite fit with anything else and they just memorize patterns rather than thinking. Which I do not claim is the wrong choice: if that's all you need, then that's likely (by far) the best effort/reward payoff, and I think that's where the vast majority of people can stop and be happy. But if you want to go further, it's soul-draining and often looks like there's no escape from the chaotic drudgery. Making completely sure the basics are in place and that you think about everything added on top of that is the only real way I've seen people make progress. Whether that's through a mentor, or a book, or just brute-forcing it by hand on your own doesn't seem to matter at all, you just have to find one that works for you. The good news though is that after you've got "I can put words in a text file and it runs" figured out, it goes a lot faster than it does when you're starting in the beginning. And a lot of what you've already learned will be reinforced or slightly corrected in ways that often make immediate sense, because you have a lot of context for how it has failed or worked in the past.

bionsystem 2y ago
Thanks a lot for the detailed answer. Would you recommend specific publishers or it's a book-by-book basis ? I heard good things about manning.
- Groxx 2y ago
  Very much book-by-book in my experience :\ Historically I would've recommended O'Reilly, but they've been absolutely trashing their brand by publishing everything under the sun without decent editing (bad english, outrageously clear flaws in code, entire missing paragraphs, you name it - editing matters). Manning has some real gems too, but I've flipped through enough mediocre ones that I can't make any broad claims (beyond "buyer beware" but it's worth checking anyway). Which is not particularly useful advice, I know. It's hard to judge quality before you know what quality looks like, at which point you're probably done with the book and maybe much further. So concretely I can really only recommend: 0) Hit a bookstore or library, browse through the books a bit. 1) Don't buy any giant books (unless you like them). They usually waste absurd amounts of space on stuff that won't remain true in the long run (e.g. individual libraries), and the sheer size means people tend to churn out and not read enough of it to get much of a benefit. Larger also often means worse editing, more mistakes per page, etc because it costs more to check more :\ If you want a physical reference for stuff the book covers, then it can be worth it, but otherwise no. Reference-like material is generally available online, but more up to date. 2) Actually try to build things the book guides you through. Then change it. Break it, debug it, fix it, etc. Make 100% sure what you wrote and why it broke makes sense, not that the book has convinced you that what they wrote is reasonable, which are very different things. The latter is just a sign of good writing, and is useless otherwise. 3) The more-detailed first-party docs in ~all popular languages are at least as good as most books (and sometimes much better), are more likely to be up to date, and are absolutely worth reading. Read the language spec, read the technical blog articles and guides, they're generally truly excellent. Even if you don't understand it all yet, it's exposure to quality code and patterns and concerns you haven't seen, from what are almost always literal experts + edited by literal experts.