Ask HN: Non-technical people, how did you learn to code?

I want Codecademy to extend their language set and number of courses. This would help me greatly.

I taught myself to code at the age of 22 and I am not a math genius by any means. I feel like I'm getting pretty good at it (almost 24 now).

The biggest thing to remember is to have a real problem you're trying to solve with programming. Just going through tutorials isn't going to teach you how to program. And then Google until you figure it out. I found it works best to get something functioning, and then go back and read the documentation or book about why it works how it does.

In my case, I started a company and didn't have the money (or desire) to find a developer to work with. So I sat in front of my computer and struggled through it. I had an actual problem that I wanted to solve.

I believe this came up in a previous discussion some days ago, but it bears repeating:

Working with/getting personal help from someone more experienced than yourself is awesome. The trick is not to bother them with (to them) trivial questions, but show that you have put in the work and ask them for their guidance.

Look over experienced coders shoulders any chance you get, and talk to them, to understand their way of thinking. I think this kind of learning has a lot more leverage than doing yet another tutorial.

I started programming when I was 24 (11 years ago) and working at my first job. A coworker was my mentor early on, and we pair programmed frequently for a couple of months. I read a couple of Wrox Java books and just learned by writing a lot of code and reading as much as I could.

Luckily, I was tasked with developing a whole bunch of forms for a client-server application, which the IDE helped me out with a lot with its WYSIWYG editor, and the programming work was relatively easy (no I/O, no DB access, etc).

The keys for me were:

1. Having a mentor early on

2. Flattening the learning curve with an IDE.

3. Choosing the right project

  * moving averages
  * linear regression
  * matrix operations
  * matrix lu factorization
  * polynomial interpolation.
  * multiple linear regression
  * cubic spline interpolation
  * variance, covariance, correlation
  * gamma function
  * t-test, t-value calculations

Learned to code from people better than me who like to teach. Teaching helps me reinforce what I do know. Writing code to solve problems helps keep it interesting.

There are two methods that helped me learn to code.

[1] Copy examples, and tweak them to understand how they work.

