I believe that it is a byproduct of increasing popularity of hacking bringing in a more diverse group of people and the lack of formal support structures / "good" trade schools for programming.

Before the internet was pervasive, a self-study of Programming was for the curious tinkerer. Now that it is incredibly mainstream, we are seeing more people who are approaching programming as a means to an end, for whom the solitary pursuit of arcane knowledge is not an end unto itself.

For people who are not auto-didacts, a little more structure is needed. From a (Vygotskian) pedagogical perspective, most learners require an Expert to create "scaffolding" (support structures) that allow the learner to increase their "zone of proximal development" -- that is, they require someone else who has mastery to provide a little help or guidance in order to help the to tackle tasks the learner does not yet fully master. the completion of tasks with help then increases the learner's level of mastery and they can then take on ever-more-challenging tasks.

Tl;Dr: most people prefer to not teach themselves hard things.

If programming is now attracting more mainstream interest as you said, I wonder if the pedagogy of disseminating programming knowledge will change. Will the educators (I can't think of a less formal word for this, but basically refers to anyone that wants to share knowledge, whether pros or amateurs) now approach teaching in a way that does not assume someone has been tinkering with Unix since they were 5, but instead cater to an audience of post-secondary and/or adult learners, including those of us that are career switchers? A section of O'Reilly's materials certainly serves this segment, but will the greater tech community cater to this new group of learners?

It already has, especially with the advent of things like railscasts (screen casts that teach new skills by example,) things like the javascript mentors mailing list and so forth.. i think you are on to something wrt writing for an audience and having that audience change as time goes on. I think the "popularizer" blogs that are basically n00b guides to web tech are increasing in popularity and directly increase the exposure of their curators...

for a direct example, compare the README.md in many GitHub projects to the pages on SourceForge.

We used to take for granted that you'd know how to get cvs, configure make and install for your system (and would understand architecture flags and so forth...) nowadays library authors (who in many ways are the "first educators" for their tech) are putting in more effort to make things as easy as "copy and paste this into your terminal to install."

That all said, it is kind of terrifying how many people are developing networked applications with only the most rudimentary understanding of networking...

It really helps to have someone show you the proper way to do things.

I've been hacking on rails for a while but only after I joined a company where they had guys with 4 years of professional rails experience did I come to know of all my bad habits and also learned how to do things in a neater faster way.

Basically being around people who are good at what they do will make you good at that skill.

The book "The Talent Code" explains this in detail. Read this book - it'll significantly help you understand what you need to do get good at a skill fast.

Venkatesh Rao wrote a blog post on this as well which is a very worthy read. He called it "The Crucible Effect". http://www.ribbonfarm.com/2009/07/21/the-crucible-effect-and...

And this goes for any skill from windsurfing, soccer to coding to running a startup.

Tl; dr: Somethings will probably be learned quicker if coding with a team/more experienced developers. Architecture/security/design/layout stuff that just takes years of experience to get really good at, for example. I'm learning to code also but have been learning primarily on my own. Perhaps a combination thereof would be optimal.

Thanks for this comment. I started coding about 8 months ago and am enjoying it thoroughly (I just turned 30 and have a background in business). I was actually thinking about doing the same thing this guy's done - get a developer intern position somewhere since reading this post earlier this morning. I'm sure I would learn tons that I wouldn't otherwise learn (I'm thinking specifically architectural and security type stuff, among other stuff) but am also learning tons on my own.

Just last night I was talking with a good friend that has been coding for 15 years and he suggested something kind of similar: fix the bugs and maintain some code that a more experienced developer can check - run errands so to speak. That way I'm not breaking something or pushing insecure, buggy code into production. I think a combination of the two would be optimal.

I've done a lot of maintenance programming, and I think it's a horrible way to start and a difficult rut to get out of. Fixing someone else's bugs all day is demoralizing and creates all kinds of cognitive dissonance about whether or not you actually hate programming. Write your own code and learn from your own bugs. If you have to, get a non-programming day job and write code on the side. At least that's what I would do if I were starting over.

