my little crush

Okay, I said it’s a little crush, but really – it’s a big crush. A big crush on a little startup called Codecademy.com. They don’t know I have this crush—I’m just a stalker.

Codecademy is teaching people to code via a highly interactive website (check them out if you haven’t). I could babble for hours about how the concept is brilliant, and how everything going on at the site is fantastic. But I do not just love the concept, I love the way they are developing their product. I want to talk about two things the Codecademy guys added to the site that I’m excited about.

The scratch pad (and labs)

I have a huge passion for education. I love teaching people about computers and how to program. Codecademy cleared away a big bottleneck I encounter every time I try to teach someone to code—getting started.

Normally you have to install development environments, set up environment variables, download APIs… I have a degree in computer science and it overwhelms me. Codecademy gets rid of all of that and just gets you started. It allows a student to feel successful right away, and to see that programming is approachable and a lot of fun.

But I started to worry –people make it through the lessons this way… but how do they practice? What happens when they get excited and want to try something on their own? All of those things that were barriers to entry might crop back up as barriers again. Enter scratch pad and labs. These two features of the site allow you to program just like you do in the lessons – no installation, no upkeep, no barriers.

Scratch pad allows you to switch from learning mode to practice mode. It shows a text editor and a console. Scratchpad solves the concerns about the new user being able to practice. It works particularly well with scripting languages, but I think with templates and guides new users will be able to practice languages that require a little more groundwork too. It provides the springboard for more features than the Codecademy team could build (saving/loading scratches, case studies/samples, templates…). And best of all, any of these features are perfectly in line with natural growth within the vision for social, online, self-paced learning of software development.

But this functionality is more versatile than just removing barriers to entry. I imagine myself, a programmer, using it when I want to try a new language and don’t want to figure out the crap associated with getting it up and running. Or when I’m on a computer I haven’t set up and want to quickly write or edit something. I can imagine plenty of uses for online development environments – but the users are not beginner programmers. I love that Labs is a separate part of the site from ScratchPad, arguably a different product, because the users are very different. Labs FAQ.

Code year

This one made me giddy. It is so clever some people might think it’s not clever at all.

It’s easy to see that an education site should and will let you “enroll” in a class. Users (including me) were probably asking for this. I’d go to the site, do a ton of lessons then walk away and stay away just because there was nothing bringing me back. Spam is an easy fix, and enrollment in a class is an easy metaphor.

Here is where the brilliance begins though. Enrollment implies commitment; it’s heavy and certainly hard to associate with fun. CodeAcademy is trying (at this stage) to grab a bunch of people on the Internet who want to learn to code and shoehorn a social aspect to it.  Fun and learning have to be the incentive and so words like “enrollment” and “commitment” are dangerous. So don’t enroll, make a New Year's resolution at CodeYear.com

The New Year's resolution has such a strong place in our culture and it’s the perfect thing to leverage here. It’s something we choose to do because we want it and because it will make us better people. It’s something that’s a little bit difficult/outside our comfort zone but that we feel is probably attainable.

The New Year's resolution allows people to “enroll” while feeling like they are in control of their learning (not something generally associated with enrollment), a serious goal of self-paced learning. A resolution captures that this is something done over time but that is completely possible, and therefore what might be “spam” is actually Codecademy supporting you in reaching your goals. Sharing your resolution with your friends helps with accountability and is a natural thing to do. Plus there is strength in numbers; friends that resolve together are more successful. Finally, just like a New Year's resolution, don’t feel like this is anything too formal, all you gave was your email address.

I could go on and on about how fantastic it was for them to choose this metaphor. It was simply brilliant.

Ideas for next CodeYear

The CodeYear.com site bothers me a bit. I think it might hinder the actual goals of the program. Part of what makes this resolution so great is knowing how great the CodeAcademy program is. Knowing that it is fun, low impact, high-reward is really important. Users that encountered CodeYear without knowing CodeAcademy have missed that, and might be more wary of the commitment, or feel less like they will be successful, etc… It might be helpful to tie CodeYear more closely to Codecademy.

Also, the overall design just seems a little text heavy to me, and a little less fun than a New Year's resolution should be. However, code is text heavy, so I’m not sure how much could be done (its easy to criticize). I understand that this was put together rather quickly.

Falling back to the resolution metaphor I’d be interested to think about how to use their rewards system and leverage the social networking to get people excited about keeping up with their resolutions. Coming from the “lose 10 pounds” resolution, staying excited is definitely the hardest part!

Going forward

I think Codecademy have a great concept and are making great decisions. I think as their product grows there are some things I would focus on because they are really exciting. That being said, I ever meet these guys I won’t be able to eat around them and will say dumb things. That’s how it is.

[caption id="attachment_62" align="alignright" width="300" caption="Screenshot of the Hitchhiker's Game"][/caption]

Self-paced learning
Having taken quite a few “self-paced” courses myself, I don’t think anyone does it right. Codecademy is definitely getting closer because of its high level of interactivity (its awesome, it’s the hitchhikers game for learning to code). I think their ability to leverage the social aspect of their product (which is currently not as developed) is going to be key. Sometimes we need help from other people.

Self-paced can’t be totally self-paced, as I gushed before in my CodeYear discussion, users need a little push. Keeping CA “enrollment” fresh and fun is going to be a challenge going forward but I think they’ve tapped into some really great ideas for solving this problem (rethinking traditional enrollment, social, competition, etc).

Codecademy sets itself apart from other online courses by leveraging “learning by doing” really very well. I would focus on doing because it keeps things fun and engaging. Programming projects are a great way to practice and get beyond the lessons and really write code. After that I think focusing on supporting students get to work on building “real” things will be key.

