I recommend coming up with a small project to work on. That will give you some focus and might lead you down some paths that you wouldn't necessarily take with a step-by-step tutorial. I started with a simple site for cataloging video games. Maybe you can come up with something that's just beyond what you think you're capable of. That way, you're not just repeating a bunch of steps.

Don't be afraid to copy and paste code. It's a big part of the learning process. Just be sure you understand what the code is doing as you're copying and pasting.

The main thing that's helped me improve is adding new features to simple projects I started -- things like a login system, image uploads, pulling data from an API like Twitter, Amazon or Youtube, etc. Just tackle things one step at a time and you should be able to add any new feature you can think of. You'll be forced to work with different kinds of concepts & objects that you might not use often (hashes, callbacks, etc.).

For Rails, Railscasts.com is a great resource. If you have a feature idea, chances are there's a Railscast video to get you started.

I love Michael Hartl's Ruby on Rails Tutorial. If you haven't worked through that yet, definitely give it a try. It will get you more comfortable with tools like git and services like Heroku and github.

Also look into meet-up groups in your area on meetup.com. I found a Ruby group in Los Angeles that way. Just showing up each week was a huge help. I learned much faster by being surrounded by coders. I also went on to help other beginners understand basic concepts. Teaching others really reinforces the basics for you.

I also recently wrote a post listing the tools and books that helped me go from 0 to part-time developer. You might find some insight there, too.

Launch Day sends and receives data from a Rails app and API that I built. The Rails app interfaces with the Urban Airship API to send push notifications to iOS devices.

Launch Day is not especially pretty or advanced, but I made it mostly by myself, it does what I initially set out for it to do and it works. I'm proud of it and I will be improving it, adding features and porting it to iPad and iOS 7 in the next few months.

I think my story may be of some use to beginners and aspiring programmers like me, so here's the basic gist of how I got here.

In 2005, I was working in television as a segment producer at G4/TechTV, the twisted hybrid of a video-game centric TV network called G4 and a much-loved, now defunct tech-centric television network called TechTV. On the side, I was creating content for my moderately popular tech blog at plasticbugs.com (also defunct). There, I would push the limits of my very limited computer skills to create what I called 'hacks': mostly-harmless, technology-based pranks for my own amusement. One was a Skype/iTunes Automator Workflow that called my phone and played a song after emailing a song title. Another time, I removed the DRM from a silent .99 cent song on iTunes and posted it on my site for anyone to download, along with step-by-step instructions. I also put my keyboard in the dishwasher after I spilled beer on it. My very, very smart friend Ron said he had heard putting keyboards in dishwashers was something people did, so I did it and documented the process for my blog. That stunt landed me on NPR a few years later.

