Slashdot Mirror

All far too dense for an 11 year old, and all pretty much require more background knowledge than an 11 year old is likely to have. I'm not sure there really is an answer to the OP's question though, at that age, even a very bright kid is almost certainly going to lack the prerequisite knowledge to learn to program from just a book.

Say what?! I was programming at age 11, self-taught, using 'just books.' (Unless you count some early -- and very rudimentary -- Logo exposure in grade school; later scholastic use of the computer was, IIRC, limited to Oregon Trail, though once you got to high school you could take a class that taught Pascal...)

I got started hand-keying source code from magazines and books available at local booksellers. As I progressed, I picked up a copy (likely got it as a present) of the AppleSoft Basic Programmer's Reference Manual.

These days, I have to imagine it would be both easier (every API you need to get started is quickly available online, often with excellent accompanying tutorials and/or with user-contributed sample code snippets), and perhaps more intimidating (as the complexity of our systems has increased precipitously). (On the flip side, much, much easier to get a GUI working under Java than back in the day when you had to hand-code memory bank switching and deal with the bizarre "but it saved a chip!" oddities of Apple II graphics programming...)

Mind you, I wasn't a very good programmer, and honestly wouldn't be until I was finally exposed to proper procedural programming (C), then OOP (C++, and when it was released, Java), in college. But I had fun with it, and my stuff worked. Wasn't terribly robust or full-featured, but, it worked. (My database was a flat-file, not relational, and, um, written in BASIC... ;))

Okay, all that said, it might be worth checking out the Head First books. Head First Programming uses Python and is supposed to be a general introduction to programming. There's also Head First Java. No direct experience with either, but people rave about 'em.

All far too dense for an 11 year old, and all pretty much require more background knowledge than an 11 year old is likely to have. I'm not sure there really is an answer to the OP's question though, at that age, even a very bright kid is almost certainly going to lack the prerequisite knowledge to learn to program from just a book.

Say what?! I was programming at age 11, self-taught, using 'just books.' (Unless you count some early -- and very rudimentary -- Logo exposure in grade school; later scholastic use of the computer was, IIRC, limited to Oregon Trail, though once you got to high school you could take a class that taught Pascal...)

I got started hand-keying source code from magazines and books available at local booksellers. As I progressed, I picked up a copy (likely got it as a present) of the AppleSoft Basic Programmer's Reference Manual.

These days, I have to imagine it would be both easier (every API you need to get started is quickly available online, often with excellent accompanying tutorials and/or with user-contributed sample code snippets), and perhaps more intimidating (as the complexity of our systems has increased precipitously). (On the flip side, much, much easier to get a GUI working under Java than back in the day when you had to hand-code memory bank switching and deal with the bizarre "but it saved a chip!" oddities of Apple II graphics programming...)

Mind you, I wasn't a very good programmer, and honestly wouldn't be until I was finally exposed to proper procedural programming (C), then OOP (C++, and when it was released, Java), in college. But I had fun with it, and my stuff worked. Wasn't terribly robust or full-featured, but, it worked. (My database was a flat-file, not relational, and, um, written in BASIC... ;))

Okay, all that said, it might be worth checking out the Head First books. Head First Programming uses Python and is supposed to be a general introduction to programming. There's also Head First Java. No direct experience with either, but people rave about 'em.

So do you have any suggestions about what books or sources to look at for information about PMI methodology?

The canonical bok is the PMBOK - A Guide to the Project Management Body of Knowledge. That said, this is more of a reference/guide than an introductory book. I strongly recommend at least getting a companion book - like Head First PMP. In addition, you should look at getting some training - you can't get a certification for a couple of years, but the training is very useful.

I'm about to finish my fourth book for O'Reilly, Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders (which should be out in stores by March).

As far as tools go, my coauthor, Jenny, and I wrote our first book using Microsoft Word, but could just as easily have been using OpenOffice, Pages or any other word processor. One thing that was enormously useful was EndNote for managing the bibliography. Our next two books were in O'Reilly's Head First series (PMP and C#), and we wrote them entirely in Adobe InDesign. (People think that there's a whole team of people designing and laying out Head First books -- it was just us, our editor, and an awesome but overworked graphic designer, Lou, who helped improve our layouts once we had them in reasonable shape.) InDesign isn't exactly the easiest tool for a book author, but it was sufficient. But it made me really appreciate word processors!

A few things that really became clear to me over the course of working on these books:

a) Pay attention to what you're delivering to your editor, and what they'll do with it. Publishers have their own set of templates and production stuff to get camera-ready copy together. Head First was a very interesting lesson in that, because Jenny and I actually produced a lot of camera-ready copy ourselves. But for most books, whatever you turn over to your publisher will get transmogrified into their own internal format.

b) The production editor people I've worked with and talked to (not just at O'Reilly, but at other publishers, too) have been extremely competent, and it's their job to take whatever it is you give them and make it work. It needs to be copyedited, typeset, and reviewed, and sent to a printer. I highly recommend getting to know them, and being as flexible and agreeable as possible (they generally won't ask you to compromise your vision for the book -- it's generally about technical stuff, like how to deal with footnotes, references, images, etc.)

c) You asked about version control. One of the best authors I've ever worked with, Karl Fogel -- he's a contributor to Beautiful Teams, and also just a great guy -- wrote a fantastic book called Producing Open Source Software, which you can buy from O'Reilly or download for free from the website. (Anyone who's interested in starting or contributing to an open source project absolutely needs to read that book. Disclosure: I was a technical reviewer for it.) In true open source fashion, Karl made his version control repository for the book available, and that's a good model to copy. Jenny and I didn't do anything quite so formalized; we just shared folders, and that was sufficient for us (even with hundreds and hundreds of image files for each Head First book).

