Ask HN: When learning a new framework, should I try to understand everything? | Hacker News Reader

Ask HN: When learning a new framework, should I try to understand everything?

4 pointsJ-dawg5 comments

I've recently been learning AngularJS. The framework makes it easy to get a lot of stuff done fast, but I'm finding it very challenging to understand what's going on under the hood.

I feel like I'm in danger of becoming a cargo cultist, copying and pasting boilerplate code because "that's the way it's done", not because I really understand it.

Am I being too hard on myself? I guess a balance has to be struck between productivity and understanding, I'm just not sure where that line should be drawn.

What works for you? Is it better to dive in and finish a project, even if it's cobbled together from StackOverflow snippets and code borrowed from tutorials? Or should I take it as I sign that I'm out of my depth and study the underlying JavaScript until I understand it?

View on HN

> Am I being too hard on myself?

Yes

> What works for you? Is it better to dive in and finish a project, even if it's cobbled together from StackOverflow snippets and code borrowed from tutorials? Or should I take it as I sign that I'm out of my depth and study the underlying JavaScript until I understand it?

No and No

---

The purpose of a framework is to abstract the nuts and bolts of MVC into... MVC (or whatever pattern Angular uses). All you need to know are assumptions on how it works, and not drill down to the if statement that caused this code to run.

For instance, to get myself acquainted with Angular (I had prior experience with Ember and Backbone), I needed to know how it was the same and different from the approaches I already know:

- How the rendering cycle works (when data is set, when it gets rendered). All you need to know about it is what runs when.

- How Promises work, because most of Angular is Promise-based (resources, $http methods). All you need to know is when they're resolved and rejected, not how they work internally.

- How dependency injection works. Angular does some weird static analysis under the hood, and doesn't inject the dependency or run code if not being used. You don't need to know the logic of how it resolves them, just use them.

- How to structure code properly and write it elegantly (because directives are not all that elegant to build). This is based on personal preference. Learn from terribly copy-pasted code.

Everything else in Angular is plain JS and generic programming concepts (event emitters, watchers, inheritance) which you can learn but need not pry open the machine to understand.

1. I don't think you have to understand everything. However, you should understand the parts that you use.

2. I find it critical to be able to rationalize about what the language, compiler/runtime and framework should be doing. This is never learned up front, but do take time periodically to understand what should be happening. For example, take 2 weeks to re-read JS the Good Parts. As you read, apply what you're learning to your code.

3. "the ways it's done". IME, "the way it's done" is too often "the way one engineer blogged about it and then 1,000 engineers reblogged without actually understanding why". Just because a solution is repeated over and over, does not mean its the right one for your situation.

4. the balance between understanding and productivity. Long term, the more you understand, the more productive you'll be. However, there is a time investment in the short run. Just balance the two based on your immediate needs. As for understanding, set a schedule of 30 minutes per night where you read. You won't learn everything at once, but it will happen over time.

5. Study JavaScript the language. JS, due to its async nature, is very different. Getting to know the language will make the Angular and/or any future frameworks you use a lot easier to think about.

If you want to understand everything, you first have to understand one thing. To start using a framework, learn the Table of Contents to its documentation. As you go about accomplishing objectives, pick features that look interesting and read the documentation for them.

If you do that while cobbling the project together with code snippets from StackOverflow, you'll end up understanding them when you optimize their implementation for your use case.

Do you understand everything about your OS? Your browser? Your user's browsers? Networking? Security?

The short answer is no, frameworks are yet another level of abstraction where some assumptions are made and [ideally] are well implemented/tested.

My long answer would be: try to understand how it works, what are it's assumptions and what does it do differently/similarly to other frameworks; but do not try to understand down to the code, unless you spot and dig for a bug or are interested in collaborate with its development.

Both book learning and learning by doing have a place.

When I am learning something challenging I load a lot of PDF documentation on my tablet and read it while I do cardio at the gym. I expect to read the docs cover to cover five times or so.

While I am doing this I am also learning by doing, but the book aspect means I get to understand what is going on.

Reply on news.ycombinator.com