Hacker News Reader

Comment by sgdesign | Hacker News Reader

This is a nice-sounding programming mantra but it doesn't make much sense in the real world, in my opinion. Learning the "philosophy" of Redux is a natural by-product of learning how to actually use Redux.

To me this is the equivalent of saying "learn molecular chemistry, don't follow recipes" to someone who's trying to learn how to cook. It may be true that the most experienced chefs have a deep understanding of chemistry, but it's much more practical to start from the surface and dig deeper, compared to overwhelming newcomers with "principles" and "philosophies" right off the bat.

View on HN

>> To me this is the equivalent of saying "learn molecular chemistry, don't follow recipes" to someone who's trying to learn how to cook.

A more appropriate analogy would be learning specific recipes vs learning the flavour and texture of individual ingredients, so that you can mix them in new ways and learn how existing recipes work. You might want to start at the former but to be even a 'good' cook, you need to learn the latter. I guess this is more in line with the sentiment the GP is trying to express.

> Learning the "philosophy" of Redux is a natural by-product of learning how to actually use Redux.

I don't think that's natural at all. You might learn some kind of philosophy, but it's not neccessarily the right one. If frustrated or pressed for time, people might also give up completely and just resort to "copy-paste programming".

That said, the answer is not throwing some documentation full of abstract concepts at a novice and expect that they magically understand them in exactly the same way as the designers. That's just as bad. But I think many designers that tried that and are frustrated that it doesn't work try to fix it by declaring the concepts as "boilerplate" and hiding them from the users completely. That will work exactly until the user actually needs to know about the concept.

I believe you can grasp many abstract concepts a lot better if you actively work with them. So it's crucial to have a good progressive learning curve that makes you "experience" the concepts and not just read about them. (Ideally by first explaining why you need them and what problem they solve)

That's a pretty apt analogy, really. If you just want to be a line cook at a no name franchise, then by all means, blindly follow recipes. If you want to understand what you're actually doing and have the ability to create new stuff without using a cookie-cutter template, yeah, you're going to need to go deeper.

As a uni student, I had some degree of disdain about being taught from first principles when I really just wanted to build games and apps, but the further I get in my career, the more I appreciate this groundwork. Recipes and frameworks come and go. Theory and first principles are timeless.

That's a bad analogy.

Cooking is much less complex, so learning it without much background works rather well.

Just look what your philosophy brought us, a horde of 'developers' who thought JavaScript is jQuery.

Programming is not complex. Frameworks make it complex, in the sense that they force you to use nontrivial concepts (I'm not against frameworks as a whole; when you're trying to do something complex it may be hugely useful to use one).

Reply on news.ycombinator.com