The latest Crome Canary comes with a few minor tweaks to search interface. The missing search bar being the most notable.

The most interesting thing for me is the search menu (Web, Images, Maps, and eventually, More). It’s interesting because there’s room on that bar to fit more (between “Search tools” and the gear icon way over to the right) , but Google has opted for sparseness and hidden all the rest in a menu item.

There’s so much room for less in everything we design. Let’s avail of it.

You sign up for Codecademy. You spend 3 months deciding between Python and Ruby, because you heard Django was more powerful or something but Rails had better community support or something. You in fact have no idea what that means. You maybe do a tutorial or two. Oh wait, I should be learning Node.js. It’s the future. Then… hey what’s that shiny thing over there?

—Jake Levine

Boy-o-boy does this ever ring true. My experience was precisely like that—learning to code is simply that—learning to code. Until you actually learn to build something, you’ll never get anywhere. I went from Ruby to Python to Javascript back to Ruby back to Javascript—it never ended.

But I remember the moment when some of it finally clicked: I was learning PHP a few years back, I kept falling asleep during the Lynda.com videos, so I bought a book. The book put me to sleep too. I followed tutorials that mostly didn’t work or were outdated, and tried everything else out there to help beat it into my head.

One day, I was trying to dynamically create a menu in WordPress using a query—I had to create a function to get the page id, hand that off to another function to get that page’s children, and then to another to get the last item in an array to determine the page’s ancestors. It was all there—strings, numbers, arrays, functions, passing values around. No doubt it was a Frankenstein of code, but it worked, and did it ever feel good!

Until you actually start making something, you’re just going through the motions—you’re not learning.

I just wanted to keep track of my progress as I went along. Thus:

Week 1:

• They said it would be hellish. They didn’t lie. Remapping your brain after so long is extremely slow and frustrating. Having said that…
• In just over a week, here I am typing this email. I’m not fast, but it’s still cool.
• The Dvorak layout is exponentially better than QWERTY. Of course it should be, but I never expected such a difference. There’s just so much less travelling for your fingers to do
• Dvorak+Cmd is actually the layout you want to try (instead of straight Dvorak). This allows the cmd key to override Dvorak and switch back to QWERTY while pressed, thus preserving your common left-hand keystrokes (copy, paste, close, etc)
• For it to work at all, you need to really to 100% switch. I haven’t gone back to QWERTY since last week. It’s been an epic pain, but I’m already way better because of it
• Typing is one thing, coding is quite another. Re-learning to type PHP, CSS, HTML and dozens of terminal commands is extremely hard on your head (I type the word ‘git’ dozens and dozens of times every day, but I just can’t seem to get the pattern to sink in!)

And that’s it for week one!

Week 2:

Things are slowly getting better. And I mean slowly. Here’s the take-aways from week 2:

• I hadn’t realized how much of the keyboard layout I had stored in my muscle memory (as opposed to my actual memory). Turns out that it’s a lot. I start almost from scratch every morning until I type a few lines and remind my muscles what we’re doing. Hence….
• Start each day with by typing a few “quick” paragraphs
• Writing code is absolutely brutal. Writing <?php if () {}; ?> still takes extreme concentration
• Using the terminal is just as brutal—cd, mv, mkdir, ls, ls-la, git, etc—I was so quick with these before, they’re all very difficult to remap in my head
• Overall, it is getting slowly getting better — it feels a little like learning Ruby after only knowing PHP. The syntax is so short and readable. Still completely foreign at first, but it just feels like it’s going to better in the long-run
• I can definitely tell that the layout is 100% better. Your fingers travel way less.  But I’m far from experiencing any ergonomic benefit—typing this slowly means that you’ll have your hands and wrists in typing mode all the time, which gets tiring quickly
• Last: I hope my backspace key is good and strong! I hit it at least every third letter!

Anyway, Tom MacWright recently tweeted a link to these fantastic slides from Max Ogden (you can watch the video too). You know, Max Ogden the Javascript for Cats guy. He brings up dozens of well thought out points, but I want to pull out just a few of the first ones:

