Why the Hard Way is Easier: Learning Ruby the Hard Way: Practicum

Why the Hard Way is Easier

Zed starts out by explaining that this was the way all programming was done before the copy-paste from electronic sources became so common. People took a book, put it next to their keyboard, and physically typed out the examples. To make this successful, you have to type it exactly and get it to run. No shortcuts, not philosophizing, no copy-paste. Zed also makes very clear that this is a foundational book and approach. Will you learn all of the ins and outs of programming by doing this? No, but you will develop some solid Foundational chops to build on going forward, and that's really the goal. LRtHW aims to teach three things, and from an Adult Learner's perspective, these are not emphasize enough (I'm sorry, I can't use words like "Androgogy" in a sentence and keep a straight face. Maybe that's my failing). Those three things are:

- Reading and Writing
- Attention to Detail
- Spotting Differences

Reading and Writing

This is the point of physically typing in the sequences of characters. Some of them are weird. Some of them are not common for people to use in their every day communication. that's why the idea of not copy-pasting is so important. You have to do it with an eye towards repeating every character so you can appreciate why those characters are being used. there is a reason. Physically typing them gives your brain that brief but ever important option to say "hey, why are we using that?"

Attention to Detail

By typing in everything exactly, we will likely not type in exactly what we think we are typing in (still with me on that?). The simple fact is, we are not as careful as we believe we are. Our brains are very helpful; it works to help us tease meanings out of things we have familiarity with, and when we make a mistake, it's very helpful in working to get around the error, so much so that w don't really notice if we make a mistake. Fortunately, run time engines and compilers are notoriously picky; they know what they can and can't interpret, and erors help us start to see what we may have missed or typed incorrectly.

Spotting Differences

IDE's have lots of tools to help a programmer spot the difference between two code examples. This book expects users to see them with their own eyes. It's a skill that's important to develop and very helpful in the long run (let's face it, sometimes the IDE isn't even an option when you are debugging a remote server that is exhibiting problems, so best to not entirely depend on them).

Do Not Copy-Paste

Again, copy-paste is tempting, but Zed solemnly warns that users will not get the benefits if they just copy-paste the code. The tedium, the time spent typing all of this out is like building muscles. There's simply no way around putting in the repetitions necessary to fatigue (and thus make stronger) the muscles, whether they be in our hands or our minds. Read, Understand, Apply Persist, Achieve. It works for the Hardgainers in Bodybuilding, it should work for the Hard-gaining Programmer's, too :).

A Note On Practice And Persistence

The first time I stepped on a snowboard, even though I'd ridden skateboards for much of my life, it was a foreign thing, an my body didn't know how to do it. For several hours, I fell repeatedly, I could barely manage to keep upright, and I was nothing like the graceful kids who were trucking past me effortlessly  But I kept at it, and then, at some point, it clicked. I found that magic place where my balance and center of gravity made sense. I was able to do rudimentary turns, and after a few days I started to get to the point where I could handle steeper terrain, some jumps and other aspects of the sport that just a few days earlier seemed impossible. You don't reach this point without putting in the time.

I've gone through several programming boks and dabbled in several languages, so why wasn't I a proficient programmer afte all these years? Because of two things. First, I used the languages to do what I needed to do an then when I had those tools in place, I just used the tools. The net result was that I had lots of projects where I figured out how to do something and then stopped. To get good at something, though, you have to keep learning about it and pursuing it. That will be the difference with me and Ruby. I'm now in a place where daily Ruby needs and efforts are becoming more and more real (and measurable) parts of my work. Therefore, I can't just build a tool and blindly and half-understandingly maintain it. I need to develop the knowledge necessary to build stuff from scratch and then be abe to maintain, grow or restart different projects. The simple hack approach won't cut it going forward, so I have to go for it and make this all work. A bit every day (and a missive writing about it) I hope will do that :).