d) This is the most important thing: make sure you have a clear idea of what it is you want to write! It's easy to get started on a project, only to have it trail off because you don't really have a whole book's worth of material. The more you can outline, the more research you do, and the more you prepare, the better the book will be.

Now, that's all assuming that you have a publisher lined up and a contract signed. If you don't, I highly recommend reading through the excellent Writing for O'Reilly section on their website. They walk you through all of the steps of proposing a book and the mechanics of actually working with a publisher -- and from everyone I've talked to, it's very similar

I'm about to finish my fourth book for O'Reilly, Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders (which should be out in stores by March).

As far as tools go, my coauthor, Jenny, and I wrote our first book using Microsoft Word, but could just as easily have been using OpenOffice, Pages or any other word processor. One thing that was enormously useful was EndNote for managing the bibliography. Our next two books were in O'Reilly's Head First series (PMP and C#), and we wrote them entirely in Adobe InDesign. (People think that there's a whole team of people designing and laying out Head First books -- it was just us, our editor, and an awesome but overworked graphic designer, Lou, who helped improve our layouts once we had them in reasonable shape.) InDesign isn't exactly the easiest tool for a book author, but it was sufficient. But it made me really appreciate word processors!

A few things that really became clear to me over the course of working on these books:

a) Pay attention to what you're delivering to your editor, and what they'll do with it. Publishers have their own set of templates and production stuff to get camera-ready copy together. Head First was a very interesting lesson in that, because Jenny and I actually produced a lot of camera-ready copy ourselves. But for most books, whatever you turn over to your publisher will get transmogrified into their own internal format.

b) The production editor people I've worked with and talked to (not just at O'Reilly, but at other publishers, too) have been extremely competent, and it's their job to take whatever it is you give them and make it work. It needs to be copyedited, typeset, and reviewed, and sent to a printer. I highly recommend getting to know them, and being as flexible and agreeable as possible (they generally won't ask you to compromise your vision for the book -- it's generally about technical stuff, like how to deal with footnotes, references, images, etc.)

c) You asked about version control. One of the best authors I've ever worked with, Karl Fogel -- he's a contributor to Beautiful Teams, and also just a great guy -- wrote a fantastic book called Producing Open Source Software, which you can buy from O'Reilly or download for free from the website. (Anyone who's interested in starting or contributing to an open source project absolutely needs to read that book. Disclosure: I was a technical reviewer for it.) In true open source fashion, Karl made his version control repository for the book available, and that's a good model to copy. Jenny and I didn't do anything quite so formalized; we just shared folders, and that was sufficient for us (even with hundreds and hundreds of image files for each Head First book).

d) This is the most important thing: make sure you have a clear idea of what it is you want to write! It's easy to get started on a project, only to have it trail off because you don't really have a whole book's worth of material. The more you can outline, the more research you do, and the more you prepare, the better the book will be.

Now, that's all assuming that you have a publisher lined up and a contract signed. If you don't, I highly recommend reading through the excellent Writing for O'Reilly section on their website. They walk you through all of the steps of proposing a book and the mechanics of actually working with a publisher -- and from everyone I've talked to, it's very similar

We get this question on the Head First C# forum every now and then from people who read the book, finish it, and want to know what to do next to get a programming career. Here's the post I usually send people to. One thing I think new developers should think about is working on a team -- that's a skill that takes practice, and doesn't always come easy to developers. The better you are at it, the more successful you'll be in your career. (I've got a few tips in that post for getting that kind of experience. Contributing to an open source project is definitely a good start. Karl Fogel's excellent book, Producing Open Source Software, is a great way to learn about how to do that effectively.)

My 15-year-old loves Head First C#. It's a great book for learning to program, and it is easily accessible to a high school student.

I have a fourteen year old son, and I can not get him to put down Head First C#. It may be a little old for a younger kid. It is the only book that I have seen that guides you through so much hands-on programming and problem solving, which in my humble opinion is the only way to learn how to write code. He wants to learn video game programming, and I think the promise of writing real video games (here and here) is keeping him going. Which is surprising, because he is quite the ADHD kid most of the time.

I have a fourteen year old son, and I can not get him to put down Head First C#. It may be a little old for a younger kid. It is the only book that I have seen that guides you through so much hands-on programming and problem solving, which in my humble opinion is the only way to learn how to write code. He wants to learn video game programming, and I think the promise of writing real video games (here and here) is keeping him going. Which is surprising, because he is quite the ADHD kid most of the time.

I have a fourteen year old son, and I can not get him to put down Head First C#. It may be a little old for a younger kid. It is the only book that I have seen that guides you through so much hands-on programming and problem solving, which in my humble opinion is the only way to learn how to write code. He wants to learn video game programming, and I think the promise of writing real video games (here and here) is keeping him going. Which is surprising, because he is quite the ADHD kid most of the time.

I have a fourteen year old son, and I can not get him to put down Head First C#. It may be a little old for a younger kid. It is the only book that I have seen that guides you through so much hands-on programming and problem solving, which in my humble opinion is the only way to learn how to write code.

Or, if you actually bothered to look at the book's website, you might find this blurb:

"We all know 'Data is Power' - but we'll show you how to have 'Power over your Data'. Expect to have fun, expect to learn, and expect to be querying, normalizing, and joining your data like a pro by the time you're finished reading!"

So much for your uninformed grousing about normalization being omitted. As an introductory book on SQL, it doesn't sound too bad. You can't reasonably expect that type of book to make you an instant expert.

Was anyone else (I'm talking to you Slashdot) put off by the reviewers writing style (you know what I'm talking about)? I found it hard to read (especially considering the length of the post) when he kept deviating (yes, deviating!) from his review by interjecting his comments (and numerous they were) into the post.

On topic, I found that the Head First XTHML book to be a great introduction to CSS as well as XHTML.