Thursday, November 22, 2012

Should you learn to code?

2:04 AM No comments

Thumbnail I earned my BFA in ’98. Learned to layout feature pages and create infographics for the local daily paper. I earned a Photoshop ACE in ’03. My most recent full-time contract was pure mock-up design work.

Yet for the last year and a half I have debugged code 40–50 hours a week. I read about code, I wrote about code, I talked to other people about code. Imagine that: a non-coder figured it out.

Still, “write code” is a broad phrase. Some languages are easier than others. Some languages require an understanding of how software “talks” to the computer. The most important part of learning code is keeping the correct mindset. It’s not telling yourself “I can do this” or hunting for the right books.

Here’s how it works.

Hold it — should you learn to code?

Literacy in any computer language, from simple HTML to complex C++, requires dedication not only to the technology, but to changes in the technology. There’s a reason HTML5 ends in a number. When enough browsers support HTML6, developers will have new things to learn.

Possible reasons to put yourself through the learning process include:

To gain confidence: I’ve had rare clients who think that if they master a language then computers will intimidate them less. While that may be the case, it rarely sticks without dedicated practice.
Necessity: technical problems will arise whether or not one’s job description fits the bill. When problems must get solved, there’s a time to pass the buck and a time to buckle down and solve it.
The thrill of it: some people just like to learn new skills.
To understand what’s possible: a developer says “it can’t be done.” Do they mean it’s impossible? Or that it’s more trouble than it’s worth? A designer says “I want it to do this.” Did he or she just give someone a week’s worth of headaches? Can technology be used in a more appropriate way?

Stay curious

I’ve seen it. You know, that look. Not quite panic, not quite despair. It’s the look someone gets when they realize the appeal of letting someone else do the heavy lifting. The look that says, “That’s a windshield; I don’t have to be the bug.” I’ve seen it in co-workers’ eyes, students’ postures, and staring back from the mirror.

In my experience, it isn’t fear of failure that intimidates people. It’s fear of getting lost. Overwhelming hopelessness encourages feelings of inadequacy. That cycle will beat anyone down.

Courage or persistence are not antidotes for feeling overwhelmed. Stopping before feeling overwhelmed is the solution.

Pressure image via Shutterstock.

My favorite technique is to tackle a project with three traits.

Deadlines and paychecks are fine. But nothing drives people like an itch they can’t scratch. In the long run, learning code must not be an end in itself. It must become a salve for some irritation.

Way back when, I got frustrated that I couldn’t find a good book. There’s no shortage of book discovery websites, but intuition told me there was a better way. So I started my own website. I never finished the project, but I learned many ways to organize novels. On the way, almost incidentally, I learned more code.

Having found that proverbial itch, people learning to code should also find relief.

No tutorials, tools, or outside praise will give people the mindset to conquer code better than “I wrote this and… look what I did!” and leaving with a sense of being greater than the obstacle you overcame.

It sounds silly until you try it. Seeing code perform gives people a micro-rush of self confidence, a validation that they can master the machine.

Code image via Shutterstock.

Last week someone looked at my screen and shook his head. It was full of code. Three open windows of colored tags and function calls. He said: “I could never do that.” Years ago I would have agreed. I didn’t want to look stupid or break something that I could not fix. Who knows what damage one wrong keystroke would cause?

This one’s critical. When learning something that intimidates you, you must approach but do not exceed your limit.

“Exercising your brain” isn’t an appropriate analogy. When working out, trainers encourage people to push just past their limits. But learning is a hunger. Your brain has an appetite for knowledge. Filling your brain to the brim (or worse, exceeding its limit) will hamper your ability to learn, erode your self-confidence, and kill a kitten. Please, think of the kittens.

Better yet, think of mental exercise as one workout that happens to last a while. Say, one week. Sure, you take breaks between reps (called “getting sleep”). But rushing ahead works against your goal. The kittens will never forgive you.

Part one: warm up by mixing something you already learned with something you don’t know. Leave yourself at least one question. 1 day.
Part two: practice. Experiment. Practice repeating experiments. And always end on a cliffhanger. The goal is to hit your stride and break on a high note. By “break” I mean sleep, eat, or talk to fellow humans. 3 days.
Part 3: cool down by improving what you’ve already covered. As always, get your brain to a point of enjoying the exercise, then let go for a while. 1 day.

Sprinting does not train you for a marathon. A hundred pushups will improve your shoulders better than trying to lift a truck once. And cramming tutorial books like shots of tequila will impair your ability to think.

Practice daily

In my newspaper days, I refused to use stock art. Deadlines came five days a week, but I insisted on hand-crafting my own vector art. Six months later I was the go-to guy for any custom graphic work. That one skill that earned me a senior position at a startup company. Even today I love fiddling with bezier paths.

Learning any skill, including how to debug code, works much the same.

The only way to learn code — and make it stick — is to practice every day. Like learning any new skill, a consistent schedule with manageable goals gradually improves performance to the point of expertise.

“I can” is not “I should”

Part of learning to read and write code, be it HTML, jQuery, or C++, is learning one’s limits. Another part is explaining one’s limits. The curse of understanding a language … rather, the curse of people thinking you “know code” is they’ll expect you to do it.

Code image via Shutterstock.

HTML is not CSS. CSS is not PHP. PHP is not WordPress. WordPress is not server administration. Server administration is not fixing people’s clogged Outlook inboxes. Yet I’ve been asked to do all of that. Me, armed with my expired Photoshop certificate and the phrase “I don’t know, but maybe I can help….”

Those without code experience often don’t differentiate between one $(fog-of).squiggles+and+acronyms; or <another/>. Not that we can blame them. Remember what it was like before you threw yourself into learning by