
Ask HN: Non-technical people, how did you learn to code? - freshfey
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?<p>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.<p>(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)
======
zedshaw
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.

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

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

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

~~~
phreeza
I think this is what i was remembering.

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

~~~
freshfey
Thanks!

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

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

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

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

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

~~~
freshfey
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 :(

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

~~~
freshfey
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?

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

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

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

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

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

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

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

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

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

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

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

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

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

~~~
freshfey
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 :).

~~~
MikeMacMan
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?

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

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

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

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

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

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

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

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

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

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

------
abbasmehdi
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...](http://www.amazon.com/Elements-Computing-Systems-Building-
Principles/dp/0262640686/ref=ntt_at_ep_dpt_1#_)

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

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

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

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

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

