When in the web domain, I find that the sought after skill is connected to what the user sees. Be it graphical elements, css art, user interface design, content strategies, copywriting or mobile adaption, to mention some examples – when looking for help, a buyer tends to view the needs from the perspective of the user.
This is, of course, a necessary and good thing. But it poses some challenges for those of us working as developers.
37Signals advocates that everybody should be writers, and makes sure that the designers are the team leaders. I think this makes sense, especially for a distributed company. You will need to communicate, and the better you do it, the better off you are, and the more you get done. And last but not least, the better you communicate, the better you are at enabling others to get stuff done.
Designers as team leaders are a sensible idea. They are in charge of the communication. They might not always be the ones that are capable of implementing a complex algorithm, but they are the ones that bind together users and developers.
But I digress.
If you look at how the terms are used in everyday-lingo, the separation is even simpler. Developers make software, or web pages. Designers make them look good.
The lines are more blurry that that. Designers often implement their designs, and developers more times than not need to implement designs without support of artists. The skills aren’t mutually exclusive either.
But you’ll need to know what you are looking for. Know that more times than not creating a website is more than a single-person job, if it is to be done well. And, even though most is able to a certain degree to do both, be specific. Do you want a search interface, or the algorithm?
Two days ago, I attended the “Skriv bedre javascript” meetup in Trondheim.
7 quick lectures, 10 minutes each. One half broken iPhone as a notepad.
- parseInt has not one, but two parameters. Pass 10, and you’ll avoid silly problems because the passed string is interpreted as the wrong numeric system.
- If you use (for something in yourarray), you’ll most likely end up with tons more of entries than expected. Better use HasOwnProperty, or a regular for loop.
- If you skip on the semi colons, the parser will guess what you were trying to say.
- If you loop strings, string[i] == ‘A’ is…. unstabile. Use string.charAt(i) == ‘A’
- If your function takes time to complete, setInterval will get you into trouble, queuing calls to your function. Rewrite to use setTimeout at the end of the function instead.
- eval is evil
- Be aware of closures
- Javascript has packages
- Douglas Crockford knows javascript better than both you and I. No, really!
- Javascript has global scope and function scope, but not block scope. Srry.
- Hoisting has some rules about parsing variable declarations. If you run into weirdness problems, that might be the answer. Declare your variables at the top, please.
- jsLint checks the quality of your code according to some criterias, but isn’t the one-stop solution.
- Avoid alert and console.log. Both suck in all or some browsers (I’m looking at you, IE). Use a debugger framework, such as log4js, blackbird or Ben Alman javascript debugger.
- Easy jquery plugins are…. well…. as easy as …. erhm…. let’s just say they are simple to implement.
- jquery UI Widget Factory structures a way to create plugins. Part of jquery UI.
- Cool stuff in the HTML5 js library: a few new calls, web storage, offline application cache api, web workers, web sockets, drag/drop, geo location, canvas and audio manipulation.
- Same origin policy could have been a problem for js-based twitter clients, except for the entry of json-p.
- Prezi is nice for presentations.
- Microtemplates, by a guy named John Reisig.
And, at the top of this, some more details about Canvas and some of the stuff named here, that I just decided to Google when I need it. Two hours well spent.
This post is for the technical oriented among us. For the rest of you, sorry – we’ll get back to the regular broadcasting soon enough!