My Story, In Brief
My road to being a JS developer is not that interesting, if you ask me, but, shrug if you want to know, here are the highlights:
- I studied music, photography, and graphic arts in high school and some in college, though it wasn’t my major (which was Jazz Guitar – seriously).
- I learned HTML back when Mosaic was still in use and grew my web skills as they arrived in each new browser update.
- I joined a startup (knowing HTML in 1997 was a hot commodity) where I learned a bit of programming (Java). I wasn’t really very good at it. I built a really simple CMS with it.
- At first focused my work around Prototype.js and Moo.fx.
- When MooTools first arrived, I was hooked from the start (here’s posts one and two from 2006 of my first thoughts on the framework).
- I left CNET in late 2007 to start Iminta.com, which I’m still proud of. Then the economy died at the end of 2008 and I started contemplating finding a job and found Cloudera (or, really, they found me).
- 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.
- 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.
I could probably go on about this stuff for a while longer, but I’ll stop. What it really boils down to is that you have to want to be a front end developer and pursue it the way a concert violinist pursues the first chair. There are hours and hours of practice for which no one will pay you. But eventually you’ll find yourself in a position where someone will pay you to do what you love and you’ll find it hard to believe how you got there. Next thing you know, you’re the person designing the user experience at some hot startup and trying to hire new people to join you.
Did I mention Cloudera is hiring?