Social
I touched on some of this above, but I think the social experience is one of the most confusing parts of the site. The social aspects feel forced, and tacked on. Sure I can let everyone know what I’m doing but how am I interacting with other students. Code development has a long and established history of being social on the web (the entire open source community). Learning has always been a social activity. The social aspects of Codecademy becoming a more integrated part of the experience could take it to the next level.

In college one of our assignments was to work together to program “critters” which “fought” each other. There was no hardware, and battles projected on a screen during a pizza party. Something like this could be a way to actually bring your friends into the Codecademy experience. Have your friends help you write code, pit your code against theirs, and shared timelines and incentives. The experience has goals beyond simply learning.

[caption id="attachment_60" align="aligncenter" width="428" caption="My first semester programming class."][/caption]

I could keep going but at some point I'm in danger of a restraining order.

XOXO Codecademy, Love you.

process process process

[caption id="attachment_44" align="alignleft" width="176" caption="Me and a rig, small town TX"][/caption]

First and foremost I’d like to take a moment to give a shout out to software development in the oil industry. Having worked there for a good chunk of my career I can tell you from experience it gets a bad wrap. I did some awesome work there with awesome people. Plus, these guys know how to do process, methodologies, and chain of command. I cannot be thankful enough for learning enterprise development in that environment because loosening up on the process is easy but learning and appreciating it can be hard.

So I wanted to take a moment to do some appreciating. When I talk about “process” what I mean is just about anything project management related—really the software/project development methodologies: waterfall, agile, modified waterfall, scrum, RUP, and many more. But process has a place beyond project management and there are things that are not overarching methodologies that I want to give a little appreciation to as well– code management practices, issue tracking schemes, and even meeting requests.

Many people are afraid that formal processes for software development (or really anything) lead to inefficiencies and are too often more trouble then they’re worth. You spend a whole bunch of time writing documents, sitting in meetings, filling out forms, doing things that aren’t accomplishing your job, wasting time. I hear you, and sometimes that's true, but you get things in return.

Respect

I mention earlier about meeting requests. This "process" seems small and silly, but I worked in places with meeting requests as the standard for scheduling and at a place where it was not the standard. There is something about letting someone “accept” a "request" and having to look at their calendar before dragging them into something that conveys a higher level of respect for their time than just shooting them an email or interrupting everyone with a “let’s all meet in the conference room.”

Just about any process can have this effect. When methodologies formalize interaction they can keep people from getting too focused on what they want out of a given situation and forgetting to respect the other people’s time, contribution, perspectives etc. This can be especially problematic if you have some dominant personalities. Having a formalized reminder of the importance and value of the other roles/teams/people is awesome.

Keep the train moving

When you work with really smart people, who have different goals: developers, project managers, sales guys, testing, etc… you’ll run into conflict. Not petty bickering, but really important discussions where smart people have differences of opinion. Good process can provide both a formalized way to “pick your battles” and a safety net for when you hit a good old fashion Mexican standoff. Sometimes you just have to keep moving because there isn’t always a best solution, but as long as you can find a great solution, things will be okay. Back to respect, process can be the enemy instead of the enemy being each other and that can be priceless for coworker harmony.

Communication

A good set of methods can help everyone stay on the same page. Whether it’s a bug report, a business requirement, a feature, an incentive… it helps to formally define the language we use to speak, and break up things into manageable bite size pieces.

This means that you can minimize the different lingo that various teams use to discuss the same things – which will improve and increase communication among teams/people –always a good thing.

It’s easier to bring problems and concerns to each other when when everyone knows what you're talking about. People have more meaningful, useful and satisfying discussions when you can get right down to it. You’re more likely to ask “a quick question,” of your business team, or run this feature by your usability guru, if you have don’t have to say… uhh so I’m uh working on this part of this thing, oh wait let me explain. Hrm.

But process is inefficient?!

[caption id="attachment_46" align="alignleft" width="198" caption="Famous tire swing cartoons..."][/caption]

I think the best response to that argument is that no process is inefficient too – no bug formal bug tracking system can lead to a bug slipping through the cracks and costing more later, possibly more than the entire cost of the tracking system. I use that particular example because I think most developers buy into the need for a bug tracking system – but the same holds true for a lot of other processes as well, including the heavier software methodologies. If you miss a business critical requirement, or overlook a development risk, these oversights can easily cost more than an entire development process worth of meetings, documents, etc.

It works if you work it … and if it works for you

These practices work because people commit to them, use them, and derive value from them. If any of that falls apart, then they aren’t working anymore.

If there are some people who aren’t participating or have a bad attitude, find out why. If the approach isn’t perceived as valuable by the team using it then something has to change. If it’s too heavy for a particular group – make it lighter. If there is something people are doing that isn’t useful to anyone, stop doing it. If you keep running into the same problems, arguments, pitfalls, then take a minute and try to design a process solution to prevent it. Get the group involved and make a change.

I think that the development and mutation of the process has to be a group democratic effort because it only works if everyone works with it—but when starting it’s a great idea to pick up a book or an article and work from a formal method. It’s easier to adjust it later, to make things more lightweight. Sometimes it can be hard to see what you need even but its often easy to see what you don’t.

The most important thing I’ve learned about working a bunch of different places with a bunch of different people is that there is no right process for everyone and the best processes are the ones everyone agrees to follow. The respect I was talking about earlier doesn’t just come magically from the process it comes from people respecting each other enough to use the process, whatever it may be.