Ask HN: Non-technical people, how did you learn to code? | Hacker News Reader

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

29 pointsfreshfey55 comments

I'm currently trying to learn to program with the traditional route (tutorials, books, screencasts and a lot of practice) but I'm looking for people who've tweaked this route. Stuff that supercharged their learning. I know this is a coder's community, but I also know that there are a lot of non-technical, very smart people reading. So non-technical people (no math geniuses or coders who learnt coding when they were 8) how did you learn to code? What was an uncommon approach that helped you a lot? How would you mentor/teach a friend (who's completely non-technical) to learn programming?

Please don't get me wrong: I'm not looking for an easy, learn programming in 48 minutes approach. But I'm questioning the traditional route of learning to program.

(I also started a Forrst discussion about this, but aimed mainly at designers, here http://forrst.com/posts/Designers_how_did_you_learn_to_code-vtM)

View on HN

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.

Awesome! I didn't know that you were doing the same for Ruby, thanks.

+1 are you planning on releasing a paperback version of the Ruby version?

Zed: I've been doing your Ruby tutorial for the last three weeks, and have learned more on yours than any other. Way to go.

I started learning Ruby a couple weeks ago with your book. Thanks for your help!

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.

thanks for the tip! It would be awesome if you found that thread somewhere.

I think this is what i was remembering.

http://news.ycombinator.com/item?id=2995733

Thanks!

Yes, and this. Google everything you can, but when you're stuck, find someone who knows. It's how I finally wrapped my head around version control.

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.

What's the language you learnt? What company did you build? I'm asking because there is no info in your profile! :)

I most likely count as a technical person, but I couldn't resist weighing in. One key factor when I've been learning something programming-related has been to actually deal with problems that I need to solve.

If you're currently puting reports together by hand, see if you can write a bit of code to do the repetitive part. If you need to filter a stream of articles, see if you can weed out the easy 80% using word matching, or some other heuristic you develop. If you have a spreadsheet to do your budgetting, see if you can replace it with a program that can fetch all the available data, and spit out relevant results.

Very true, though it would help a lot if the need to solve something is driven by an innate interest, curiosity or simple laziness to do repetitive work (so as to pursue more interesting things).

Monetary motivations don't really count. No doubt it helps, but it won't compel or make you strive to become a better programmer or make something truly great.

Have something exciting and technically trivial that you want to build. Draw it. Build it.

My first "programming" projects were a Processing app that fills your screen with randomly colored dots that increase in size, a website that will send an email after a one-year delay, and a pair of headphones that play back everything that happened 20 minutes ago.

These were perfect projects because they were "correct" and presentable when they were done, they have small enough scope that you can spend days perfecting the details, and they were done when they were done.

Lower the bar. Incorporate things you already know about. Build it for yourself. Make the objective a thing rather than a skillset.

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

Another excellent answer, thanks. I'd love to talk a little more but you don't have a twitter handle or your email in your profile :(

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.

Interesting approach. So how should I become technical? Let's say I'm interested in AI, I can't just think about a problem without a certain base knowledge right?

Stanford is offering free online access to their courses. You may want to check that.

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.

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.

Is there a reason why you recommend 1-3 hours and not let's say 6-8 hours (split wisely)?

It really depends on the person. I find I'm not able to absorb more than 1-3 hours of new stuff each day. It's also a lot easier for me to commit 1-3 hours every day. There's an idea that you need to learn a lot up front, and then you're a "programmer". Doing 1-3 hours of learning a day, gets you in the habit of ALWAYS learning. You never know enough, so it's not a 3-4 month process where you come out at the other end and you're done. I think 1-3 hours a day is manageable by everyone, and you don't ever run into diminishing returns for the day.

That doesn't apply to actually programming. If you're building something, and you have the time, more hours in the day is generally better. If the focus is on learning, 1-3 hours is probably good for most people, and something that's easy to keep up with for years.

Because your goal is to get to thousands of hours of practice. I think the probability of burnout is way too high if you put 6-8 hours of practice in a day. The only way to get to thousands of hours is to practice every day for a long period of time. With 6-8 hours it's very easy to say to your self "Well I did put in all the time yesterday, so today I'll take a break", and this in turn tends to lead to finding yourself spending weeks/months without practice. Slow and steady and whatnot ;)

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.

Hey Freshfey,

Over the summer I taught myself how to code (PHP). The route that I took was the following:

1) Watch screen casts without doing any coding and just understand the basic concepts and syntax. This was done via Lynda.

2) I then went to the tutorial Zend has on PHP 101 and did each and every exercise until I understood it.