1. We need better introductory materials [for teaching JS]
2. the better you get, the worse you get at teaching
3. people are going nuts over programming education

Let’s start at the end—that one is very hard to refute. The world (that I live in) is basically going nuts over programming education. There are dozens of very good sites to go learn about programming specifically, and Computer Science in general. Codecademy, Codeschool, Hacker School, The Starter League, open courses from Stanford and MIT, Udacity, and many, many more. Here’s 25 brand new options for you. The choice is paralyzing.

That dilemma of choice, leads us to item #2 above: “the better you get…the worse you get” idea. I couldn’t agree more with this one. Just go have a look at jQuery in Action for a perfect example of this. The authors certainly mean well, but the book is so needlessly dense and technical (at least for me) that I found myself quickly turned off. This problem isn’t pervasive or all that limiting, however. There are still lots of amazing teachers out there—Jeffrey Way for example, is as good a teacher as you’ll find anywhere.

So far then, our greatest issues are the overabundant choice of resources, and teachers who have lost touch with their beginner roots. But again, given the variety out there, these are fairly minor issues. What about #1? Do we need better introductory materials? I certainly don’t think so. JS for Cats is superb, jQuery Fundamentals is excellent, as is 30 Days to jQuery, Lynda.com has great stuff, Codecademy and Codeschool are both great, and then there’s the mountain of good books out there. There are many, many, many fantastic places for beginners to learn the basics of both Javascript and jQuery. Within a few weeks of moderate effort, you can learn all kinds about the basics of Javascript and move your way up to doing pretty cool interaction-y things with jQuery. The main things you’ll cover in all the basic Javscript courses are right here (pretty much):

// Basic stuff
var myStringVariable = "I am a string!";
var myNumberVariable = 5;
var combined = "Strings and numbers like " + myNumberVariable + " can coexist! "

// Arrays
var animals = [ 'cat', 'dog', 'sheep', 'cow' ];
console.log(animals[0]);

// Loops
for ( i=0; i < animals.length; i++ ){
	console.log("I love my pet " + animals[i]);
}

// Objects
var cat = {
	name: "Harold",
	favouriteFood: "bacon",
	favouriteSleepSpot: 'couch'
};

console.log("The name of my cat is " + cat.name)

// Logic

if( cat.name === "Harold" ){
	console.log("That sure is a great name for a cat!")
}

// Functions
var area = function(length, width){
	return length * width;
}

// And last, the holy grail for basics: mixing objects and functions
var cat = {
	name: "Harold",
	favouriteFood: "bacon",
	favouriteSleepSpot: 'couch',
	weight: function(pounds){
		console.log("Your cat is called " + name + ". And he weighs " + weight + )
	}
};

This isn’t everything—by a long shot— but there’s a lot of basics in there. And once you’ve gotten all of these, you’re well on your way to Javascript zen (right?). Not so fast.

So what is the problem with learning Javascript then?

The trouble I keep running into, is moving from all this basic stuff to that "next level." I feel like I've come a good ways with the basics—though it's all fairly unimpressive stuff, I wrote all that sample code above, without any examples to go by, and I definitely could not have done that last month. But I'm finding that I just can't make that next step. It feels like all the gold these days is in ajax, JSON, and APIs, but I just find much of that stuff to be over my head right now. I've spent a fair amount of time studying the fundamentals, and I think that with practice, things like arrays and objects and loops will all become second nature. But at this stage, I really don't know how I'm going to get from here to where I want to be.

A bridge too far

The trouble with progressing with your Javascript knowledge is that there's no bridge between the fundamentals and the gold. The internet that I live on is certifiably obsessed with this gold—APIs, open data, Node.js, Backbone, and the 75,000 Backbone alternatives—but I've found it almost impossible to sort out how to get started with any of them. I still dont' actually know what Node is/does, I can't figure out why/when/where you'd need something like Backbone, and every single API I've looked at has its own domain-specific quirks. To top off the issues with APIs, they change so fast. A Twitter API tutorial from 2 or 3 years ago is almost useless now, for example.

