The meeting started with introductions, which gave the membership an opportunity to share our goals for the group while also learning about common problems and frustrations that people have encountered while learning to code. The group came together over shared concerns and frustrations ranging from getting stuck on problems that can’t be solved alone to finding the lessons too dry when there is no real life application. Members also discussed the sense of frustration that comes from knowing that you need to know more about computer programming to keep up-to-date and simultaneously feeling guilty about time spent on computer programming lessons that aren’t directly related to a specific job duty.

Participants discussed techniques that they found helpful in teaching themselves to program, including:

reviewing lesson walkthroughs or keys (though some avoid this because it feels like “cheating”),

working through the problem with another student/mentor,

setting aside an allotted time daily or weekly to practice coding skills,

saving up multiple lessons or projects to work through in a single day of non-stop coding, and

finding code online that you can learn from and adapt for your own purposes.

These suggestions highlighted the importance of learning style and schedule flexibility when it comes to successfully teaching oneself to program. Just as importantly, the conversation showed that for most participants, committing to a long-term practice of regularly using these skills was key to success. This discussion provided an excellent foundation for the topics covered in the rest of the meeting.

The second portion of the meeting was devoted to lightning talks. Eric Phetteplace offered an introduction to bookmarklets. These relatively simple programs can be created with just a small amount of Javascript and can allow users to exert a powerful effect on websites through their browser. Bookmarklets run the gamut from the fun, such as Kick Ass, a bookmarklet which allows you to play Asteroids on any website, to Instapaper, which allows you to save and reformat webpages for future reading. Eric discussed some of the possible uses for libraries, including data harvesting or adding proxy server information to all links on a page. Any data on the web page can be accessed and changed with a simple script.

For those inspired to get started writing their own bookmarklets, Eric also provided concrete information on how to get started. He advocates using a template found online, echoing the meeting’s recurring theme that coders, particularly beginners, shouldn’t feel the need to reinvent the wheel for every project. Instead, finding templates online that can be adapted for your purposes is often a much more efficient way to start a project and a great way to learn from the work that other coders have already done. Eric also discussed tricks and tips for bookmarklets, such as having the bookmarklet point to code hosted elsewhere for easy updates, the importance of not making assumptions about the types of websites on which the bookmarklet will be used and the difficulty (to the point of virtual impossibility) of using bookmarklets on mobile browsers.

I gave the second lightning talk, which covered resources that can be used for learning or teaching programming. As was evident from our introductions, members of the group have a wide range of different interests and approaches to learning. While Code Year has worked for some people who want to learn more about Javascript, JQuery and web programming, my talk highlighted other tools that can be used to learn Python, Ruby, Java and other languages through tutorials, videos and exercises. I also discussed options for finding in-person programming classes locally for those who prefer to work with a group in person. Those interested in finding these alternative tools can refer to the handout I prepared for this talk or to my Pearltree on the topic.

The final, and arguably most important, agenda item for the meeting was discussing plans for the future. The group brainstormed and settled on focusing our efforts on a number of different types of how-to projects including:

A collection of resources to support those who want to host a Hackathon.

You can see the full list of volunteers for these projects on our ALA Connect space, but we are definitely looking for more helpers for these and other projects, so let us know if you want to help out! We also hope to maintain a list of members’ areas of expertise to facilitate helping each other out. If you want to coordinate this project, or if you would just like to be included on the list, add a comment on our ALA Connect space.

This first meeting is just the first step in what we hope will be a long history for this interest group. Even if you weren’t able to attend the meeting, we want you to be able to get as much as possible out of our activities. Be sure to stay in touch and please think about getting involved with us!

About Our Guest Author: Carli Spina is the Emerging Technologies and Research Librarian at the Harvard Law School Library. She has an MSLIS from Simmons College and a JD from the University of Chicago Law School and she is one of the co-chairs of the LITA/ALCTS Library Code Year Interest Group. Her interests include emerging technologies, innovation in libraries and coding. She can be found on Twitter@CarliSpina.

You may have seen people posting that they are learning to code with CodeYear, mentioned in our earlier blog post “Tips for Everyone Doing the #codeyear”. While CodeYear and Codecademy are not the first sites to teach programming, CodeYear has seen quite a bit of marketing and notice, especially in the library world (#libcodeyear and #catcode).

Many find themselves, however, in a familiar situation when dealing with learning to code. And it starts with the person saying or thinking “I want to learn to code, but…

Do you fall under any of these categories?

1. “I don’t have enough time to learn coding.”

You can work through the time issue in two ways. The first way is block off time. You have to look at your schedule and decide, for example, “ok, I’m working on my coding lesson between 1 to 2pm.” Once you made that decision, tell the rest of the world, so that they know that you’re working on learning something during that time.

For some folks, though, blocking off an hour may be impossible due to disruptions from work or personal life. When you’re in a situation where frequent disruptions are a fact of life, documentation is your friend. Keep notes of what you learned, what questions you have, what issues you ran across, and so on – this will make sure that you do not end up having to repeat a lesson, or losing track of your thoughts during a lesson.

2. “This is too hard.”

Here I must stress one of the key survival traits for people learning to code: ask questions! Find people who are taking the same lesson and ask. Find coders and ask. Find an online forum and ask. Post your question on Twitter, Facebook, blog, or any other broadcasting medium. Just ASK.

