I always have such ambitious plans for the semester breaks: books to
read finish, lesson plans to revamp, furniture to refurb (finally gave up on that one–can someone just take me to Ikea?), trips to take, people to see… sleep to catch up on (Yeah. Right).
Maybe I need to look up the definition of “break.”
Along with a laundry list of other things, one item on my summer to-do list is learning Ruby on Rails. I am frustrated to realize that I remember precious little about object-oriented programming (Uh, what’s a class again?), so I’ve basically resigned myself to starting back at square one. I’m trying to convince myself that this is a good thing.
While working with Ruby this past week, I started noticing several core principles that can apply to any type of programming language. I grabbed a sheet of paper, and as I continued to work, I started jotting them down. As the list grew, I suddenly realized that these were all things I already knew… based on my background writing and teaching writing.
I’m not going to make the argument that computer programming codes and linguistic codes (writing) are the same thing. Clearly they’re not. But the writing processes of programming languages and human languages actually might have more in common than you think.
1. Draft and plan: Going old school with pen and paper
Have you ever pulled up a blank Word document, started typing, and emerged 5 hours later with a 10-page essay that’s not only well-argued, but articulate, engaging, and flawless? If you answered yes, you’re either lying or a bit misguided in your estimation of your abilities. Or you’re the only one of your kind and I’d like to meet you (and I’d also like to read that essay, if you don’t mind).
I can’t tell you how many sources I’ve come across in the past few weeks that advise programmers to turn away from the computer screen and draft out their program first on a piece of paper or on a white board–in plain English, not code or pseudocode. I was comforted to hear that even the best programmers don’t sit down, fire up their text editors, and just start pounding out code that miraculously renders as a brilliant program.
But why would they? The best prose writers don’t do that (even though most of us kid ourselves into thinking they actually do). Just as good writers draw mind-maps, sketch outlines, or make flow-charts before they being writing an essay, good programmers plan out their programs on paper before ever writing a single line of code.
2. Don’t expect to reach a place where you know everything. Know your resources instead.
I wish someone could have gotten this message through to me years ago. I have a “need-to-know” problem, characterized by the debilitating desire to know everything I can about something before I start working on it. The reality is (in both writing and programming), until I get over this, I’ll never be really productive.
While you’re trying to learn a new programming language, instead of trying to memorize every single command, you’re better off spending a little extra time becoming familiar with your resources. Figure out which forums to
lurk read, how to ask the right questions, whose blogs to follow, and how to access the right code libraries.
More importantly, understand when you need to build something yourself and when you should draw on your resources to find the pieces you need elsewhere. When you’re trying to learn a new programming language, sure it might be useful to build things yourself from the scratch… but eventually that slows you down. You’ll save energy and speed up production if you can integrate code from other sources–the programming community is all about sharing.
The same principle applies to writing–and no, I’m not talking about copying-and-pasting. I know. That’s plagairism.
If I’m writing an article that talks about the benefits of giving iPads to in-coming freshman, and I’m interested in knowing the retention rate for these students, I’m not going to build the research study and track all the students through their four years of undergrad myself! I’m going to find other people who did this and reference their published results in my work. I can understand the implications and use the results from the study without having to conduct it myself. I may have the competence, but I don’t have the resources or the time!
3. Write to solve a problem.
Think about most of the activities you perform every day. You don’t do them just for the sake of doing them. I don’t drive my car around just for sole purpose of navigating 3000 pounds of metal. I drive my car so I can pick up eggs at the grocery store or get to campus to take a class. In that same vein, it’s silly (and probably not very effective) to learn code just for the sake of generating code and learning a new programming language. What are you going to do with it?
Jeff Attwood wrote a really interesting post several years ago called “Can Your Team Pass the Elevator Test,” which talks about the importance of making sure development teams understand why they are programming:
Software developers think their job is writing code. But it’s not. Their job is to solve the customer’s problem. Sure, our preferred medium for solving problems is software, and that does involve writing code. But let’s keep this squarely in context: writing code is something you have to do to deliver a solution. It is not an end in and of itself.
Finding a problem to solve provides you with purpose (as well as motivation) for both coding and writing.
In writing, we call this sense of urgency or need to solve a problem exigency. When I’m helping my composition students define a focus for their final papers, I always ask them: What issue are you trying to bring to light? What problem are you trying to address? What situation are you trying to fix? What question are you trying to answer, and why does this matter?
I know from personal experience that unless I find a good reason to write, I’ll struggle through the entire process and the end result will be flat and uninteresting.
Come back tomorrow for Part 2 of this post.