As for Backbone, I came across a fantastic piece of evidence to support my theories the other day.  This tutorial from Ramakrishna Nadella wants go step by step from jQuery to Backbone—it seemed perfect for me! Let's just say that it wasn't. I was lost from the very first code example—well before he began talking about "separating DOM and Ajax (whatever that means).

Where next?

Speaking of Tom MacWright, I was looking at his dc-government repo the other day, and was really interested in what I saw on first glance. It looked like he was connecting some simple json data with an equally simple html page. I thought, "Hey! This is a perfect place to start!"  I thought I'd be able to figure out how to gather up some of my own data, do some of my fancy Javascripting on it, and append it to my own magical web page somehow. Spoiler: I couldn't.

But I think something like this is a perfect place to start on what I'll call Generation II Javascript Learning. A course centered around this kind of project would be absolutely perfect for me at this stage. I've been playing with jQuery for a few years (and know it reasonably well), and now I have a fairly good grasp of Javascript basics.  Basically, something in the middle of jQuery and Node/Backbone is what I'm looking for, and I've found very little. I'd love it if I could come across a site or program that looked something like this:

Generation II Javascript Learning (for Intermediates)

1. Basics — what you should know (Javascript and  jQuery basics)
2. $.ajax — Ajax is always an add-on chapter in jQuery books. It shouldn't be.
3. $.each — Loops are covered in great detail in beginners guides, but $.each is never covered. It's very important when dealing with #4 below.
4. JSON — creating it, accessing it, looping through it, filtering what you find
5. APIs — Just focus on GET requests from one single API. Pick Facebook or Twitter or Flickr or something, and focus on it. No POSTs, just GET. POST involves a whole pile of other stuff that you don't need at this stage. Just focus on the easier part (GET) and build from there.
6. Project A — Build a tweet-fetcher or a Flickr picture getter, or something like that using a well-established API. STEP BY STEP.
7. Project B — Build an interface that does something with an actual json data source. IE: Read from a json file into variables, do calculations and fancy things with those variables, and append the results to a web page.  Perhaps a Dashboard of some kind that reads static json data, does some calculations, builds some charts, etc

In conclusion

This has been long enough. Let's quickly summarize:

1. There's an enormous wealth of materials out there for beginners. Enormous. Choice is both a blessing and a curse here, but if you're just starting out, it's a blessing. If one site isn't keeping you interested, try another. 
2. There's little out there to help bridge people from Beginner to Intermediate level. I'm not saying that it isn't hard work, I'm suggesting that there's way more material out there for beginners than for people who know the basics.
3. Learning Ajax is more difficult than it should be, and learning about JSON and APIs is still completely wild-west. The info that currently exists is mostly for people who already know this stuff, not for beginners.
4. It would help if learning materials defined this new audience and marketed to them. Learning about Ajax and JSON in the same detail as in beginner courses would be amazing.

I'd love to other beginners' thoughts on this, as well as from more seasoned Javascript developers  How did you get over the hump? Maybe I'm the only one finding myself stuck in these predictable ruts with learning Javascript. Maybe. But I doubt it.I don't have comments here because...well...you know...but please send me a reply on Twitter.

Great story on Google’s evolving design language and the team behind it. We all benefit from better design. theverge.com/2013/1/24/3904…

— Doug Bowman (@stop) January 24, 2013

The last line of this tweet hit me right in the face today. We all benefit from better design.

I guess I’ve never really thought about it before, but “modern design” or a “modern aesthetic” is like a fluid, always-moving glacier. New stuff and old stuff constantly grind against it, and somewhere in the middle there’s a loose convergence of colour, style, shape, feeling, experience.

What I like most about it is that it enables us to imagine a modern aesthetic. I know that that isn’t an actual thing that you can point to or print off, and you’d probably never get two people to agree on it, but it does provide some weight to your opinions. At the moment, for example, its flat, has muted colours, and often has thin sans-serif type. You can love or hate it, agree or disagree, but it’s true. In a year’s time, it will generally be something different. Again, the older and the newer will still be there, but we’ll still have a new, pervading “modern aesthetic.”

