6 ms·

I feel like something lost for (web) programmers is how to construct complex systems in a “do it yourself” yet practical manner. My hobby of doing game dev (dr

I feel like something lost for (web) programmers is how to construct complex systems in a “do it yourself” yet practical manner. My hobby of doing game dev (driven by automated testing) has taught me so much about patterns of abstraction, boundary making, and modularity. Domain driven design makes so much more sense given my stint in hobbyist game dev. (buyer beware: game dev pedagogy is awful and many lessons I’ve had to discover myself) In my day job as a web dev I notice that my team/company think exclusively in our framework and we seem to push everything into the framework. I wish we treated react as just a view layer but so much more gets pushed into react. We’re so hooked on the sauce that writing anything outside of react is defacto considered an anti pattern. I know there has to be a better way but before I can know what that is I’ll have to understand why people adopt what I’ll call “framework brain (rot).” I kinda suspect programmer pedagogy is fueled by clickbait pretenders who find it easier to teach frameworks than the tough stuff like how to make a complex system easy & practical to build. Let me know what your speculation on this subject might be.

fennecfoxy 3y ago
What has been lost can be gained again. It's like C developers smirking and demeaning web developers because "kids these days don't know anything about computers or memory management" as if they truly believe that that's true because newer devs aren't smart enough to understand it, rather than the ground truth that it's just not relevant to those newer devs, and that they could easily learn everything the jaded C dev knows, if it became relevant/useful again. I definitely believe that a devs exposure to various languages/frameworks is important though, even if they only work in one domain. Someone who is a React dev will try to apply a React spanner to everything they do, but then again someone who is a C dev will write C-like React code (or just outright refuse to engage in web dev).
- shrimp_emoji 3y ago
  I think the changing demographics of developers counters this argument. I think it takes a special kind of person to grok C and C++. If offered C/C++ on the one hand and JavaScript/Python on the other, very few people in the world will choose C/C++. Back in tha day, when C and C++ were the only games in town (and programming wasn't as lucrative), the industry naturally filtered for these people. Today, it lets more people in than ever before. These new people, it can be reasonably argued, are not as smart as those select few from yesteryear. The fact that they're not exposed to the mind-scrambling vagaries of architecture differences, which means the barrier of entry and attrition rate are far lower, should pump that intuition, no?
simple-thoughts 3y ago
You’ve hit it on the head. A well written react app will have a lot of code that isn’t in hooks or components and is instead imported by those. That said anything to do with the presentation of the app should be within react, with important exceptions.
tcfunk 3y ago
> My hobby of doing game dev (driven by automated testing) I'm kinda curious about this. Do you have any good resources on automated testing for games?
- sovietmudkipz 3y ago
  Nope! It’s all synthesized knowledge from other sources. I’m simply reading, doing, and thinking a bunch to work out what makes sense. If you ask about automated testing for game dev you quickly learn there is very very little desire to entertain the subject. I’m unclear why. At some point I’d love to share my insights as videos and/or a blog series.
chefandy 3y ago
> I kinda suspect programmer pedagogy is fueled by clickbait pretenders who find it easier to teach frameworks than the tough stuff like how to make a complex system easy & practical to build. There's a lot to balance making these decisions at a project's inception. NIH bias can cost you a lot for no benefit beyond self-satisfaction. There's a good chance making something with a current stable framework and migrating to a new one down the road will have taken far less time than making the initial RYO version. You'll also be able to hire people who already know how a big chunk of your codebase works, and lots of your underlying functionality is already documented. Additionally, pedagogy is very different from practice. Most of the time when young me decided to do something the hard— but "more elegant" and "simpler" "more correct"— way rather than using a library or something, it was because I didn't actually know how hard the hard way was. Those are mistakes you only make once. It's true that some people use frameworks because they don't understand how to do what frameworks do under the hood. A lot of other people use frameworks because they know exactly what it takes to recreate what that framework is doing under the hood. That obviously doesn't work if your code uses very little of what the framework offers— but they are generally designed to bring a lot to common use cases, and can save you vast amounts of time, energy, and money if judiciously applied. Just like any other tools, they've got their good use cases, bad use cases, and ways to outright abuse them. A good understanding of your requirements, the preferred methods to address them, and the current tooling available is the way to decide which of those scenarios a framework would fit into.

fennecfoxy 3y ago

What has been lost can be gained again. It's like C developers smirking and demeaning web developers because "kids these days don't know anything about computers or memory management" as if they truly believe that that's true because newer devs aren't smart enough to understand it, rather than the ground truth that it's just not relevant to those newer devs, and that they could easily learn everything the jaded C dev knows, if it became relevant/useful again. I definitely believe that a devs exposure to various languages/frameworks is important though, even if they only work in one domain. Someone who is a React dev will try to apply a React spanner to everything they do, but then again someone who is a C dev will write C-like React code (or just outright refuse to engage in web dev).

shrimp_emoji 3y ago
I think the changing demographics of developers counters this argument. I think it takes a special kind of person to grok C and C++. If offered C/C++ on the one hand and JavaScript/Python on the other, very few people in the world will choose C/C++. Back in tha day, when C and C++ were the only games in town (and programming wasn't as lucrative), the industry naturally filtered for these people. Today, it lets more people in than ever before. These new people, it can be reasonably argued, are not as smart as those select few from yesteryear. The fact that they're not exposed to the mind-scrambling vagaries of architecture differences, which means the barrier of entry and attrition rate are far lower, should pump that intuition, no?

simple-thoughts 3y ago

You’ve hit it on the head. A well written react app will have a lot of code that isn’t in hooks or components and is instead imported by those. That said anything to do with the presentation of the app should be within react, with important exceptions.

tcfunk 3y ago

> My hobby of doing game dev (driven by automated testing) I'm kinda curious about this. Do you have any good resources on automated testing for games?

sovietmudkipz 3y ago
Nope! It’s all synthesized knowledge from other sources. I’m simply reading, doing, and thinking a bunch to work out what makes sense. If you ask about automated testing for game dev you quickly learn there is very very little desire to entertain the subject. I’m unclear why. At some point I’d love to share my insights as videos and/or a blog series.

chefandy 3y ago

> I kinda suspect programmer pedagogy is fueled by clickbait pretenders who find it easier to teach frameworks than the tough stuff like how to make a complex system easy & practical to build. There's a lot to balance making these decisions at a project's inception. NIH bias can cost you a lot for no benefit beyond self-satisfaction. There's a good chance making something with a current stable framework and migrating to a new one down the road will have taken far less time than making the initial RYO version. You'll also be able to hire people who already know how a big chunk of your codebase works, and lots of your underlying functionality is already documented. Additionally, pedagogy is very different from practice. Most of the time when young me decided to do something the hard— but "more elegant" and "simpler" "more correct"— way rather than using a library or something, it was because I didn't actually know how hard the hard way was. Those are mistakes you only make once. It's true that some people use frameworks because they don't understand how to do what frameworks do under the hood. A lot of other people use frameworks because they know exactly what it takes to recreate what that framework is doing under the hood. That obviously doesn't work if your code uses very little of what the framework offers— but they are generally designed to bring a lot to common use cases, and can save you vast amounts of time, energy, and money if judiciously applied. Just like any other tools, they've got their good use cases, bad use cases, and ways to outright abuse them. A good understanding of your requirements, the preferred methods to address them, and the current tooling available is the way to decide which of those scenarios a framework would fit into.