Why is it a difficult rut to get out of? Because when people build teams to build systems from scratch, they look for other people who have built things from scratch. Then when they need someone to maintain it, they look for someone who has maintained other piles of buggy crap.

Gogogo!!

Then share your experiences with HN!

I don't know why there's a general "mentorship" trend recently and I have a visceral dislike of that particular term but I do know that my efforts to learn programming became dramatically more effective when I had someone helping me. There are so many unknown unknowns for a new programmer, having someone to just help nudge you in the right direction occasionally is tremendously useful. If that person is also a good coder, then you're more likely to start out with good habits. Bad habits in general are difficult to unlearn and if you're learning by yourself, you're unaware that you're even forming habits.

Agreed. I hired an experienced programmer to help me part-time for a few weeks at the beginning of my current project. He boosted my confidence by showing me that I could actually write good code, corrected bad habits before they became ingrained, and sped up development significantly.

Knowledge is stored in 3 buckets. Mentorship can help move the set of stuff you "don't know that you don't know" to the set of stuff you "know that you don't know". This can make the process of filling up the "know that you know" bucket much more efficient.

I think its a good question actually.. Here is my opinion:

1) Environment. Having the right people and drive around you striving for the same goal has a positive impact on your own actions. Makes you more motivated to do stuff (at least for me)

2) Make less mistakes. I made a ton of mistakes the last couple of years and I am now VERY receptive to not learning things the hard way.

In the event that I did not, the plan was to get a regular 9-5 job and devote nights and weekends to improve my technical chops.

There are many ways to do this but having a mentor or a right environment to do it certainly helps an already difficult journey.

I taught myself "programming". By the time I attended university I had written a few small programs/toys.

When we were formally taught Java at university, there were 10 hours of tutored labs available. I certainly didn't need any help to do the coursework, yet I went. I soon found some real hackers, who happily ripped my coding attempts to pieces (in a good way, mind).

When I started work on my first attempt at architecture, I got some guidance from some of the same people. Whilst design patterns were around, these people helped me understand which ones to look at, why, and what overkill was.

When I graduated and started working, I was already a "better" programmer than some of my peers, as I had been shown GDB (and hence JDB) by my mentors. However two years in I worked on a project with some talented developers, and again I learned about IOC etc.

Mentors save you a lot of time and energy. They are present in almost all trades where you have apprenticeships, and I for one know I thrive in that sort of situation - the one where I am challenged by someone who has been there before, who forces me to back up my designs/arguments by reading directed texts.

If I hadn't had them, I'd have found my own path. But I'd have spent a lot of time wondering somewhat aimlessly, reading semi-useful books cover to cover (yawn), and screwing up projects...

From the BigCo perspective, mentoring is coming back. Mentoring/apprenticeship used to be the way all engineers started out, but it seemed to slowly fade away over time in a lot of organizations.

Now we're seeing more HR/management training people teaching that mentoring and coaching new hires (esp. those just out of school) is a better way to go. It gets them up and running faster and you can brainwash^H^H^H^H I mean teach them they way you want them to do things.

Personally, I think it's a good thing.

I've been teaching myself, somewhat similar to OP. I'm too isolated to know about trends, but the few conversations I've had with more experienced people are enormously helpful.

-- They help weed out the bad and the WTF to bring forward the good (in my case, okay) stuff.

-- Their discussion of design issues can help you figure out your framework, and show directions you hadn't known.

-- They give you some sense of what you've accomplished, what you haven't and what you must improve.

Yeah I think when you're just starting, the most mentorship you need is the teacher of a programming class you're taking. The reason being that to find a good mentor, one who can really teach you a lot about hacking, you will need to have some baseline skills, otherwise you're just wasting that person's time with beginner questions that can be answered in 5 seconds on Google, or 30 seconds on irc if you don't even know where to start.

You could also do this by contributing to an Open Source project rather than a for-profit organization.

Look up Google Summer of Code. You won't get into the program if you're not a student, but it's a great jumping-off point for finding communities that are willing to nurture newbies.

Some people need to be paid to learn something(a job), or pay someone to force them to learn something(trade $ for a grade/degree).

I agree. I rather learn by turning my own ideas into products and asking experienced friends to look at my code for feedback.