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.
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.