What excites me about this most is the weight it lends to a new design of your’s. When you present a prospective design to a client or boss, and they hate it because it’s “grey” or because it’s “boring” and “flat”, you can point them to something huge like Google and tell them to get with the times.

This excites me quite a bit.

I want them to tire of their own limitations and decide to push past them and put in the effort to make that happen

— Kate Bassford Baker

From a fantastic piece on life, parenting and the nature of self-discovery through disappointment. via Kottke

Though it all sounds pretty cool, the problem with the “everything is an object” for beginners is that it’s still fairly abstract. You still don’t know what you can even do with objects—you just know that everything is one.  Seeing that functions were objects was a ground-breaking moment for me. It came when I read these few lines:

// Don’t do this: function getData() { }

// Do this instead: var getData = function() { };

There it is. Plain as day. That function you’re creating can be used just like any old variable. Though there’s no real difference between the two, it’s a fantastic way for beginners (like me!) to think about functions.

Functions are one of the biggest stumbling block for beginners, imo. Getting to the point where you can pass the return value(s) from one function to another is really a holy grail and indicates that you’re actually “getting it.” Hopefully this will help with that.

Lance Armstrong was not a man, he was an idea; an American myth like Honest Abe and Johnny Appleseed. He was the little engine, brutalized by illness and then savaged by opponents, who could anyway, somebody who shrugged off hate and always took the high road.

—Michael Specter, The New Yorker

The scenario: So, I was working on a website that has been live for a few months now. I’ve been regularly pushing fixes and new features by just committing to the master branch and pushing that: Add some new footer info, change a few css styles, add a few lines of jQuery, etc. No sweat.  I’d just make the changes, commit and push them, and then they were live. The trouble reared its head yesterday as I was working on a fairly large new feature. The changes spanned about 5 different files, and nothing was ready to go live yet. My coworker messaged me saying—”I just added a table to a page, but it’s completely unstyled. Do you need to add some css?”

Here I was, with a ton of changes made to a pile of different files, my local master is about 10 commits ahead of my live master, and I need to push about 5 lines of css.

What did I do? In the end, I was able to use Github’s app to select and commit only the lines I needed in my css file, and run git push origin XXXXXXXXXX:master with the latest commit id. The problem was that I ended up doing that all day. Pushing individual commits to the live server all day is really, really stupid.

What I should have done: A month ago, when I started working on that new big feature, I should have created a new branch for it. If I’d done this, pushing those table styles yesterday would have been really painless. Basically, I would have had three branches yesterday:

1. master
2. new_feature
3. table_styles

I would have worked in the table_styles branch, writing all my css there, and then merged the changes into master before pushing it live. When I was done merging, all I needed to do was delete the table_styles branch, and I’m all set to continue working in new_feature.

The takeaway advice: (Clearly) I’m no Git expert, but next time you commit to master, ask yourself if what you’re working on shouldn’t be happening in a new branch, and get merged into master when you’re done. My new practice is creating a new branch for every new thing I work on. This way, master will always be ready for quick hotfixes and minor changes.

I’m a complete noob, I know! Maybe I didn’t know before, or maybe it was just laziness, but yesterday was literally my first a-ha moment with this. If you’re just starting with Git, you should really get into the habit of using branches. The official guide will do a great job of showing you how to use branches, and I hope I’ve just done an ok job at showing you why you should.

The result? Well, if you look real close in the screen below, you’ll see my name in the bright lights near the bottom. Seeing my name on this page was extremely exciting.

But then the guilt

Truthfully, although my name does magically appear on the credits page, I must confess that I did very close to nothing to help out with the development and release of WordPress 3.5. Very early on, I participated in some discussions on a new look for the Welcome screen, I very briefly popped in to talk about the “Page on front” workflow, I suggested that icons might be nice on the welcome panel, and I thought that a border might be nice under h2 tags in the Twenty Twelve theme. Like I said, in the scope of this thing, I contributed almost nothing.

