
Learn To Build - stanleydrew
http://benton.io/tech/2014/03/28/learn-to-build.html
======
raamdev
I always suggest starting with Why:

Me: "Why do you want to learn to code?"

Them: "Because I want to build X, or I want to modify Y, or I'd like to learn
how to do Z but it seems like I need to know how to code first." (This is the
ideal answer but in reality it's usually not the one I get. "Uh, I donno...
because it looks cool or fun or I can get a really good job," is the more
common answer.)

If someone doesn't know _why_ they want to learn something, they will be more
likely to give up as soon as the learning gets tough.

By the time I was 12 I had spent 4 or 5 years playing with computers, taking
them apart, building them, and spending _lots_ of time playing games.

One day I asked my dad, "how do they _make_ those games on the computer that
I've been playing for the past few years?" I wanted to know _how_ so that I
could tinker and build my own games too. My dad was a technical writer at the
time and the only programming language he knew of was a language called BASIC
(this was the early 1990s) and suggested that I pick up a book the next time
we were at the book store. (That led me from QBASIC -> Visual Basic -> PHP, of
which I'm currently most proficient. I wish he had told me "C" or "C++"; my
life would've taken a much different route.)

When I started digging into Python a few years ago, it was because I wanted to
build a script that connected two APIs and manipulated some XML. I knew
through the grapevine that Python was a good language for that, so I dug in.
It got tough, but I had a _goal_ in mind. There was something tangible that I
was working towards, a light at the end of the tunnel that I could keep aiming
for no matter how long it took me.

I cannot understate the importance of knowing _why_ you're doing something,
especially when you're learning a new skill. (I think this applies more to
adults than to children.)

~~~
doktrin
> _That led me from QBASIC - > Visual Basic -> PHP, of which I'm currently
> most proficient. I wish he had told me "C" or "C++"; my life would've taken
> a much different route._

I started with QBASIC as well. I was 12 years old in Japan in the late 90's,
and I distinctly remember searching through stores for a C++ book in English.
Never found one, and haven't used the language to this day - although I have
worked with C.

I occasionally fantasize about what it would have been like to tackle such a
comparatively complex language earlier in my journey. However, who knows how
things would have turned out. C++ is by all appearances quite an intimidating
beast even for diligent adults. Not inconceivable that it could have
discouraged a kid who was approaching it solo.

QBASIC is _fun_. As a result, my earliest memories of programming are
incredibly positive. That alone is worth quite a bit, and has had a
significant impact on my life.

~~~
raamdev
I never considered that perspective, that the difficulty (and dare I say,
ugliness) of the language might've discouraged me early on. A prior job in
Cambridge, MA paid for me to take any course I wanted at Harvard Extension
School (a branch of the esteemed Harvard school) and I picked an intro C
programming class. I learned a lot, but mostly I learned how challenging it
was and how annoying programming in C could get (i.e., how easily I could
become discouraged).

I've always assumed that my difficulty becoming proficient with C/C++ was due
to the fact that my brain started learning on BASIC, which wasn't nearly as
"close to the machine" as C is. What I loved about that C programming class
was how much I was learning about how the physical hardware worked (e.g.,
pointers; most people in the class seemed to hate pointers but I loved them).

------
Smudge
> Open source projects might seem like a good place to look since the code is
> readily available, but be wary as they are also known to be heavily
> gatekeeped and often getting started is more difficult than it should be.

This is certainly true for some projects, and as a beginner I'd steer clear
from them. To pile onto the generalizations with another one, I've found that
a project is FAR more likely to accept contributions (or even discuss ideas
with outsiders) if it has some kind of mechanism for accepting pull requests
(be it on GitHub or elsewhere).

What's that you say? Send a patch? To your mailing list? And then we'll talk?
No thanks, I'll lend my support elsewhere... (Not always true, of course, but
it should sound familiar to some of us.)

------
enraged_camel
This resonates very strongly with me. In the past, I've tried to get motivated
to "learn programming" multiple times, mostly because you just hear everyone
say it. But without any sort of meaningful end goal, each attempt sort of fell
through. I would hit a roadblock and fail to get motivated to crush it.

But just six months ago I actually had a need to build a website to make
company training materials available to our remote offices, and with that end-
goal in mind I was able to learn things bottom-up. The ability to place my
learning in a greater context certainly motivated me a hell of a lot more than
"OK, next up is loops in JavaScript... _yawn_ " Not to mention the ability to
use what I built to advance my career.

