Learn To Build | Hacker News Reader

Learn To Build

benton.io

75 pointsstanleydrew13 comments

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.)

> 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.

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).

> 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.)

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.

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.

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.

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.

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)

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

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.

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.

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), 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.

Reply on news.ycombinator.com