A fun post for a Tuesday morning, Aaron Newton shares his path to becoming a JavaScript ninja, and how you can too. Some of his tips (I encourage you to read the whole article):

Study design and designers. I’m not saying you have to have the talent to be an awesome graphic designer, but you should pay attention to people who are. When you are surfing the web, pay attention to what works. What looks good? What communicates to you that you can do something on a page? A great example here is this video of Bill Scott’s work on UI patterns. He gives great examples of what the “interesting moments” are in UI design. But in general, you should pay attention to the sites you visit and notice when they get things right and wrong. I often ask interview candidates what sites they admire and why.

Study JavaScript. I mean really dig into it. Watch all those awesome Crockford videos – ALL OF THEM! – on the YUI theater. For that matter, watch all the OTHER videos there. Seriously awesome stuff. I don’t agree with 100% of what they all say, but they are educational for sure. Read Crockford’s JavaScript: The Good Parts. Again, I don’t agree with it 100%, but it’s a seriously solid overview of the language.

Study JavaScript Frameworks. Note that this is plural. The single most important thing I’ve done in my education with the language was to write the original documentation for MooTools. To do this, I had to read the entire library’s undocumented source and figure out what it was doing and why. I’ve learned a lot since then, but nothing I’ve done has ever resulted in as big a jump in my knowledge. When I wrotejqueryvsmootools.com I did it again, this time with jQuery. I read the entire source so that I could understand it. I did it again with Dojo when I put together a talk about programming to patterns that I first gave in tandem with Dylan Schiemann of the Dojo team (the talk wasn’t about frameworks so much as it is about the value of abstraction, and I wanted to make sure it wasn’t just a MooTools focused talk). I’ve done the same thing with other frameworks to learn the lessons that I can from other people’s development styles. Don’t just use jQuery or YUI or MooTools. You need to study all of them to understand what makes them the same, different, and interesting. Don’t stop until you understand everything that these frameworks are doing and, more importantly, why. Don’t hesitate to ask their authors for explanations; most are happy to talk about their work.

Get involved with a framework. The second most important thing I’ve done with JavaScript was getting involved with the MooTools project itself. Working with open source projects is a HUGE boost to your resume and, here’s the thing, you don’t need to really know that much to get started. You just have to be willing to spend the time. Right now, there are dozens of bugs open on every framework out there. Go fix some! Go write test cases! Go write a blog post about how you use it! Do these things and get committer status and I promise you you’ll start getting a ton of interesting job offers.

Release some of your own code. I can’t stress this enough. If you don’t have code on github (or google code or your own site or whatever) you’re wasting a big opportunity. Releasing your own code allows me, a potential employer, to know your capabilities before I hire you. This stuff gets people interested in you. If you release a lot of your code, you may even get others to help you maintain and grow it. This is how open source projects get going. I almost consider it a red flag to see a resume without a url to github or something similar.

Blog about it. Write down everything you learn as you learn it on your blog. Next thing you know, 3 years have gone by and you have this huge body of work. Stuff on your site draws the attention of other developers who are struggling with similar problems. You become an expert without really meaning to. If you blog constantly about what you are doing, what you are studying, you’ll find that people come to you with work to be done expecting that you are awesome because, well, you’re explaining all this stuff to them. I can’t stress the value of this enough, though it is very time consuming. This is especially valuable if you’re a freelancer.

Build something interesting. I once spent a month or two writing a photo gallery in PHP just to have an excuse to learn PHP better. I learned Smarty with that little project, too. I’ve built a lot of things for the excuse to learn it. I built Iminta.com with a friend and we chose Ruby on Rails mostly because neither of us had built anything with it and wanted to learn it. Forcing yourself to do things with new languages and environments will grow your skills faster than anything. Don’t rely on the skills you have; always look for chances, excuses really, to do things in new ways. Working with emerging technologies will make you debug that technology itself and maybe contribute fixes back to it. It can be painful, but it also makes you really learn how that technology works.

Join a startup. I know, this one can be tricky, especially if you don’t live in the SF Bay area. But joining a startup will make you tackle problems that aren’t in your domain because, well, there’s no one else to do it. If you’re not experienced enough to be the 2nd or 3rd person at a startup, aim for being the 10th or 20th. You’ll be asking for long hours and low pay, but you’ll get a mountain of experience. Think of it as an extended college education that pays you a little cash and (if the stock takes off) might buy you a house.

Take the time to learn why solutions work. When you’re working on something and you get an error and find the solution on Google, take the time to really understand what the problem was. When you are starting up an app server – ruby on rails, django, lamp, whatever – and you get a stack trace, take the time to dig into it and understand the problem and what the logs are telling you. Debugging stuff on the command line will teach you a ton. It’s slow, thankless work, but it’ll greatly improve your value when you take on more challenging tasks at new jobs.

Be curious, and fight off laziness. This is a bit of a weird one, I know. What I mean by it is that you should look at tasks that require you to do new things as opportunities. Recognize when these moments come along and cherish them. There is nothing more awesome than having a job that pays you to learn. If you have coworkers that know things that you don’t, and vice versa, trade them. When I was in college I told the guy who was building the web site for my school that I’d help him design it and show him how to use Photoshop if he would teach me HTML. I joined Cloudera 18 months ago and knew zero Python and now I’m pretty decent at it. If you have a job that uses technologies you don’t know, don’t just stay in your little JavaScript world; find ways to expand your knowledge however you can.

Great advice! I would also add, “do not be afraid to get up close and personal” – there are a bunch of great open source projects out there, and it’s not hard to get involved, but even if you don’t, blogs and twitter and even email are great ways to reach out and say thank you to the Resigs and Crockfords of the world. And more often than not, of course, they will respond.

Don’t study JavaScript frameworks, study JavaScript. I’m almost sick of jQuery as I am with IE. Stick to object detection and don’t use innerHTML or document.write. Keep your script elements in the head element; one should be a cached index.js that includes all of your static functions and the other file should be onload.js that includes all of your global objects/variables as well as the anonymous onload function. Learn the terminology and smack people who say the word “tag” when referring to elements. Most importantly learn about the DOM and if you want to get really good serve your content as XHTML which means using application/xhtml+xml. SilentLennie is spot on with making functions that you can reuse; my emphasis dynamic, the more you can do with less code the better you’ll get. I kind agree with the fighting off laziness though part of my personal drive is building my own solutions because the existing solutions are bloated, rely on frameworks, are static, etc.

Things not to do? Go to college, total waste of time and money. Don’t rely on others, the closest thing you should try is posting on forums though however don’t forget to contribute back when you get awesome at stuff.

Most important of all? Realize what criticisms are acceptable, it’s been about 2% of all the criticisms I’ve ever been given most of which has been “don’t” with a massive lacking of “why”.

Best advice I could give for polishing a product? When design meets technology the golden rule is to reduce the number of steps to achieve a goal though don’t screw over advanced users who enjoy being able to customize things. Balance usability and control and you’ll do well.