Learning to Program, Part I: How I did it
Posted: January 23rd, 2012 | Author: Brandon | Filed under: Education, Programming | Tags: Learn to Program | 3 Comments »This is a part of a three-article series on my journey so far as a programmer:
- How I learned to program
- Programming lessons that changed my life
- Why everyone should learn to program (and where to start)
Quite often, when I tell people I left a career in marketing to teach myself to program and develop software, they react with surprise or even amazement. As much as my ego wants it to be, it’s really not all that special, and it’s something I believe anyone can do, and many should.
Here’s how I learned to program, how it changed my perspective, and how you can do the same without falling into some of the same pitfalls I did.
The spark of interest
After spending nearly 5 years learning online marketing for the startup I worked at, I had become profoundly unhappy in my job. The only path forward I saw for myself was “marketing guru” (ugh), and I was constantly depressed.
Several people, including my dad, suggested that I pick up programming, and that I might enjoy that more than my present career. I perceived it as a serious affront to my abilities as a marketer and fumed at the advice.
But eventually, I decided to take a few minutes to talk with our lead developer and brought the idea up. His response surprised me and sidestepped all my concerns: “Everyone should know how to program. It’s a part of living in modern society. It’s like knowing how to change your oil or change a tire.”
We talked late into the night, and he wanted to show me how amazing programming was. He wrote a little program in Ruby that would create different animals, give them stats, let them fight, and see who would win.
I watched the strange symbols dance around the screen and was totally fascinated and thoroughly confused.
He handed me Learn to Program by Chris Pine and suggested that I start reading it. He said that I’d know whether I had any interest within two weeks, and my response would be either “this isn’t for me,” or “people get paid to do this?”
Learning to program
I started in on the next night, and asked the second question within hours. Captivated, I spent every night for the next few weeks working through the exercises in the book.
Each day I’d run into the developers’ room to talk about concepts, check my code, or get help on the tougher exercises (looking back, a recursive algorithm for parsing an array of arrays is a bit much for beginners).
Clearly, it was a stroke of luck that I worked with wonderful, knowledgeable people who were too happy to help me along the path.
I continued this pattern of learning new concepts through several more books, the best of which was Beginning Ruby, by Peter Cooper. I then picked up Agile Web Development with Rails and started building Rails apps along with the tutorials. I was actually making stuff, and felt like I could take on the world.
Getting overwhelmed
From there, the books thing was working so well that I kept rolling with it. I picked up several advanced books that started to take me off track. Somewhere between Design Patterns in Ruby and Test-Driven Development, I started to feel like I’d gotten in over my head.
To make matters worse, I couldn’t separate what I was learning about Ruby from Rails. I didn’t understand where the language ended and the framework began. Did I have to read the whole “Programming Ruby” book? What about Rails books? What was MVC? I had to learn Javascript too? And CSS? And HTML?
I confided in my friend and admitted that I’d failed as a programmer. I couldn’t do it all at once, and there didn’t seem to be a way to break it up. He told me, “That’s enough, your problem is too many books. You need to write some code and go from there.”
My first projects
My friend was right: it was time to just start making things. I got tiny assignments from the dev team: small copy or functionality changes, or bite-size features that were low-risk if I failed.
The things I built were embarrassingly elementary, but it’s an amazing feeling to ship code, and I felt back on track.
I tried and failed at a few more side projects. I was wholly unprepared to build the square-foot-gardening app I wanted to make, having underestimated its difficulty.
It was about this time that the company started to go under and I was shown the door. I suddenly lost my support network, and it became more difficult to practice my coding skills.
Luckily, just a few months later, I discovered Ruby Mendicant University. Started by Gregory Brown, it’s a free online school for intermediate programmers with a strong focus on building stuff for real-life situations.
Going full-time
After completing the core Mendicant University course, my projects became slightly more ambitious: A video upload site that limits you to 1 minute (a terrible idea, if you’re considering it), then a lunch-voting app, ToDoGroove, and now Hashbadges, which is mostly under wraps for the time being.
Even with all that, I still had a mental block about becoming a full-time programmer. I was more comfortable hanging back a bit and helping manage programmers than trying to write code that would actually be used in the business.
Luckily, I had a friend call me out on this and tell me that it was do-or-die time. I either needed to start coding and stop making excuses, or be happy with a non-technical role. We spent the next week pair programming, and I realized that I really am capable of programming full-time.
That week, I moved my desk into the programmers’ area and decided to become a full-time developer. (Kudos to my employer for not firing me for that one.)
I’ve only been a full-time programmer for about 5 months, but it’s been the most fun and interesting few months of my career thus far.
I have no idea where the future is taking me, because I’m having so much fun with what I’m doing now. No matter what I decide to do next, the act of learning to program has taught me lessons that completely altered the course of my life.
I’ll outline those lessons more fully in the next post.