3) Lastly, (this I am still in the midst of doing) is attempt to replicate a website or a certain functionality of a website. Meaning apply everything you just learnt from step 1 & 2.

By going through those three steps I've become pretty good at coding and now it's all about practising and to continue putting together things I've learnt into real stuff.

Some AMAZING resources that I highly recommend checking out (no matter what language you're learning is:

http://stackoverflow.com/ <-- Amazing Q&A site that SHOULD have the answer to just about any problem you run into

https://github.com/ <--- Take a look at other people's projects and see how they are doing things in the language that you are learning.

The last and final tip that I can give you is stick to it and don't give up.

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?

I'd love to code for the web and the mobile web. And I chose my weapons: RoR, HTML5 and JavaScript. When it comes to learning I'd love to be prototype/side-project proficient, so than I can quickly code an idea and show it to people and iterate from there.

Myself, I'm still slowly learning. Coding came out of necessity. I've been working for different technical support jobs for pretty much my whole adult life, and started off trying to automate a couple of things around the office, and then for clients (a PHP script that generated a regex which configured a client's email account in Outlook Express, for example).

I created a couple of useful things which gradually became more complex - a little voicemail queue (where we'd enter client messages and then call them from the top, in a cycle), then generated a map of our client's locations using google maps, etc.

Nowadays I'm fairly fluent in JavaScript, VBScript (don't laugh!), and I'm gradually learning Python simply because it's something that I need to learn for a project. I'm not a professional coder by any definition, I "get by" with a little help from my friend (who IS a hacker).

So my advice would probably just be "go your own speed, on your own highway". It really depends on your needs.

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.

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

Can you define #3? Meaning going from easy to difficult? Or starting with a difficult task and trying to solve it (at the beginning everything seems difficult, but yeah :).

I meant choosing a project that is not too difficult, but is interesting. Solve a real problem, even if it's small. One advantage you have is that instead of being a programmer, you have expertise in something else. Are their any problems in your own field that you can solve with software?

I implemented a lot of statistics functions to learn how to program in a language. Some of the things I've learned on include:

  * 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

One limitation of the above is that it doesn't explore all of a language's features. The above are mostly interested in array processing. There aren't any classes or generic types or what-have-you.

IDEs all the way! I started with Matlab, which was a super gentle way to start. Then I moved to Java+ Eclipse. Now I mostly use geany (linux TextMate). I'm not quite at vi level yet :).

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/

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.

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?

Too bad the long answer got lost :( Well, not in a hurry, but if I can save a couple of years by learning and working smarter, I'd take it! I'm just testing the general assumptions to help me with my current learning (is there a better way? How can I improve? etc.)

In 11th grade (1999), I learned how to program in Javascript from http://www.htmlgoodies.com/primers/jsp . I went through every single one of those documents / primers.

As zedshaw says, do every exercise, type every bit of code, etc.

After learning javascript, I went on to learn something more immediately useful. It took me about a month before I had built and completed my own local file search engine with jscript (windows scripting) and ms access. I altered my sleep schedule to 34/14 (awake 34 hours, sleep 14). If your mind is actively engaged in the learning, you won't need to sleep regularly. Sleep was the only limiting factor.

3 months after first learning javascript, I had rewritten my file search engine in perl and C, and upgraded my database from ms access to mysql. I didn't know much about perl and C, but I was happy to now "know" 3 languages and 2 databases.

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.

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.

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

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.

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.

Look through this book, I graduated with a degree in ECE 5 years ago, and this book blew me away: http://www.amazon.com/Elements-Computing-Systems-Building-Pr...

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.

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

I agree codecademy was the most fun I've ever had learning a language. I'm going to college now, trying to struggle through at least one language, but the professor only reads out of the book. :/

Although I have been programming for many years, I have never really given Javascript a chance. A friend showed me Codecademy a few days ago, and as a newcomer to the language, I really liked to way the basics were taught.

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.

A lot of gems here, thanks a lot!

That is a great roadmap. I'm a new Ruby dev, and am grateful for this info.

Reply on news.ycombinator.com