B Before A | Hacker News Reader

B Before A

billwadge.wordpress.com

45 pointsmr_tyzic18 comments

I remember when I was little, I wanted to learn piano, and everyone recommended simple pieces for me to play. They all looked kind of boring, so I printed off the sheet music for Liszt’s Transcendental Etude No. 10 and started practicing.

I can’t say that my skill is anywhere close to that of a concert pianist, but I also can’t say I would have ever stuck with piano if I was forced to practice that other stuff first.

This is precisely how I learned how to play the piano. I started w/ a Beatles anthology book, but for Christmas got Gershwin's Rhapsody in Blue. Played it 3 times a day until I actually got it down. That rapidly accelerated my learning curve.

As someone who is kind-of sort-of learning piano, in more-or-less this way, thank you for giving me hope! I wasn't sure, based on anecdotal evidence, if just sitting and learning 'too-hard' pieces (and all the scales and arpeggios) would actually get me anywhere.

I had a friend who went to Michigan State. This was back when computers were a new thing. As a freshman, he signed up for a graduate level comp sci class. Had a hard time convincing the prof he should be let in the class. As time went on, it was clear he was the star student. The next semester he was a TA for the class.

I've been struggling with this concept in the context of teaching someone web development. There's just so much you "have" to know and it all seems so interrelated. Do you start with HTTP since that drives the web? If you do, do you first need to cover computer networking, IP addresses, routing? HTML and CSS aren't terrible to get started with, but are ultimately limited and [generally] aren't enough to build "some cool app". Then you have the beastly JavaScript, which you'll probably use on your front-end but only might use on your backend - there are so many other options. Python and Django? Ruby and Rails? Any of the dozens of PHP frameworks? Oh, right, now we might need to get into SQL. And builds and deployments and sysadmin-y tasks. Don't forget security. Or we could build everything serverless or on some PaaS, but how much understanding do you really have of what's going on there.

Having gone through undergrad and grad school for CS, I think part of it comes not truly realizing or accepting just how much knowledge you get from taking ~45 college courses . It's taken years for me to learn a reasonable breadth and depth of this subset of computer science, (and there's way more I don't know than I do know) and I struggle with the fact that I seem unable to boil all of that into the "a-b-a-b" pattern the author describes. Start doing the thing you want to be doing (e.g, making a web app), and learn just enough of the bits you need to keep on that path. But it's much easier said that done when you're starting from scratch.

It's like the pervasive interview question of "What happens when you type google.com in your browser and hit enter?"[0] Well, a lot... where do you start?

[0] https://github.com/alex/what-happens-when

I taught web development to multiple people, some of them now working as web developer. I still teach it almost exactly like I have been taught about 15 years ago my self. In my opinion it works great:

1. using a simple text editor learn writing some basic (semantic) HTML and view in in the browser. At this point you do not think to much about all the fancy websites out there but just see it as an geeky alternative to a word processor (headlins, paragraphs, lists, images[and their path resolution]... no input fields yet) and get familiar with the notion that the computer can understand the plain text you write and display it as a formatted document.

2. introduce css as a way of adding visual effects to your elements. Start with font-size, color, backgrounds. Start with simple element selectors, then add class selectors. Contrast selectors vs inline styles. The learning person will have a lot of own creative ideas and will ask "how to do this and that?". Gradually only introduce additional selectors and properties if needed. Once you get into css3 territory tell a bit about the history of web browsers and how difference browsers support different properties.

3. introduce vanilla javascript. After the basic control flow concepts (variable, functions, if/else) are clear start with simple event handlers for button clicks. One step at a time disclose useful DOM apis (el.style, el.classList, el.querySelector)

Notice how up to this point no knowledge of network protocols is needed. Except the interactivity provided javascript everything could as well be done in photoshop/word/illustrator. So learning all this is no different then learning using any other application, just a bit more geeky. The adventage of doing it that way is that you can introduce each new topic with the actually motivation for which the technology had been invented.