One day, I thought it would be cool if GIMP, the open source image editing application worked more like Photoshop. I knew Photoshop pretty well. GIMP was similar to Photoshop, but the commands, their locations in the drop down menus and tool names were all quite different (e.g. Gimp's blur tool is/was called convolve). GIMP was not easy to use for someone who knew Photoshop.

Maybe if I downloaded the source code and opened some of the files in a text editor, I might be able to come up with a plan of attack. Unfortunately, for a guy like me who only knew HTML and messed around a little with Processing and Applescript, GIMP's source code was pretty much indecipherable.

A day later, I was talking about the GIMP-to-Photoshop idea with Ron and how impossible I thought it would be for me to actually execute it myself. Ron said, "You'll figure it out. Just download the source code and do it."

So, I went back to the GIMP source code and started reading, looking for anything that looked familiar.I read through the code file by file, line by line. I was looking for menu commands, names of tools, and wrote down every file name and line number where I found something that matched. Then, I would use 'find and replace' to change the code to match the Photoshop equivalent, taking care not to overwrite working code, just words that I was certain were used only as text strings.

After months of reading and editing each file, I had pieced together something that actually compiled and worked on my Mac. I posted GIMPshop on my blog, along with a detailed writeup of exactly what I did and why, and waited. Several hundred people downloaded GIMPshop by the following morning, and it seemed like I had a moderate success on my hands. Two days later, on April 1st, someone posted GIMPshop to Slashdot and I quickly had far more traffic than my site could handle. My web host shut me down and I rushed to get re-hosted somewhere else. In the meantime, Slashdot commenters thought GIMPshop was an April Fool's prank.

Nearly a million downloads later, I should have been pleased with the result -- but I wasn't. To me, GIMPshop felt more like a stunt. I performed the coding equivalent of pounding a square peg through a round hole. My hack was inelegant and I wished I knew enough to do it properly. I also wanted to eventually make something of my own and execute it. I had no shortage of ideas, but actually turning those ideas into working code was impossible without knowing how.

I began to look at more technical blog posts and demos online: cool CSS tricks, jQuery, a new-to-me programming language called Ruby, and a short demo by a guy with a funny accent who said "whoops" a lot. I didn't know how to code, so most of it was not something I was going to just 'pick up'. However, the Ruby on Rails scaffold stuff from that video looked easy. Based on the number of blog posts and Ruby tutorials being posted, Ruby itself seemed like something worth learning. And, thanks to my GIMP experience, I was semi-comfortable with the OS X terminal, so I started there.

Over then next several years, I spent about one or two nights each week reading a book or working through a tutorial. Then, I dedicated at least a half-day every weekend to reading, following more tutorials and working on small projects. Though it took me years, this whole process would have gone much quicker if I didn't have a full time job in a completely different field. What follows isn't necessarily the quickest or easiest way to learn iOS development, but here's how I did it, step-by-step.

1.HTML & CSS

I learned basic HTML in 1995, but that was the end of my 'coding' ability. So, I decided to start my education with a concerted effort to learn CSS properly. Within a month, I had finished one CSS book and knew enough to build web pages that looked half-decent.

2. Ruby

Rails was fun to play around with. But I knew that, with Rails, I was just repeating a bunch of steps from tutorials. I still didn't know how to make what I wanted, so I had to take a step back and learn Ruby.

I read Why's Poignant Guide first because it seemed so approachable with its cartoon foxes. I understood most of what I read, but some concepts like blocks and symbols, I didn't quite get. That led me to the first of many Ruby books that I would read over the next year.

3. Ruby on Rails

After two beginner Ruby books, I learned the basics of Ruby on Rails, a framework for building interactive/dynamic websites with Ruby. I read books like the Pragmatic Programmers Rails book and watched videos. I got a Peepcode subscription & watched a handful of videos from railscasts.com.

I created several project sites, mostly just to learn. One tracked 3D blu-ray movies and video games with Amazon API data. Another was a social site with user accounts, logins and more.

Around this time, Michael Hartl's Rails Tutorial first appeared. Rails and the process and tools that I was learning about from Peepcode (things like git, RSpec, Heroku, gems) suddenly became a lot more clear after plowing through Hartl's well-written guide.

I also started attending Ruby programmer meet-ups every week where internet-famous Ruby guys helped and advised new-comers like me. I would bring along whatever beginner project I was working on and if I got stuck, I had a place to get answers.

4. iOS False Start

After becoming comfortable with Rails, I purchased my first iPhone programming book and it scared the shit out of me. The concepts were mostly foreign and the examples were nearly impossible to comprehend. This was not going to be easy.

I checked online for some videos to start with instead. The Stanford CS 193p iTunes U course seemed like the most popular. I watched the first six videos over a couple weeks and, in the end, I had learned exactly nothing. It was obvious that I needed to start with the prerequisites or everything would continue going right over my head.

5. Objective-C

I picked up some basic Objective-C from this book: Programming Objective-C.

6. Then, I learned C.

I felt like I wanted to work on something fun for my first iOS project after plowing through that Objective-C book. I bought a Cocos2D book. But there was a lot C stuff going on in that book and I wasn't understanding the code. That's when this book happened: The C Programming Language

Also, that advice about not working on a game for your first iOS project? That's good advice that I should have followed sooner. After the C book, I gave up on making a game for my first app.

7. Xcode, iOS & Stanford

Now, I felt like I had enough of the basics to go back to the Stanford iTunes U Course. Though it was still difficult, I was understanding much more of what was happening. The hardest things were not the Objective-C language, but the workflow, concepts like multithreading, callbacks, delegation, observers, and the tools. For me, the Stanford course was the key to the putting all the pieces together.

Nearly five years after picking up my first Ruby book, I was able to cobble together a very basic iOS application and the rest I learned as I went, adding features along the way.

I don't think I would have as firm a grasp on Objective-C if I didn't start with Ruby and Rails. Things like object oriented programming, MVC, and callbacks were much easier for me to understand in Ruby first. Then, I was able to apply what I already knew to Objective-C as I learned it.

Giant pile of books.

Where I went for help:

The LA-based Ruby meet-up group I attended was fantastic. They were very welcoming to newcomers and really helped me to get past any stopping points where I felt I could go no further without more information. Once I knew enough to know exactly what questions to ask, the answers came much easier.

I'm also a member of the Something Awful forums, so when I got stuck, I usually went to the Hardware/Software sub-forum for answers. In many cases, after I had finished typing my problem into the post form on Something Awful, I would suddenly understand what my actual problem was and how to solve it without actually submitting my question. This, I have come to find out, is known as Rubber Duck Debugging. Stackoverflow and NSScreencast were also an enormous help.

It can be discouraging if you don't have a formal education and don't necessarily know where to start or where to go for help. Hopefully, you'll just start doing and persistence will get you to your goal. If you spend enough time doing anything, you get decent at it.

If you like video games, get my app!