[2] Program a game or a puzzle. (Here I'm talking about a simple game like Tic-Tac-Toe, not a full-fledged PS3 of XBox game). Programming something that is purely for fun provides a lot of gratification and reward. The joy of seeing the result is what propels you in spite of the frustration of error and failure. Plus, since you're in control of the project, you can focus on the fun stuff and postpone or skip boring things. For example, have a go at writing a Sudoku solver, or Cryptoquote, or Mastermind.

I think the "non-technical" bit is superfluous—we're all non-technical when we first learn to code.

I learnt to code at 14 after asking my GCSE ICT (as in, Word, Excel, and FrontPage—that's the sad state of IT education in the UK) teacher what the "header files" I saw in the Deus Ex SDK were. He introduced me to Java, and, to be very cliché, the rest is history.

The main "textbook" I read was "Introduction to Programming Using Java"[1] (then in its fourth edition), which goes at a very easy pace and explain things well (I love this book, maybe its the nostalgia goggles but I'll never forget it and what it taught me). I'll add that I didn't have the Internet at home at the time; I had only a handful of resources to help me and all problems I encountered I had to solve by myself. Very "grindy".

If I were to start over, I'd probably go for a much nicer language such as Python, and use its tutorial[2] as well as Mark Pilgrim's Dive Into Python[3][4], and then move onto Django.

Basically, the best way to code is by coding—think of something to build, then build it, ideally trying a different way. Remember to read documentation and other (ideally smarter) people's code and follow (and, importantly, try to understand the reason of) best practices.

[1] http://math.hws.edu/javanotes/ [2] http://docs.python.org/tutorial/ [3] http://diveintopython.org/ [4] http://diveintopython3.org/

My (meager) coding skills come from doing what you're doing, but I'm also working on a project in conjunction with an experienced developer. Being able to look at each of his patches in github and see the changes in the code really helps.

I took classes my senior year in college. I started out with a class crosslisted in bio/engineering that used Matlab to interact with a circuit we built. The instructor included a lot of basic code for each project that we just had to improve on to get things working. It wasn't too daunting and Matlab is a nice place to start to get a handle on basic principles.

Then I took data structures and programming because I liked that first class so much. In between the two classes I taught myself from material for a 1 credit course that converted matlab people to Java.

It really depends what you want to do as a programmer. Different programming languages do better or worse jobs of making the general concepts of computer science digestible. My advice for someone just starting off, who wants to be "well rounded", is to start learning Python. 'Learn Python the Hard Way' followed by a couple more introductory tutorials will help you get your head around a lot of the concepts of computer science that are found in most programming languages.

From there, it's worth working on a couple projects. You'll have built a few by following the introductory Python tutorials, but pick something you're interested in and actually build it. It doesn't need to be a huge project, something small will do. Once you understand the syntax of the language and why you use specific concepts, building something helps cement that knowledge.

Once you've built a few of your own programs, you'll have a better idea of what you're actually interested in, and what you can do. You won't need to follow a specific route by then, you'll be able to learn what you want to learn. I'd suggest that you pick up a functional language next. Haskell does a great job of packing in a LOT of computer science concepts, especially on the functional side of things. Follow the same process you did with Python. Start with a couple introductory tutorials, then build a couple programs.

If you've got Python and Haskell under your belt, you're really ready to tackle anything you can think of. Learning a new language will be easy. You'll find deep library support for pretty much anything you could want to do. From there you really can pick anything you're interested in and built it or learn it.

First, I'm about as technical as they come (8 years old sounds about right), so take my advice with that in mind. But I think becoming "technical" is critical to learning how to code.

I don't mean you should start solving equations in your spare time. I just mean find a concrete problem that you're motivated to solve (i.e. something fun), and then solve it.

Maybe you think AI is cool, so try to figure out what it takes to make an interactive chat with the computer (easier than it sounds). Maybe you think computer graphics are cool, so figure out how to make a web page that has a ball bounce when you click it.

Above all, make the path interesting and fun for yourself. You'll get a lot further that way than you will by reading books or watching screencasts that brainwash you into the author's (or the programming language's) way of thinking. Most of programming is a transferable skill set anyway.

That's what I mean by becoming "technical". Just make something you think would be cool, and when you're done, make something cooler.

And if you don't know where to start, just remember this: Google is your friend. Search engines will point you to plenty of material you can copy-paste, and will answer 99% of coding questions you could possibly have. After 15 years of coding, there's still not a day that passes when I don't look up how to do something.

A hugely important thing to keep in mind when learning is "humility is endless". I remember when I started out I felt like I knew hopelessly nothing. Well it turns out that this is actually a good thing. You learn much better when you approach everything with the attitude of "I don't know this so I am open to everything" (There's a concept of 'Beginners Mind' in Zen Buddhism which is similar). I find that new programmers are discouraged by this feeling, when in fact the most dangerous thing is when you start to approach problems with the attitude (and we've all done this) "Okay I'm a smart guy , this should be easy to understand". So cherish that feeling of ignorance, and work to maintain it (the feeling not the actual ignorance).

And of course the biggest thing is to try to put in 1-3 hours a day of practice. Coding a problem you have solved before is not practice. Always be pushing yourself. At first this is very easy since everything is new, just code 1-3 hours a night. But as you get better continue to try to learn new things, code problems from a book you're reading, start learning a programming language that challenges you, implement new algorithms, refactor and improve something you've written etc. Essentially practice is very closely related to humility.

Put in enough hours of true practice and you will be a better programmer.

I also should add that I did find taking formal classes helpful (and it can help with pushing you to realize how much you don't know, force you to practice etc). People make a distinction between autodidactic and formal learning, but really the best solution is both, and they are not mutually exclusive so there's no reason not too.

I was 14 and faced the same questions you do. I was surrounded by all these guys who could bend bits with their thoughts and had pointers and stacks for breakfast. They all used see and did stuff that seemed amazing to me at the time. Add to that the fact I felt more like a 'creative', in the narrowest of senses, so I was not sure how to reconcile both my interests, my friends were no help and I did not know much about the demo scene, nor of people like _why and the Processing guys.

Somewhere along the way I found Perl, and the way from A to B was not paved with incantations. It took me a copy of Randal Schwartz's "Learning Perl" and a Christmas Holiday to get really hooked — the immediacy of thinking and doing and making mistakes and fixing them was paramount to my believing programming was not only for the initiated.

While I second all the recommendations for having a mentor and working closely with knowledgeable people, I disagree with putting IDEs in the middle and choosing PROJECTS (more on that on a second). I sincerely think there's a great benefit to shortening the path between you and running code, and I believe dealing with compiler errors and linker spewage can be detrimental to the overall purpose of getting acquainted with code and thinking about programs.

About projects: having something as a goal is definitely a must; I don't object to that, but to all the baggage the term _project_ carries. Have something around which you'll structure your thought, but allow yourself to tinker and to put it in the backburner if it proves itself to be not challenging enough or too daunting a task for your current knowledge level. If you're neither having fun nor being challenged, you won't improve.

If you want specific tips on what tech to use, it would perhaps be better if you told us what you want to achieve. Do you want to code for the web, to take your designs to the next step, to code simple workflows?

Find a language - start learning a language. Have a project you want to build. Then start learning a framework. Python -> Django, Ruby -> Rails.

Practice. You'll think you understand something, to only realize a few weeks later you don't. Just gotta keep practicing until you really get it - it takes a few 'Oh i think i got it..nevermind's

When you get stuck, try to answer it for a while, but if you are truly stuck - raise your hand and ask for help. Ask friends, or Stackoverflow.

The great thing about Stackoverflow is that explaining why you are stuck will help you better understand the problem. As you get better, you'll notice your questions get better.

In I believe 1975 I moved across the campus from 8 years of fines arts study to the nascent computer department (actually math department---wouldn't become computer department until long after I left) sat down in front of a model 29 keypunch machine took a summer course in a pseudo language modeled on IBM 360 assembler. It was made up of macros and was enough to show the basics of programming if not language. Shortly after that I was handed my professors old copy of Susan Stern's book on IBM BAL. For those who have never had the pleasure, it is (was?) very near a high level language even if it had a low level implementation. My first observation was that there was very little difference (meta) from planning a piece of sculpture to planning a program. As I joked, the biggest difference was clean-up; with code, you just turn things off, with sculpture you spend a fair amount of time with physical work. My first significant project was building a concordance generator---a key words in context generator from a given corpus. This meant not only the usual trapping of text in, new text out with no library to aid, but taking quick-sort apart and writing it in assembler. Looking back it was one of the harder things I've ever done; but that said, also one of the most enjoyable. There after I began the usual progression, skipped PL1, took FORTRAN etc. I was introduced to C at the New Jersey Computer Faire by Scott Guthrie who was selling a version of Small C, enough to get a leg up. Then BDS C on my 8085. Looking back, I've loon since adopted an approach of 'What have I lost, what have I gained' with regards to the language and syntax. Programming itself remains the same, although some things are easier to express in some languages versus others (Noam Chomsky and 'Language conditions thought' seems to apply to computer languages in my opinion.) Over the years, it is the usual 'Wash, rinse, repeat' with regard to language with the selection dependent on what the client wants or provides.

Make it sink or swim. Force yourself to learn or perish...you'll learn.

To echo what others have said, having a problem you need to solve is paramount to succeeding. If you're just reading a programming book, being introduced to totally foreign concepts that you never put into practice, you won't get anywhere.

Based on your background (looks like design and electrical engineering), I think you'll do fine.

Some of my first projects were: - A directory (basically just listings on a map) - A customer survey - A todo manager - A wordpress plugin

All simple projects, but all things I was able to use. When you first start, sometimes you have to reinvent the wheel a bit just to get some practice (it's not like any of the aforementioned haven't been done a thousand times). What you're looking to develop are fundamental skills:

- How to design a relational database - How to design a non-relational database - How to query said database - How to work with strings (splitting, imploding, etc.) - How to work with arrays and loops - How to work with objects etc. etc. etc.

As you keep adding new tools to your arsenal, you'll wake up one day and be really surprised with what you know.

...And as a few others also said - stay humble. You can be proud of the things you create - but just look around every once in a while and find someone better than you. You won't have to look very hard.

I wrote this http://learnpythonthehardway.org/book/ and http://ruby.learncodethehardway.org/ and am now working on this http://c.learncodethehardway.org/ so I'll give you advice that fits with what I've been doing to teach people:

1. Do every exercise, type in every bit of code, DO NOT COPY-PASTE.

2. Make the code run, fix all the bugs.

3. Repeat until you are done. Do it 1-3 hours a night.

That's it. It's an old method: repetition and practice to build base fundamentals so you can apply them to more complex problems. For the very beginner this works better because the topics are incredibly simple, but their experience and understanding needs work. By making them just type it in, then explain it, I get them experienced and bust through a lot of fears about learning something new.

Hope that helps.

Crap, my looooong answer disappeared in a timeout.

The short version: in 1999 I was a junior Graphic Designer and was given the task to build our first website. At the time i thought programming was too abstract. The site was done entirely WYSIWYG in Dreamweaver and total crap but it was online. After a while we saw some cool effect somewhere on the net and I had to implement it on our site. It wasn't that hard, actually, and it soon appeared to me that my way of using graphic design/dtp programs (I knew most keyboard shortcuts by heart, used almost exclusively the keyboard and numerical values to manipulate objects, didn't use rulers…) was actually quite abstract compared to what most of my co-workers and friends did.

After that I just gave myself tougher and tougher challenges until I "pivoted" to become a full time Web Developer.

The whole transition took 8 years of reading books and tutorials, trying, failing, trying again. But maybe you are more on a hurry?

Learning to code is the same as learning a second language. You must recognize the amount of energy it takes to learn french, and apply it to learning ruby. Your final goal - which for the HN crowd would be something like building a SaaS web app, is equivalent to writing a novel. But before you get to your novel you must learn how to speak and think in the language. You need to know the vocabulary and how to write sentences and then paragraphs. Start with ruby or javascript, and become comfortable with the vocabulary. Learn about strings, arrays, loops, methods, functions and classes. Understand the basics of input and output. Commit all the small code snippets or phrases to your rote memory. You need to know what a for loop is in your sleep. Write it over and over again until its ingrained in your memory, until you can write it without looking at any documentation. This will be the boring part, but you need these tools to continue to the more rewarding states that involve creativity. From here start reading small programs ( As a front-end developer I started by reading jquery plug-ins I was using for websites, sticking with ones with less then 300 lines of code). Read every statement of these programs and if you don’t know what something does, google it. Write every line out for yourself, making sure you know what everything does. Writing out code it the ultimate way to learn. Do this as much as possible. Translate these small programs into English. Actually write out the translation. Then a few days later try to write the program yourself by only looking at the translation you wrote. Try to memorize patterns you notice. Think of features you would want to add to these programs- try adding them! These 300 line programs are like essays. When you are ready to write you own essay, start off by building a calculator. If you still don’t have any idea how one would go about building a calculator, go back to reading more programs written by other people. When you are looking at other programs try and find elements that you could use to build a calculator. If you are ready for the calculator then you are transitioning from merely knowing the vocabulary of a the language to creating something meaningful with it. When creating a program start by thinking of everything you need, gather all your requirements. “I am going to to need to create buttons that a user can press”, “ I am going to need a method for a plus operation”, “I am going to need to store values pressed in an instance variable.” Take your requirements and ideas and build it. From here, build bigger and bigger programs. As they get bigger they are no longer programs but applications. Keep reading other code are writing it. Learn about frameworks and databases. Buy books on application development and read them. Try and get some consulting work- If you have a responsibility to a client it will help motivate you. Create your own small applications, and then slowly morph it into your novel.

Writing code is the real key- think of writing at least 50 lines of code a day.

This process takes about a year.

Just a tiny little suggestion if you don't personally know anyone who can help you code, try a good website. StackOverflow.com is a pretty awesome Q&A site with lots of smart guys on there. Just make sure you do Google stuff first and don't ask questions without showing that you've actually done some research on your own.

I started learning html/css/javascript by viewing the source of websites, copying/pasting each file into notepadd++ and then saving each one in a desktop folder.

From there I changed the paths so the style.css pointed to its location in the folder. I'd do the same thing for any .js scripts. After getting it running locally I would deconstruct the site (remove and add back various pieces of code) to witness how one thing relates to another.

I myself, need to jump on frameworks. I'm too stuck in my comfort zone of design and front-end skills.

For me, nothing really clicked until I actually started working on something that was meaningful to me.

Before that, I tried every book I could find, religiously watched the latest Railscasts, Peepcode screencasts, etc. and watched every free tutorial out there. Until I started working on something that I needed and just plowed through it until it was built, nothing truly clicked. It also helped that I locked myself in my attic for three weekends straight to get my first "real" project done - setting aside that kind of time to focus is huge...

Just pick a small-ish project that is personally relevant and hack your way through it until it's reasonably functional. Also pick a language that is fairly simple and readable (I chose Ruby, but there are lots of good options) and a problem that isn't too difficult at first (e.g., a straightforward CRUD app will build confidence before moving on to bigger and better).

Also, you'll see a ton of recommendations for the "next big thing" (e.g., Node.js) on sites like HN and you'll be tempted to run from one new language or framework to the next. Try to avoid that if possible. I think the key is just picking anything that can get you as close as possible to solving the problem you're trying to solve. Later on you can worry about finding the ideal tool for the job.

I should note that I'm not a pro developer by any means, but I can hack together prototypes and simple apps fairly quickly coming from a similar background to you, and this is the way I went about it...

Even someone who learnt when (s)he was 8 had to learn somehow ;). In my opinion (no one is gonna agree but I'll tell it anyway), I'd start with a language like BASIC. You need to understand variables, loops, conditional branchs, and all the basic stuff before other concepts (object oriented programming, etc ... ). In modern languages, everything is mixed together, which is good for coding but ot that good for learning. I'd do Basic -> C -> C++ . This combo will give you all the basics you need without teaching you "bad" habits. Then up to you : java, python, ruby, haskell ...