Hi. I'm Andrew

Filed under: frontend

See all posts on posterous with this tag » 

Why It’s a Good Idea to Be a JavaScript Developer, and What it Takes to Be One | Clientcide

So what does it take to be a JavaScript badass, and what do you get for it? Well, to be a really top-notch front end developer means you’re going to have to spend a lot of time doing stuff that’s tedious and boring, some stuff that’s really hard and beyond your talents, and some stuff that’s just plain fun. For what it’s worth, here’s my list:

  1. You need to know HTML. You need to know everything about it. Everything. You need to know what effect document types are going to have on your markup’s display. You need to know that browsers will shove a TBODY tag into your tables even if you don’t code one. You need to watch what the browser vendors are adding into their nightly builds and their upcoming specs. Learning this stuff, at least for me, just takes loads of time discovering it as you work.
  2. You need to know CSS so well you’ll regret it. These days most of the cross-browser problems I encounter are with their CSS implementations. Getting around them usually means describing the exact same style in a different way. You just added a negative margin-top to a link and guess what, the users of certain browsers can no longer click them, despite the fact that you gave it a z-index of a million and you can clearly see the damn thing. Or you just made the most amazing collection of positioning statements to make an auto-resizing masterpiece of CSS awesomeness but god help you if your boss looks at it in Internet Explorer. The thing is, having this skill – being good at CSS – isn’t really all that interesting or valuable any more. Everyone who works on the front end is just expected to have it. There are some seriously talented CSS developers out there who go far above and beyond this kind of knowledge and truly make CSS into an artform. You don’t have to be one of them, but if you can’t make the page look like the mockup, it doesn’t matter that you can do just about anything else.
  3. You need to know the browsers. You need to know that IE won’t let you convert this string: “<meta></meta>” into DOM elements by setting the innerHTML of a DIV. And forget about injecting it in the HEAD to turn it into a DOM element, because that thing is read only. You need to know that IE will always barf at trailing commas in your array and object literals. You need to know that IE has offset positioning issues for elements inside of iframes. And IE isn’t the only pain in the ass; Firefox has those clearfix issues with floated elements and webkit’s no saint. And you need to know that the latest versions of webkit have whatever awesome new features it has, as well as what ways mobile safari differs from the desktop version.
  4. Did I mention JavaScript? You need to know how ALL of JavaScript works. You need to know that the arguments object in a function has a length property and is iterable, but it isn’t an array and has no methods. Further, you need to know how to turn it into one. You need to know how the prototype property works, how to use it on your own without the help of a framework, and what the implications of using it are. You need to know how to garbage collect things and, for that matter, how to tell when you aren’t. You need to be really good at abstraction. Seriously brilliant at it. You need to be good at designing APIs for yourself as well as others. You need to know how to test your code and how to manage it.
  5. You need to be decent at design – information flow, graphic design, user experience design, code design. You need to be able to interview a user, a client, a stranger, an expert, whatever, and ask them the right questions to be able to devise an experience that solves their problems. Not just the ones you can imagine, but the ones they don’t know how to describe. You need to be able to open Illustrator and put together wireframes quickly to devise a plan, then switch to Photoshop – god you need to be good (that is, efficient) at Photoshop – and put together the visual style. You don’t have to be the worlds best designer; I’m certainly not. But you need to be able to tell the difference between good design, bad design, and amazing design. If you can manage good on your own, you’re set.
  6. You need to be comfortable on the server side. There aren’t that many positions out there where all you write is JavaScript all day long. Most front end jobs will see you writing as much as half of your code in JavaScript, but you need to be able to pick up other languages relatively quickly (in, say, a month or less). Python, Ruby, Java, PHP… If you only know one programming language, it doesn’t count. If you only know JavaScript and PHP, and you balk at any task that requires you to use something other than those two (rather than, say, looking at it as an opportunity to learn something new), then you need to ask yourself what you’re doing here. Knowing how to use a framework, but not how to accomplish something without one – with vanilla JavaScript – doesn’t count as knowing JavaScript.
  7. And then there’s about a million other things that you need. You need to understand Git. Git is amazing. I know you’ve heard people tell you this, and if it still seems like an alien monster that refuses to explain itself, then you need to hunker down and figure it out. You need to understand how to get things done with just a shell. You should be able to open up vi or emacs and edit a conf file without launching notepad or TextMate or whatever. You should be able to run make and compile things. You should be able to tail a log file, unzip a tarball, secure copy things, run servers and configure them. You need to be able to kill processes and read a stack trace.

Filed under  //   frontend   javascript  

Comments (0)