I think the problem is not that one person can't have both of these skills, but that it is hard to play both roles on the same project unless you have a lot of discipline.
The engineering mindset and the UX design mindset optimize for different things. Even if you are excellent at both, it helps to have someone else forcing you to get the UX right when you're doing the engineering work, and to make the engineering possible when doing the design work.
The people who can do both at the same time don't differ in having both skills -- lots of people have them -- but in having the discipline to optimize for both in alternation.
I find the reason it's hard to do both on the same project is that the engineer by definition knows the internals of the system. It's hard to un-know that and see things afresh from the user perspective. Thus one tends to create UIs that are intuitive to someone who already has a mental model of how the system works, but seem convoluted and arbitrary to everybody else.
This is a good idea. I'm going to try to do it on my next project. I don't know if I can stop thinking about the data and implementation. It is just where my mind naturally goes. Someone presents me with some type of data and a way they want to present it and I immediately start thinking about data representation, persistent storage, data abstraction models.
I think more important is just to get out of the engineering mindset and try to think like a user. I bet just sitting down with a non-technical person and working through the UI design would help a lot to keep me from going into my engineering mindset.
but that it is hard to play both roles on the same project unless you have a lot of discipline.
For me it's less of a discipline issue and more of a time issue.
Both the backend and the frontend take a lot of quality time to do them right. It's simply not effective to have a single person context-switch between them, even when said person is very good at both. I.e. this is one of the situations where two people can indeed produce a given result nearly twice as fast.
However, I also agree that on top of that discipline plays a role, too.
While wearing the engineer-hat you have to constantly force yourself to stick with the brain-damaged abstractions that comprise todays "state-of-the-art" and not give in to the urge of fixing them bottom-up.
I.e. when both front- and backend are in your hands then the temptation to make the frontend truly model-driven can quickly become overwhelming (auto-generate those stupid forms and validations! why mirror when we could just rpc!). Sadly more often than not this results in a huge time-sink, as you embark in an uphill battle against a tool-chain that's strongly optimized for the exact opposite.
This is the best comment so far, I think, because it highlights why a designer + engineer, even a theoretical 'designeneer' equally skilled at both, isn't necessarily going to be twice as valuable, and in fact may be only as valuable as a single engineer or a single designer.
I believe strongly in the value that knowing both can give you, and for certain classes of small project it's a huge win.
But you're right: context-switching is a limiter. You only have so much free time and mental energy.
For me, I know that I prefer working with competent UX/visual design guidance. I can get some really pretty results from doing my own designs, but it's a wonderful freedom to know that I'll spend 15 minutes in the morning iterating on a piece of paper with a designer today, and then just go away and do my thing. I'll get a PSD that will make the prototype UI more concrete late-afternoon, and the next morning we can talk about how using the UI makes us want to change it.
But if I was doing it all myself? I doubt that even with twice the time, the overall result would be equal, either on the code or the design side.
That designer keeps all of his visual design acumen and photoshop 'muscle memory' loaded into cache.
I keep my emacs key-chords, the code's secret sauce, my bash and git aliases and the topography of staging environments loaded into my cache.
There are definitely projects that exist where you can 'do it all', but ... node.js' model is great for maximizing throughput, but when you've got drastically different types of work, that's what you have multiple cores for. ;)
Re: "brain-damaged abstractions" - you reminded me of a coworker who could be called a "designeer" (he's a good programmer but he also does decent UI/UX).
The problem is, he ignores deadlines because he hates the brain dead abstractions and bad code, and decides to unilaterally refactor.
I feel sorry for him because I understand that he can't stand the sloppy code, he is working with nimrods and mediocre people (and awful tools), what he should do is quit. (some of the mediocre code is, I admit, mine, I've stopped caring and I just want to build a nest egg to quit)
100% agreed. That's why I couldn't believe the upvote fest on the "anti-Product Guys" post a while back. When you do it all, you quickly learn that it's absolutely exhausting work.
More than just the same work 2x, but more like 3x or 4x because of holding it ALL in your head and trying to balance it.
I had the same experiences you did. So, while I'm a good back-end developer, and a great front-end developer, I've chosen to focus on design because A) I'm amazing at it -- it's my best skill, so that is the best use of my energy, B) I don't have the time or energy to do it all any more.
That said, I do still pay attention to the overall shape of the code (and my husband/biz partner pays attention to the design).
Several times, I've been able to wade into a drawn-out discussion between my biz partner and one of our freelancers, & cut thru the crap with a beautifully architected solution. Which always makes me feel warm & fuzzy. And they look at me and go "Oh yeah, you DO know what you're doing," which is worth it just for that. (Because my biz partner has this irritating tendency to tell me "that's impossible" as if he forgot that I damn well know it isn't ;)
Being entirely wrapped up in the code OR the design can be dangerous. ("That's impossible!" - ha.)
I wouldn't trade my ability to do both for anything. I'm glad my husband & I are both "desingineers," at slightly different mix percentages.
"Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations"
When the organization structure of a project is 'there's just one guy who does it all', the software architecture will tend towards 'the big ball of code' pattern.
However, if the team on a project has people who are engineers, and people who are designers, then a designineer might be a useful product manager to help balance conflicting engineering and UX requirements.
In a startup, looking for a first hire engineer, you probably want someone who will grow into that role - but it's a mistake to have your first system built by them and them alone, because you'll almost inevitably wind up with a big ball of code.
In general, all software should be built by at least two people collaborating, to force some division of responsibility, which will (via Conway's Law) force some structure.
(as you say, the best developers are disciplined and capable of structuring systems in the absence of a forcing structure. This is maybe because they divide work logically into units, and therefore find themselves collaborating with their past- and future-self, giving the structural effect of team work. But apply pressure to even a great developer and that discipline can break down.)
I don't know if I agree with this. It seems like the more people there are working on a project, the more likely you will end up with a complicated ball of code. The reason being is people generally aren't working with the same mental model on the system they are implementing. So, some of the engineers will think its obvious to do things one way, and others will do the opposite. It doesn't make sense for complete rewrites when the other engineer reviews the code, so you end up with inconsistencies in the code. At that point there is no real way to look at the code in a coherent fashion. It doesn't completely make sense to the first or second engineer. It has become a complicated ball of code.
If we accept the initial premise that designers who are also engineers are as rare as ninja-unicorns, then surely the logical thing to do is to turn them into managers?
I was an artist most life and learned engineering when I was 20. It was extremely difficult but I did well and graduated at the top of my class. I can still draw and paint, but creating beautiful web interfaces is very hard for me. Like you're saying, it's not for lack of ability. It's a curse of knowledge.
When you design a UI as an engineer, you're thinking long term. Like make the whole thing white so that new features can be added in easily. Also, the logo is going to need to look good on white anyway for email footers, Facebook apps, etc..., so just make header background white. Then you may have integrations with third-party widgets. All will support white best.
Also, things that 'look' good often are not usable. Like text below 11px, and low contrast shades of text may not be visible to older folks. I see this stuff all the time on sites with 'awesome' design.
Also, images for backgrounds, corners, buttons etc... slow the page load down and don't allow for easy extensibility or iterating. So if I can't do it with CSS, I don't do it.
Page load time, non-buginess, and iteration leading to smooth functionality are the most important parts of UX, IMO. Making the site look like a piece of art does none of these, but I think art gets confused with UX too often. Do you visit this site for the beautiful design? How about Google or Facebook?
If you spend the time to do beautiful design and functionality like Apple, you can create something where the beauty does not detract from usability. But, that takes somewhere on the order of 10x the resources since they're doing 10 prototype designs, refining 3 of them, and only keeping one. If you're trying to create a market, then that makes sense. However, if you're trying to create the most useful product in an existing market, then you're wasting time IMO.
A lot of people can do passable jobs on both roles, but I've never met someone who was awesome on the backend that was also a great UX designer. Likewise, the best designers can whip up a new UI in an afternoon, but it might take them a couple weeks to get it coded.
Maybe, but requiring both skills to be "great" and "awesome" in order to be anything more than "passable" is a little unfair, no? Are there situations for which "passable" is indeed doing a good job?
And yes, it often takes longer to code features than it does to draw and place their UI elements.
My point was that most good coders can implement a designer's UI a lot faster than the UI designers.
For almost all situations I think you are better off getting two developers with complementing skills rather than two jack-of-all-trades that can do "everything". If you can only afford one person then seriously consider how to contract out some tricky parts of the weaker skills to an expert. Then you have a good foundation to build on.
Engineering and UX can go hand in hand. What clashes is User-Centred UX and (sometimes) business objectives.
When engineers and UX people work together, it is bliss as both provide a piece of the puzzle, can't see why one person can't do both.
Agreed. It's hard to switch gears from being head deep in back end code to thinking about and approaching a problem in terms of design. Maybe if you can spend one day coding and the next designing...
Unless I'm working for myself I find I rarely have this freedom. This is why I left my last startup. If I'm trying to do both there are too many things that I'm accountable for on a daily basis to the boss, who in my experience doesn't want me to stop coding to "waste a day" designing.
And in the end I feel like I just end up doing a half-assed job on both. More power to those who can do the switcheroo, be excellent in both, and keep the writer-of-paychecks happy!
Definitely the best way is to not work in little nibbles but long stretches, like a day or two on each. Otherwise you're going to drive yourself insane! (As you've learned.)
I agree, there are a lot of people that can both very well and to be honest most contractors have to be able to if they want to get work.
I don't think that the skill set required is actually that different, but your right in saying discipline is required in order to excel in both.
Then I think the key point is those that do possess both skills and the discipline/drive to excel at both are usually either doing very well doing their own thing and aren't looking for work.
There are some people that have both but it is extremely rare as the author points out. Being a hack or OK in design and development is not the same, many people can do that. I think he is pointing out the very small circle of extremely gifted individuals who can legitimately do both on a professional level.
As in any profession there will always be some extraordinary individuals that are heads and toes above the rest.
You're probably also not making two salaries' worth for doing two roles worth of work. But I know, you guys don't go into startups for the money, right.
The engineering mindset and the UX design mindset optimize for different things. Even if you are excellent at both, it helps to have someone else forcing you to get the UX right when you're doing the engineering work, and to make the engineering possible when doing the design work.
The people who can do both at the same time don't differ in having both skills -- lots of people have them -- but in having the discipline to optimize for both in alternation.