More often than not your question will be answered, or you will be pointed in the right direction in answering your question. The overused saying “there is no such thing as a stupid question” applies here. Coding is a community activity, and it’s to your benefit to approach it as such.

3. “I don’t like the tutorial/course.”

It’s OK to say “hey, this course isn’t what I thought it would be” or “hey, I’m not finding this course useful.” Ask yourself, “in which environment do I feel like I learn the most?” Is it a physical classroom? A virtual classroom? Do you like learning on your own? With a small group of friends? With a large group? There are various formats and venues where you can find courses in coding, from credit-earning classes to how-to books. For example, the Catcode wiki lists a variety of coding lessons or learning opportunities at various levels of coding knowledge. Choose the one (or a few) that will fit best with you, and go for it. It might take a few tries, but you will find something that works for you.

So, if you find yourself saying “I want to learn code, but…,” there is hope for you yet.

Find what’s holding you back, tackle it, and work out a possible solution. If you don’t get it the first time, that’s OK. It’s OK to fail, as long as you learn and understand why it failed, and apply what you learned in future endeavors. For now, we are stuck in learning coding the hard way: practice, practice, practice.

Learning code the hard way, on the other hand, is not too hard once you have taken the first few steps.

If you are a librarian interested in learning how to code, 2012 is a perfect year for you to start the project. Thanks to CodeAcademy (http://codeacademy.com), free JavaScript lessons are provided every week at http://codeyear.com/. The lessons are interactive and geared towards beginners. So even if you do not have any previous experience in programming, you will be able to pick up the new skill soon enough as long as you are patient and willing to spend time on mastering each lesson every week.

A great thing about this learn-how-to-program project, called #codeyear in Twitter (#libcodeyear and #catcode in the library-land) is that there are +375,443 people (and counting up) out there who are doing exactly the same lessons as you are. The greatest thing about this #libcodeyear / #catcode project is that librarians have organized themselves around this project for the collective learning experience. How librarian-like, don’t you think?

Now, if you are ready to dive in, here are some useful resources. And after these Resources, I will tell you a little bit more about how to best ask help about your codes when they are not working for you.

Resources for Collective Learning

CodeYear Group in ALAConnecthttp://connect.ala.org/codeyear
//Meet other librarians who are also doing the #codeyear project, ask questions, rant out your frustration, find support from your peers.

CatCode IRChttp://webchat.freenode.net/, and enter the channel name #catcode
//#catcode folks also set up an IRC channel for real-time chat. It is a nerdier version of group chat (e.g. Meebo, MSN, etc.) Read IRC info here at Code4Lib wiki (http://code4lib.org/irc/faq) but remember the channel name is #catcode instead of #code4lib.

Now what I really like about #codeyear lessons so far is that some of the lessons trip you by trivial things like a typo! So you need to find a typo and fix it to pass a certain lesson. Now you may ask “How the hell does fixing a typo count as a programming lesson?”

Let me tell you. Finding a typo is no triviality in coding. Catching a similar syntax error will save you from the most frustrating experience in coding.

The examples of seemingly innocuous syntax errors are:

var myFunction = funtction (){blah, blah, blah … };

var myNewFunction = function (]{blah, blah, blah … };

for(i=0, i<10, i++;)

var substr=’Hello World’; alert(subst);

–//This is my first JavaScript

Can you figure out why these lines would not work? Give it a try! You won’t be sorry. Post your answers in the comments section.

How to Ask Help about Your Codes

by Matteo De Felice in Flickr (http://farm4.staticflickr.com/3577/3502347936_43b5e2a886.jpg)

I am assuming that as #codeyear, #catcode, #libcodeyear project progresses, more people are going to ask questions about problems that stump them. Some lessons already have Q&A in the CodeAcademy site. So check those out. Reading through others’ questions will give valuable insight to how codes work and where they can easily trip you.

That having been said, you may want to ask questions to the places mentioned in the Resources section above. If you do, it’s a good idea to follow some rules. This will make your question more likely to be looked at by others and way more likely to be answered correctly.

Before asking a question, try to research yourself. Google the question, check out the Q&A section in the CodeAcademy website, check out other online tutorials about JS (see below for some of the recommended ones).

If this fails, do the following:

Specify your problem clearly.
(Don’t say things like “I don’t get lesson 3.5.” or “JavaScript function is too hard,” unless the purpose is just to rant.)

Provide your codes with any parts/details that are related to the lines with a problem.
(Bear in mind that you might think there is a problem in line 10 but the problem may lie in line 1, which you are not looking.) Highlight/color code the line you are having a problem. Make it easy for others to immediately see the problematic part.

Describe what you have done to troubleshoot this (even if it didn’t work.)
: This helps the possible commenter to know what your reasoning is behind your codes and what solutions you have already tried, thereby saving their time. So this will make it more likely that someone will actually help you. To believe it or not, what seems completely obvious and clear to you can be completely alien and unfathomable to others.

Some JavaScript Resources

There are many resources that will facilitate your learning JavaScript. In addition to the lessons provided by CodeAcademy, you may also find these other tutorials helpful to get a quick overview of JavaScript syntax, usage, functions, etc. From my experience, I know that I get a better understanding when I review the same subject from more than one resource.

If you have other favorite Javascript please share in the comment section.

ACRL TechConnect blog will continue to cover #libcodeyear / #catcode related topics throughout the year! The post up next will tell you all about some of the excuses people deploy to postpone learning how to code and what might break the mental blockage!