In my experience, the designers are learning how to program way faster than the programmers are learning how to design. (This coming from someone who's doing the latter.) I can't give a good reason as to why; it's just a gut feeling.

So in addition to computer science based HCI programs like CMU and Stanford, keep an eye on programs in studio-based design schools. A lot of undergraduate programs in designing technological experiences - combining engineering training with studio method - are starting up in places like NYU, SVA, SCAD, CCA, CMU's art department, and the like. Many of these schools already have strong masters programs which take undergrads with computer science backgrounds.

There's a difference between the level of programming required to build a proof of concept, and the level required to make it do anything off the beaten path.

I think it's well established that it's never been easier to get a web application off the ground, and UX+design in this space definitely is a differentiator, and probably more important for those initial first impressions than the programming.

It's a function of market saturation though, creating your average web application or site is a pretty established problem, with a huge number of options when you need to go about building it.

Where engineers are not a commodity? Any company that needs things to be delivered yesterday, in a space where you need cross-disciplinary, out-of-the-box thinking, with the ability to play multiple roles (sysadmin, support, customer service, programmer).

These types of engineers are quite hard to find, and satisfaction with the average "commoditized" engineer will be extremely low.

Let's say, making an HTML5 iPad app talk to a proprietary hardware device using a proprietary application protocol over TCP to make for a rocking walking salesman appliance.

Yeah, good luck making that sing in a sufficient timeframe if you don't know what you're doing.

I went to Northeastern and my undergrad degree was in "Information Science" program which is a mix of HCI/Usability/Com Sci, though it's an unfortunate name for the major as most people have no idea what it means. There was very little focus on web technologies and more of a focus on interaction principles as you said. I don't know that I wanted to take an HTML/CSS/JS class, but I always wished that my major involved some more design type classes to hone people into that type of career more. I love doing front end work, but I think at this point I lack the design skills to do be an effective employee in that sense.

I think HCI -- even though it's a relatively new program in most schools -- is a response to a problem a decade late. For reasons good and bad, Academia can't keep up with Moore's Law.

First, you don't want to build a major for every new technology; the half life of most technologies is very short. Second, sifting the cruft from the stuff that will outlive the specific technology (think personal updates vs. friendster -> myspace -> facebook -> twitter) is difficult.

So you end up with a compromise: A school of thought that teaches (or tries to) timeless principles of interaction. This is an incredible advancement in education, but unfortunately means less to someone looking for employment right out of college.

The problem is that UI and UX are a mix of science -- something taught at universities and colleges -- and what is traditionally relegated to vocational schools. It's not an applied science; it's more like being a mechanic or someone who makes those really fancy import cars even fancier.

The solution, I think, is going to be a long way off; universities will have to hire people that teach more about the history of design, what people are accustomed to and expect, what interfaces work and why and how to design for people whose aesthetic changes once every couple years. Art schools will have to hire hardcore CS people to teach rock solid foundations of logic, how languages work, etc etc...

Just wondering, what really makes a good UX engineer? I'm studying HCI at a university other than stanford, and the course is total BS... I knew the principles we were supposed to learn were important, but having whole lectures spent on comparing command languages vs natural languages (i.e stuff like command languages are fast and good for experts and natural languages are good for novices... how to make prototypes out of postit notes... a low-fidelity prototype is a cheap prototype whilst a high fidelity prototype is expensive... Stuff I could tell you myself) makes it hard to spend my time focusing on the course. :(

The only useful thing I've learnt is that when you're doing a questionnaire with lickert scales, don't use mean because the distances between each point on the scale isn't equal...

It kind of depends on the scale you want to operate at. If you are Google level, UX tends to be VERY mathematically (statistically) driven. In which case I would focus on a degree in math.

Towards the lower end (read: almost everywhere else) of that scale, you're best bet is actually to look at a design degree, and learn the tech on your own.

Your best bet is experience in the field. Very few schools are teaching comp sci programs that are worth anything (Stanford, CMU a few others), and I have seen almost nothing of value in academia in terms of product/UX development (which is why I say focus on Math or pure Design). The web stuff you're really going to have to teach yourself, I think for at least another 3-4 years, maybe longer.

The author is somewhat right about the commoditization of the backend, but it's not to India, it's to frameworks like RoR. Larger companies that require serious, responsive scaling, sharding and cacheing are not, and will not be, outsourcing to these frameworks. But it's definitely not to India (data entry, sure).

Google is a combination of qualitative user research for the initial design backed by quantitative analysis upon release.

I would say it's the same thing that makes anyone good at anything: The ability to take the body of knowledge associated with the field and not only synthesize it, but to riff on it and make new -- or at least -- compelling things.

That might be too broad. Specific to UX, I would say that many companies only consider what a user experiences and the stories they accumulate when their brand is mature -- usually much too late to pivot.

A good UX designer in an early stage venture is usually also an interface designer, to some degree, and taps into the following:

1) Deep understanding of the market and demographic

2) A solid grasp on what people expect

3) A great appreciation for the things that compel people to action

UX designers and engineers make things that cause people to accomplish goals in a way that is unobtrusive (except when it needs to be) unoffensive (except when it needs to be) and not confusing (ever). That's my take, at least.

There isn't an engineer in the world that understands AJAX, jQuery or HTML5. Oh wait! You're talking about software developers or computer programmers or computer scientists aren't you? Why didn't you say so??

Sorry about the confusion. We call our developers engineers.

I'm told in Canada it's not allowed to have 'Engineer' in your title if you lack a P.Eng.; I think I prefer this situation to the common practice here in the States.

Can I ask why you prefer this? I think that prefacing the word engineer with the type of engineering is much more preferable than redefining the word to mean something to do with physical engineering.

I think it's not so much about the 'physical' part as about the 'rigorous training, certification and qa assurance practices' part. Developing software is very different from constructing a building (I do both, not as an engineer though); software is new, almost each and every time, because once it's build, you can just copy it byte by byte. Developing software is about pushing the edge in an unconstrained space. Physical construction (buildings, bridges, roads) is about repeatability; rigorous standards to reach a quantifiable production standard, and a build-in inertia to change. Large outfits (IBM, IT dev depts of big-four, that sort of thing) want to get software development to those levels, but nobody has managed so far.

It's a similar situation with the word Architect.

Everyone in tech fancies themselves an engineer and architect these days, although they have little nothing to do with the original intent for those long established professions.

It can be confusing and misleading for non-tech people.