------
slavik81
I think it's often easier to start with scripts, automating manual tasks.
Jumping into a big, complicated program is difficult. Even just compiling from
source might not be easy. Existing code and its requirements are extra things
you need to grapple with on top of just getting your own code correct.

There are many computer-related tasks done manually simply because nobody who
understands the task also understands how to code. If you know some manual
tasks, building scripts to do them automatically is probably much simpler.

It's not glamorous writing VB macros or PowerShell scripts, but there's lots
of low-hanging fruit that can be plucked by beginners with simple tools.

That said, with the exception of choice of first project, I think I agree
entirely. The important thing is seeing the world around you as something that
you can take action to improve. Coding software is one simple (but powerful)
tool to do so.

------
rakoo
I'm really passionate about coding so I love doing it again and again, but I
don't think this argument is helping a lot:

> You do it all again. You learn to iterate. You learn that nothing is ever
> finished, and everything can be improved.

Building software is like any realisation in any domain: you don't keep doing
it because you have to, you keep doing it because you enjoy it, and you enjoy
the results you've made.

By saying what I quoted, you kinda mean that "No matter how hard you try, it
won't be enough". That's a very harsh thing to say to people who aren't even
passionated by the field but just want to get a grip on it.

Other than that, I think this post is very interesting, even for coders: we
should remember that coding is a tool to build stuff, not a goal in itself.

~~~
stanleydrew
It doesn't have to be negative, but I can see how easy it is to read "You do
it all again" and think it's discouraging.

The intention is not to say "No matter how hard you try, it won't be enough."
It's to say "Once you build one thing, there's still a whole bunch of other
things to build and improve!"

That's an incredibly motivating concept to me, that software is forever
changing around us and we can just keep choosing to latch ourselves onto
various bits and pieces and run with those changes. But perhaps others like
the comfort of checking skills off a list and calling them done and then
moving on to a different discipline.

------
ThomPete
I keep recommending this method but I honestly think this is the best way to
approach coding for the newbie.

1) Figure out what you want to learn first.

2) Get some reference books, cheat cheats etc. join StackExchange and a couple
of channels on IRC.

3) Spend some money on a subscription for Lynda.com and take on e of the
courses there.

4) Instead of diving into the coding watch the course without doing any code.
Just suck in the terminology, see what the results are, get an undertanding
about how things in the beginning will be used later on.

5) Now watch the course again but this time start doing what they ask you to.

6) Create your own version of what they just showed you how to build (ex. a
CMS system)

------
lilasmill
Also here are a couple more good classic resources to learn from:
[http://tryruby.org/levels/1/challenges/0](http://tryruby.org/levels/1/challenges/0)
and [https://www.codementor.io/](https://www.codementor.io/)

~~~
k__
Any tips how to teach people OOP?

I tried it with the codecademy stuff and everything worked fine, but when I
tried a simple project the students didn't understand the difference between a
method and a function (where does "this" come from? etc.)

Most people are rather fast in doing procedural stuff. Using APIs to load and
save stuff. Reading inputs, writing outputs etc. Most of the functional things
they get right pretty quick. But the more abstract things, like objects,
encapsulation don't come to them easy.

------
goshx
I'm also a self-taught engineer and, when I was starting, the best way I found
to learn how to code was to first figure out what I wanted to build. For
instance, at the time I new HTML, but not much about server side programming
or databases. I decided I wanted to build a dynamic website with user
registration, login and posts on a wall. Then, I split that "project" up in
small pieces and tried to figure out how to do each one of them. When I knew
what I wanted and the pieces I had to build it was easier to search for
resources to read. I believe this way it becomes easier to associate what you
learn from the programming language with what they are used for.

------
gailees
I've been saying this for a few months now. Although I love what the
learn2code movement is trying to do, what people really want is to learn how
to build things.

To facilitate this, we started Major League Hacking
([http://mlh.io](http://mlh.io)), the NCAA of Hackathons. Since it's inception
last year, we've had over 10,000 students take part in MLH Hackathons.

A large number of those students had never built something before. Many didn't
even code when they arrived. Once you show someone what they can build, it
becomes infinitely easier to convince them to learn2code.