4. Once there is a solid understanding of html/css/js I would introduce the concept of a web server (constrasting it with the local file system) by just taking it as given that you can upload files via ftp/ssh into a folder on another computer that is linked to a domain (for now it does not matter how dns,ftp/ssh,apache/nginx... work.

---

I spend much time listening to lectures (on youtube and even live in university) about topics I already know about. I enjoy how different people explain things in a different way. And I have much fun explaining things I am interested in to try how fast other people grasp the concepts. On importent impression I got is, that's sooo much easier to understand - as well as to explain - concepts in the order and context in which they were historically developed. This got especially clear to me after taking various courses on set theory, logic, computability and turing machines provided by the philosophy department after I already finished a bachelor in computer science. The philosophers focused on "How did turing come with his ideas in the context of his time" while in the CS courses that question is almost skipped.

Just go learn whatever it is you immediately need to progress on whatever project you've picked. In time you'll have enough puzzle pieces filled in that you can stand back and get a sense of what the domain looks like. Then you can start targeting what you want to know more about and in time you'll feel like an expert.

This is probably the biggest thing that lead me towards self learning, I always felt like I was stuck with gatekeepers in the way.

Is it not unreasonable to believe that some things worth knowing or doing (A) are worth the prerequisite work (B)? If your class on data mining requires fundamentals in advanced databases why is it unreasonable to require people have taken that course to ensure the whole class is on the same page? Besides in most colleges you can sometimes skip those prerequisite courses if you can demonstrate adequate knowledge in those prerequisite.

Did you not read TFA?

The issue is that a) it can be greatly discouraging or impossible to fit in the subject's schedule, b) a waste of time and effort if the requirement isn't that hard, c) there may be a better way: the a, b, a, b pattern, which is to say: do A until you need to do some of B, then go back to A until you need more of B, and so on.

The a,b,a,b pattern is the right answer in at least some cases.

I think it's important to realize that you're optimizing for different things. "a, b, a, b" optimizes for, let's say, "attention span", while "B, A" optimizes for some sort of efficiency. Not everyone's attention span or need for efficiency are the same.

> while "B, A" optimizes for some sort of efficiency

What sort of efficiency do you think this optimizes for?

A perception of less time spent overall, perhaps. Or less loss/dropout from not being able to achieve A (for lack of B). I personally prefer "a, b, a", so I have to imagine.

On the other hand, if B-before-A is discouraging, then it may be very inefficient. It could act as a filter, but not so much for skill or any particularly useful personal attribute so much as "enjoys B-before-A well enough", which isn't particularly indicative of anything.

In general I do think that B-before-A is a very useful approach, but it cannot be the only approach. For one, it doesn't scale, not as the chain of Bs grows longer over time. We teach a lot more math to students today than 100 years ago, but almost certainly we're taking shortcuts that essentially amount to a,b,a,b -- how else can we manage the otherwise ever-growing cognitive burden of the sum of our knowledge?

If abab lets you start being productive sooner, then abab is more productive. It may or may not be more efficient than B-before-A -- I doubt we can conclude one way or the other in the general case, so I don't see the point in discussing the two approaches' efficiency.

The choice of A and B here seems designed merely to frame the conversation as unnecessary prerequisites versus if you say "you must do A before B" it just sounds more agreeable to begin with. In practice though, whether a prerequisite makes sense or not is highly contextual and is not done justice by a reductionist abstraction.

One of the many things I enjoyed about MIT was that I could register for almost any class as long as I could convince the professor I wouldn't be a drag on the progress (this was in the 80s). Let me take all sorts of interesting classes on subjects not part of my degree program (Optics! Machining! Nuclear strategy!).

Sometimes I ended up spending as much time running to keep up (lots of b,bmb) as I did following the class itself (A). But the system tolerated it.

My son wanted to play electric guitar. Being all responsible about it, I suggested starting with acoustic first. Now he's not playing any guitar.

Reply on news.ycombinator.com