[eswangren]

You're right, but let's not trivialize the difficulty of programming in general. Want to build a UI in .NET, HTML + JavaScript, or <insert UI framework here>? Sure, that sort of programming is relatively easy and not usually technically challenging. However, that is hardly all that we do.

I don't touch UI's in my day job. You make it sound as if all programmers code UI's and perform other relatively mundane tasks. That may be what you're used to, and yes, it is relatively easy work, but there are a bunch of people like me out there who design infrastructure at a low level so that you can more easily build software at a high level.

[x1]

>let's not trivialize the difficulty of programming in general

No, let's trivialize it. What exactly do you do on a daily basis? Give me an example of a task that you worked on that took a lifetime to master. Something that you could only truly appreciate after years of focused experience.

[eswangren]

I have no example of a skill that took "a lifetime to master" as I am only 28 years old and would not call myself a "master" of anything at this point. However, I can describe the last two projects I worked on.

One was implenting an image quality algorithm for a medical imaging system. I did not do this on my own, but I will wager that it was far more complex and involved than any UI code you last wrote. I had to understand the science behind the algorithm, implement it, and then make it fast (it is run on huge images).

My next project was optimizing a heap memory manager for the device which captures these images. Not PhD level physics here, but not trivial and not something I would expect a UX guy to do.

So yeah, I take a bit of offense when you lump all programmers into the same bucket. Not all programming is engineering IMO, and to compare writing a UI to writing a thread scheduler, a memory manager, a new programming language, etc. is just ridiculous.

I'm not saying that UI work is dumb simple. It is incredibly hard to get right, but that kind of complexity is not technical. It takes a certain kind of aptitude and knowledge to do work that is closer to the metal and closer to concepts taught in CS. Creating a UI is not CS, it is wiring up bits of code that other people wrote in a such a way to be useful to a non-programmer.

So yes, a UX guy could probably be writing his or her own UI's in about 6 months to a year. I would not hire this person into the group I work on because they will be overwhelmed by technical complexity that they simply won't be able to handle.

[x1]

I'm not sure where you got that I was a "UI guy", with that said you sound terribly defensive about your work and your abilities. It is almost as if you are insulted because you believe what you work on requires an advanced intellect. That's something you'll need to get over eventually.

[eswangren]

Well, no, but I see how what I said may cOme off that way. I gathered that you were a UI guy from statements you made. It seemed to me that you were trivializing programming as a whole by saying things like "do you think anything we do is that difficult?". Well yes, some things we do are terribly difficult and require far more knowledge than what may be gained by reading "teach yourself HTML + JavaScript" for a year.

[x1]

I think we're arguing the same points.

We both seem to agree that your run-of-the-mill Java programmer working for the autozone website is not a complicated position.

We both seem to agree that your run-of-the-mill UI/UX person working for the same autozone website is also not complicated.

I bet you would agree that designing the interface for the first consumer focused touchscreen-only device is something that is very complicated.

Just like I agree that working something that deals with ct scans, ultrasounds, 3d printing, 3d rendering, product delivery and a host of other problems are very complicated.

The real point is that you should know your industry, and yes all of our industries are a little different. If you are working on the Accuvix V20 Medison ultrasound system I personally believe you should know how to turn the thing on, point it, run the scanner, understand the readouts (to a certain degree) as well as understand the inner-workings of the image acquisition and processing. I believe this is just what helps people make more informed decisions. This doesn't mean you suddenly have to be a UI/UX person, it simply pushes you to know the complete lifecycle and have some competency in the product you are working on.

Should you be a UI/UX person? No. Should you know why the UI/UX decisions are being made? Absolutely. Knowing that will help you write a better system, it will also help you bring to light more possibilities.

I mean, would you call Jonathan Ive a "UI guy"?