(Untitled)

[qazwsxmko]

I've said this before (a lot), but after the misery of trying to learn Rails from Agile Development with Rails, O'Reilly's Learning Rails makes my brain sigh with pleasure. Which is not to say that I know a lot about Rails now, but it's no longer the voodoo that ADR has tried to make it. I'm all for magic and flair, but not with code, guys. Never

Comments

[zanfur]

When it comes to programming, "agile" is a codeword for "I'm being trendy but don't actually know what I'm doing", in my experience.

[zanfur]

In general, I think that's a bit harsh. In my experience, agile tends to stand more for "just jump in and do it and figure it out along the way"... which is a fine way to learn and build, but your jumping in and just doing something is not a great way to teach /me/ about the thing that you're doing. At least afaic.

Er, LJ isn't letting me log in on this computer. So I guess this is an "anonymous" comment.

-Anna

[zanfur]

I'm referring to "Agile Software Development", which isn't that really at all...here, have a link:

Good Agile, Bad Agile

[zanfur]

Right, I know what agile software development is (though I don't think that article does a particularly good job of characterising anything except for what NOT to do and what Google DOES do). In my experience with agile sprints, once the tasks are divided up, there's a bit of floundering and then stuff gets written and revised as necessary, with the focus being on getting shit done and getting a small something working first, going back and making the thing look pretty later, and then integrating it into a whole last. Which again seems like a completely fine way of working if it works for you, and a fine way of /self/-instruction for a particular project, but a shitty way of teaching. When you're trying to teach a general concept, I think you have to present the whole first, and then present the general subcategories in a logical sequence, instead of just presenting the bits that happen to relate to some specific example.

[qazwsxmko]

I completely agree about the value maintaining a consistent example throughout a tutorial. I also have nothing against referring back to the same example throughout a whole book and building on the example, as long as you also present all the necessary concepts outside of the example in some kind of a logical and structured manner (so that if you were trying to find these concepts later, you wouldn't have to dig too much for them or have to go through the example from the beginning). It's also important to be mindful of what concepts your example is demonstrating, and what concepts it's not (and to make sure to fill in the gaps at the appropriate times).

Basically, I think consistent examples are great as long as they're used as a teaching aid and not as a substitute for the teaching itself.