A few bits that caught my attention and perfectly show why Zed's publications are so good:
> 1. Use just a simple editor like gedit, notepad+, or Textwrangler. NO vim! NO emacs!
> 2. Do not have them use git or other RCS tools. They're here to learn code, not git.
> 3. Make it work for Windows, OSX, and Linux if you can.
> 4. The install of your language should not involve tons of steps.
> 1. Your book should educate people, not indoctrinate them. If you find yourself talking constantly about how awesome your language is and how it will change their life, then you're not educating, you're just making another cult follower. Leave the decision of whether the language is good to the reader.
> 4. Lightly make fun of programmers and inoculate your student against religious wars over syntax, idioms, editors, tools, and anything else that gets in the way of them learning. Remember, you are writing this book for them, not your fellow coder friends.
This should be the mantra for everyone who writes a tutorial (which often land here on HN) or any other form of introduction into technologies. Way too often authors waste a huge chunk of their educational material on shoving their tools of choice down readers' throats. 'hey, you want to learn rails? ok, now buy a mac, install git, learn emacs, download my dotfiles...'.
I'm currently writing a book and the pointers are great. Had been having trouble getting good momentum going due to the nature of the topic, but the bit about creating the structure of the book and then filling it in is just golden. I do the same thing with programs, but had not thought that it just applies to writing too.
If you're stuck then I'm finding there two common causes:
1. It's a structure problem, so you have to go back to organizing the concepts and how each chapter flows. Try changing the first lesson as a way to start rethinking this.
2. It's an audience problem, so you have to go figure out who the book is really for and then constantly try to write it for them. Try even changing who it's for and then see if that makes the book work for them.
You are right. After reading this post and following some useful links to your site, I was able to sit down and redo the book structure. It solved my problem and was able to quickly write a nice draft of the first chapter. Very useful wisdom to share, thank you.
2. Do not have them use git or other RCS tools. They're here to learn code, not git.
This is good advice for Zed's LxTHW brand, because those books are geared toward learning one particular language at a time. But in some contexts having an integrated approach can be an advantage. Readers of the Ruby on Rails Tutorial often tell me that they didn't really "get" web development until they saw how Git, GitHub, Heroku, and Rails all fit together. That's because the goal of the book isn't to teach Rails; it's to teach web development with Rails. Unfortunately, this means that some readers are overwhelmed by all the detail (and I may someday make a product to better meet their needs), but for many readers seeing the whole picture is a revelation.
the case is, git, github or heroku are not needed at all for web development. if I was to teach somebody how web dev as a whole works, I would introduce them the concept of source control and web hosting for sure, but not tie them into some specific solutions of my choice. learning technologies (languages, databases, frameworks) is timeless, learning how to use a commercial website popular at the time isn't.
frankly speaking, whenever I drop into a tutorial and it begins with an introduction to github or vim, I leave the page. it's because it shows the author isn't focused on solving my problem which is I am not familiar with some specific technology, he prefers to advertise his favorite tools for some reason and lock me in his way of doing things. just show me what I'm looking for, I will figure out the rest myself if I need it.
git, github or heroku are not needed at all for web development.
You're missing the forest for the trees. While it's true that those particular technologies aren't necessary, professional-grade development does require version control, shareable repositories, and deployment. Git, GitHub, and Heroku are just the solutions I happen to use in the book.
All education is a form of indoctrination. When you teach a kid to read you are indoctrinating them, but you do so with the assumption that if you don't teach them to read they will be worse off. So you indoctrinate them. As we all go through life people are interacting making similar judgement calls based on time, place and circumstance. So indoctrination in that regard is omnipresent and has a good side. Sorry to be off topic but I felt like typing that. I agree that we should fight our shallow inclinations to sensationalize in ways that diffuse "robust" learning.
No, and I'll give you my distinction that separates education from indoctrination:
Education's goal is to teach you something so that you can then go on without them, thus why they teach a wider range of topics within a subject.
Indoctrination's goal is to make you dependent on the educator, thus why they focus on only their version of the subject and squash differing opinions using propaganda tactics.
For example, you don't have to go back to your highschool math teacher to use Algebra or back to your grade school to read something. You are independent and may never set foot in your school ever again, but can still do these things.
If you teach someone that Python is the one true language and use propaganda to make them want to use it, then they'll be dependent on that language and the community in order to write code. Even simpler is if you only teach them git and github then you've indoctrinated them into always needing github to share code.
Bad kinds of education are like History classes that teach fairy tales like "George Washington never told a lie." These are indoctrination masquerading as education because they make the student dependent on the country for their identity.
The reason indoctrination like this is bad in programming though is because programming languages and tools die all the time, and when they do it destroys these people the indoctrinators have made dependent on the technologies. It also smacks of a con that's covering for shit technology that can't survive on its own merits.
Finally, finding a particular topic in the gray area between them does not disprove that there's a difference. Rational people don't think in binary, so this is a continuum where you could find some topics that require a bit of indoctrination, and some where it's the complete wrong approach. In my opinion, programming education only has indoctrination because that lets shitty technology hide behind propaganda.
I agree that everyone should strive for the intent and ideals you're talking about (IE not making people dependent etc) But
I still hold to my view in terms of the definitions.I think indoctrination is like social order, to a certain degree it is inescapable and inherently part and parcel to learning anything involving reading and writing. But I complete agree with the ideals you believe we should all strive for and the methodology etc. I do think there is a staunch distinction between the indoctrination of people learning through the state or a church or whatever, and the more interpersonal empathetic methodology of teaching with an intent to facilitate independence. The irony is most staunch ideologues would probably agree, then go off and completely contradict it with their actions :). Around and around we go...
Wikipedia says it in the first paragraph: "(Indoctrination) is often distinguished from education by the fact that the indoctrinated person is expected not to question or critically examine the doctrine they have learned."
Zed is specifically referring to this usage. You should never assume you are doing the Right Thing in programming, because you probably aren't, at best you're doing the "least wrong" thing for your situation.
I still hold that education (insofar as it includes reading and writing) no matter how you cut it is a form of indoctrination. I understand the common sentiment behind the ideal difference and Zed's words, but I also think that no matter what you learn you are expected to a certain degree not to be critical since by default (when learning something new) you usually don't have the slightest idea what to even be critical about at that point. I just think the notion that there is a demarcation between the two is not true.So using your own programming analogy, I think the goal of education should be to strive for "less bad" of an indoctrination.
If you've never taught beginners how to program, then you should obsessively follow Zed's advice...I just cringe whenever I see even a mention of "git" or any other development tool in the context of beginners coding.
I can only say that it is nearly impossible to underestimate the technical unfamiliarity of this audience. Opening the command line terminal is bewildering to them. Not understanding why 'ls' worked a minute ago but not now (it's because they're in the interactive interpreter) causes rage.
You may think you're enticing the beginner by teasing all the cool things they'll eventually get into, but it ends up being a disservice. They're already entering a world of confusion and frustration, no need to add orthogonal concepts to the mix.
I agree in principle. However, sometimes it is useful to bundle things together if that's how things work in the real world, like Ruby on Rails + Github + Heroku in a RoR book. Then again, it would be counter-productive to add in totally irrelevant things like vim or emacs.
If I'm teaching someone rails deployment and making their first rails app, then maybe but that's a whole lot of indoctrination there. You have to pick, but to me you're basically just making customers not programmers.
If I'm teaching someone who doesn't know how a computer loops in a while loop or what a variable is, then you're advice is counter productive. None of that is useful for them and just gets in the way of what they need. At best you're just impressing them with a flashy demo that they may not even really understand.
I vividly remember my first foray into real programming a year and half ago. Trust me, just getting Python to install and compile was lesson enough. It was months before I learned how to use the Windows command line. To a total beginner, especially one who is only familiar with Windows, path variables and stuff like that is absolutely frightening. It also doesn't help that the documentation for many programs is Linux-only.
If you can't get someone started with the following steps:
1- Go to website
2- Download and press next until the prompt says "Installation Finished."
3- Click here to create a file and save the file on your desktop.
4- Press "Run."
5- See "Hello, World."
You already made it too damn difficult for week one.
All that other stuff is secondary. Getting the words "Hello, World!" (much less getting the screen to show 1 through 10 without dropping into an infinite loop) to show up w/o supervising the student is a huge victory. I can't tell you how long it took me to understand while and for loops, but it wasn't one or two days.
Getting someone set up and running with a semi-significant website is an unrealistic goal to accomplish within a few months... well, if you want that site to be reasonably coded, that is.
People with lots of experience forget that the basics, for a total beginner and near technophobe (as I was 18 months ago), is very difficult. The real "oh, crap" moment came for me when I was first exposed to Emacs. I complained that, in today's day and age, it was utterly fucked-up that some stupid class would suggest you don't use a mouse. I was told that that statement was probably the biggest indicator of my newbie status than all the horrid code I could demonstrate up to that point. Just remember that people aren't ready to learn a bunch of new tools and they aren't ready to give up familiar tools at the start.
I disagree. Adding github + heroku to a Rails book is a mistake. Too much time is spent setting up things you don't really need to learn how to code with Rails. Its a big drag.
Imagine if at school you were taught how to write cursive while also being taught how to hold the pencil. Shit gets complicated too fast.
It depends on your goals and your audience. The Ruby on Rails Tutorial teaches web development to those who already have some programming experience, and in this context including Git and Heroku is, for many readers, a big win. True, the #1 complaint about the tutorial is that it includes so much more than just Rails, but that's also the #1 compliment.
I like your book. Have read about a 100 times. Its good. But its not perfectly marketed. The title does not fit the book. You are not teaching Ruby on Rails per se, but web development and deployment with Ruby on Rails. There is a difference between the two. Imagine a beginner, who has no experience with actual web development, but wants to try out RoR to find out what the big fuss is. He/she finds your book, and starts reading it. Only to find out that he/she has to learn about n different things before learning how to include a field in a model. Its frustrating. I know because I went through it. Even though I knew git/heroku deployment beforehand, skipping over those subjects proved difficult.
Though you do make a good point in your first sentence. It does depend on the goals and the audience. But I think your audience is a bit too widespread. People who have some programming experience are too wide of a net. I think if it were sold as a book for people who havea bit of web development experience then your conversion rate would be higher (from free reader to paying customer).
Now, I'm not knocking on your accomplishments. My approach is merely from the business perspective of marketing you book and videos. Have you tested other approaches? If so, may you shed some light? I used to market/sell books on the web, and find it fascinating. If you wish to continue this conversation through email mine is in my profile.
Yes, because clearly the only way to see a list of files is by typing something in a command prompt, and beginners should install lots of apps to handle different edge cases so they can't program on their own.
Sorry for submitting to HN with it not quite ready! Just stumbled across it today and thought it was really fascinating. I'm working on a "learn to code" product myself. Just watched your talk at Oredev in Sweden yesterday. Thank you so much for sharing what you're learning!
No, this is now the latest template. That's what I'm using in all my books now, and it's coming from a more advanced project for writing music books http://orkestrix.org/
My goal was, if I could write about code and music at the same time, then making a build system for books would be easy. The above is the end result of that work. Enjoy.
I understand you don't want to use LilyPond because it is too complex, but you may want to know that LilyPond comes with a tool to convert from ABC to LilyPond (abc2ly). One could use it to write the music examples in ABC and have LilyPond typeset them. I'd consider using a setup like this to typeset the "final" version since LilyPond's typography is so nice.
For a book like the Python book, what features of LaTeX were used? I usually associate it with its ability to do fancy typesetting. But the Python book looks like it could be done in mostly Markdown.
lots of formatting features, easy to version control, able to convert to print book and pdf easily, fully text based thus more predictable, and so on. LaTeX can be used for any document from CV to an entire book.
Most of this is true, but I found that it completely falls flat on its face once you want to do any reasonable HTML output. htlatex is an abomination that should be destroyed in the fiery pits of hell after some long quest with a ring and some hobbits.
Presumably because LaTeX is designed for typesetting for fixed page sizes while HTML is designed for creating content that reflows to different window sizes and devices?
Not really - it is more that the various wrappers from tex to html are written in the spirit of the ancient web, rather than a transform to (another) simple, structured markup language. Somewhat odd considering docbook sgml should be a good match for modern html+CSS. I've considered writing something better, but have come to the conclusion that treating tex as output is just more reasonable (ie write in something like rst/markdown etc).
I just recently started attempting to teach myself how to teach with my friend and his girlfriend as Guinea pigs using Zed's books as a guide.
Another thing I would add - go slow, but let the student explore and achieve on their own. Small accomplishments without frustration are much more motivating and "sticky" in the mind.
I am expecting Learn Scala the hard way. Scala for the impatient (first free eight chapters) was a very good book, Scala Coursera was interesting. Some of Zed advices are very practical.
As a recent vim uptaker, vim is an entirely separate subject matter on it's own and should not be used as a distraction to learning a programming language.
It's an additional hurdle (with quite a bit of a learning curve) that would get in the way of learning to code. That said I wouldn't be too surprised to see a learn $EDITOR the hard way book out at some point.
Yes! Learning vim or Emacs would have been a lot easier if I hadn't started learning Unix with a bunch of bearded gurus back in the day. Although I did impress a few with my now-forgetten VMS/DCL chops...
> 1. Use just a simple editor like gedit, notepad+, or Textwrangler. NO vim! NO emacs!
> 2. Do not have them use git or other RCS tools. They're here to learn code, not git.
> 3. Make it work for Windows, OSX, and Linux if you can.
> 4. The install of your language should not involve tons of steps.
> 1. Your book should educate people, not indoctrinate them. If you find yourself talking constantly about how awesome your language is and how it will change their life, then you're not educating, you're just making another cult follower. Leave the decision of whether the language is good to the reader.
> 4. Lightly make fun of programmers and inoculate your student against religious wars over syntax, idioms, editors, tools, and anything else that gets in the way of them learning. Remember, you are writing this book for them, not your fellow coder friends.
This should be the mantra for everyone who writes a tutorial (which often land here on HN) or any other form of introduction into technologies. Way too often authors waste a huge chunk of their educational material on shoving their tools of choice down readers' throats. 'hey, you want to learn rails? ok, now buy a mac, install git, learn emacs, download my dotfiles...'.
TLDR: want to educate? be agnostic.