Why didn’t I do more?

There are two main answers here:  A) I just didn’t. Simple as that. And, B) the technical reasons.

Before I say anything about B), I want to make it absolutely clear that I did not do all I could to overcome the technical hurdles I faced when trying to contribute. I didn’t read as much as I should have, I didn’t reach out enough when I ran into issues or got confused, I didn’t develop a deep enough understanding of Trac, I didn’t step up and claim ownership of issues I could actually help fix. I want to make that crystal clear that I personally did not do enough to overcome the issues I ran into. Ok, so onto B: the technical issues.

Technical Overhead

Contributing to WordPress comes with a lot of overhead. Knowing how to setup a local install of the latest version, keeping that up to date, creating patches, applying patches, and I haven’t even mentioned Trac yet. A lot of the issues I had have already been pointed out in the notes from the “Engaging/Retaining New Community Devs” at this year’s community summit, but I want to
specifically go through a few of the issues/questions I had here:

1. I use Git. Is that ok? Should I just learn svn already? Update: Scribu posted a great, concise how-to. Sounds like you’ll never need svn again.

2. Making patches. Helen very kindly walked me through the process of making a patch. Very soon after, however, with no practice, I’d forgotten the basic steps

3. Keeping my repo in sync. So, I clone WordPress from Github per Mark Jaquith’s instructions and start working on a ticket. As soon as touch a single line of code, my repo is out of step. What do I do now? I’m positive I’m not doing this right, but I don’t the right way to do it.

4. #Trac. How people can find and sort tickets to issues is just beyond me. I find Trac to be almost a complete mystery. How do I find open tickets? How can I get a list of tickets that I might be able to work on?

5. #wordpress-dev. The folks who inhabit #wordpress-dev on IRC are extremely knowledgeable and helpful. They’re also very busy and focused. This definitely isn’t the place for questions like “how do I make a patch” when we’re right in the middle of heavy development. But outside of there, I don’t really know where else to ask that question.

6. Foraging for resources. I wish there was one good, comprehensive guide to contributing that brought you through all the steps. Everything from cloning the repo, making changes and not ‘breaking’ the repo, searching Trac for a ticket, creating/applying a patch, etc, etc. There are a lot of great resources out there, but they’re scattered around and sometimes not easy to find.

A few ideas

I can’t just create a list of problems without suggesting some ideas to help fix them. Two things stand out for me as being potentially huge for new-comers like me:

1. Mentoring. The word mentoring is loaded, I know. It comes with connotations of a long, arduous and time-consuming process but it doesn’t need to be. My suggestion? Create a place where a mentor can help walk you through three tickets. That’s it. In the process of working through these three tickets, the mentor can teach the new person how to set up a local repo, create/apply patches, and give them the basics of Trac. I think three tickets would be more than enough to get someone started.

So…..the real question here is — where do we get these tickets?

2. Identifying/tagging ‘easy’ tickets. Early in the release development cycle, you see lots of “easy” tickets floating around Trac. I’ve seen some that require changing a single line of css! Tickets like this would make a perfect starting point for someone new. Here’s how it might work:  A ticket would be tagged as “easy” or “beginner” and a mentor would assign it to their new student. Tagging a ticket with “beginner” would mean that an experienced person should leave the ticket alone until a new person has had a crack at it.

This process would really get to the root of my issues pretty fast. Having three easily solvable issues assigned to me, with the support of an experienced mentor would be huge.

A brief afterword

As I hope I’ve already made perfectly clear, many of the issues I encountered in the past few months could have been solved by simply trying harder and persisting more. That said, there really is a lot to learn, and the biggest part for me was finding something small and “easy” to learn with. As you would expect, as soon as a simple ticket shows up, someone has a patch created in a few minutes. I really think that leaving some of these easier issues in reserve for new-comers, and actually assigning them, would be extremely helpful. While I recognize that this would slow down development, I think it would really be worthwhile, at least early in the cycle, to have new-comers get their feet wet with actual tickets.