Page Fault Programming / Parrot Programming

Question

In Podcast 53 of Stackoverflow, Joel and Wil Shipley mentioned a term called "page fault programming" or "parrot programming".

In Joel's words: "The page faulting is I try doing something, I see something, maybe in a piece of sample code, I go to Google and I say "What is..."

Basically, it's learning while you're doing, and doing the research when you need it, as opposed to learning from a book.

In my experience, this happens a lot and I think this is similar to going for an exam and "winging it". The code you produce isn't stellar. It's usually copy and pasted and lacks good software architecture. However, it gets the job done as long as you know programming fundamentals (this applies to the test analogy too: you can pass if you know the bare minimum).

My question is whether the SO community thinks this is a bad habit. Also, can it actually help you learn something compared to learning from a book? I'm thinking if it's something where a deep understanding is needed (ex: C++), then you're better off reading a book first. If it's just another MVC Framework and you're not producing production code, I would learn like a parrot.

Answer 1

I'd love to learn by... well, "Learning": digging into a book, writing little bits of sample code, and generally immersing myself in Something New.

But the harsh reality is that I'm not paid to do that; I'm paid to solve problems. Hence, you tend to learn by example; if you find something that solves your current issue, you use it.

Now, it could be argued that a Smart Employer should allow you time to Learn, on the basis that the resultant in-depth knowledge would pay off in the long term. But I'd wager there's few hard numbers to support that viewpoint.

Is it a bad habit? Maybe. But sometimes it's the only opportunity you've got.

Answer 2

I'm all about "Parrot Programming" - although I don't care for the term.

I find it difficult and quite boring to learn from a book without having a context for the solutions I find.

Having seen some "more mature" colleuges fall behind in technical knowledge I personally don't think there is any other way than learn as you code.

Given the vast number of languages and frameworks in the world, I challenge anyone to learn from a book, and then be the most effective programmer they can be without constantly learning new things, and of course keep it up for the duration of their life as a coder.

This is how things work today. What's the point in having all the worlds information indexed and search-able if your just gonna try and memorize all of the relevant stuff before you need it.

As for producing a good software architecture. You can't google the answer to your own unique project... At this point, you're going to need to be able to think for yourself and have some decent theory behind you. But this should be independent of the implementation anyway.

Answer 3

Even if you take the page fault approach to learning you need to know enough about your task to be able to make the right questions. So learning things up front is still very viable, but I think you need to know less details by heart now than you did 10 - 15 years ago.

Answer 4

its the only way to learn tbh.

Answer 5

I'm not sure what the question is. Obviously actually understanding something is always preferable to having a superficial reference to it, but nobody has time to learn everything in the world, so we compromise.

Answer 6

Of course you need to learn things up front. You have to have the knowledge to perform most of your tasks without having to go 'the parrot way'. However, you can't know everything, and there will always be situations in which you need to get something done which you don't know everything about, and you will have to use google and learn the bare minimum to get the job done. That is flexibility that a real professional must have.

I always take this as an opportunity to learn more, later, though. Make the deadline, and then use the advantage you now have (you are 'into it') to learn as much as you can much quicker than when you did not have any reason to. Try to find out whether you really did the correct/best thing. Learn.

Answer 7

It depends on the depth of the knowledge you need and the size of the task I think.

I'm using this style of programming right now to do some PL/SQL.
I've never done any before and I need to do some fairly simple stuff - iteration and concatenation - so am trying what I think might make sense (eg, MY_STRING.LENGTH) then searching online to find out the correct way (turns out it should be LENGTH(MY_STRING) - who knew?).

It's sufficient to do the stuff I need to do now but you can't learn a whole new language that way really.

Back when I first learned Java I read "Java in a Nutshell" before I touched a line of code - it really gave me a good grounding in the theory.

Same when I learned Ruby - read about half of the Pickaxe book (I have less patience now) before I hit the code.

Also - it's worth mentioning that someone who knows PL/SQL will be reviewing my code to make sure I don't do anything really silly.