Of course this depends on workflow and tastes vary, but for designers who don't use PSD to actually design websites (a purpose for which it is not very well suited), git or other version control tools are incredibly useful. Wasting a bit of extra space storing a few versions of a psd file is no problem - I've worked on 20GB local repositories before with a lot of assets, without issues, and it's easy enough to separate out large files into another repo or leave them out of version control if you have to. If a designer is creating 1GB PSD files with hundreds of assets in, I'd say (as a designer) their workflow is fundamentally broken unless they are producing billboard advertisements which require very high resolution files - you shouldn't have that much of anything glommed together in one file. So git works perfectly fine for lots of designers today, even working with binary files.
It's just a shame that these version control tools are mostly isolated to the workflow of programmers, as people at most workplaces I've come into contact with, from architects through writers or editors, sorely need a tool like git in order to manage collaboration and versions.
Many designers who do not code at all do not understand the workflow of Git. The process of pull, commit, push is extremely confusing. E.g. One large company that forces all designers to use Git ended up with multiple files with slightly different names in the repo system. Designers do not understand the concept of merge conflict and will just rename the file so that they can push to the repo. Case in point: the mental model of Git has worked well for developers, but does not translate well to non-coders.
Overall, I think a version control system for designers should be transparent, non-intrusive, and just works. Designers should not have to worry about when to push or pull, should not have to worry when to commit. I think it should just backup every saves and then subsequently allow them to flag specific design iterations that they want to highlight.
Disclaimer: I am co-founder of Pixelapse - Version Control for Designers.
What is the definition of "developer" here? Does it include HTML and CSS? I love working with designers who can translate their designs into actual layout and styling because it seems a lot closer to what they're good at than it is to what I'm good at. It seems like there's quite a bit of gray area in these definitions, but building front-end application behavior seems to flex similar muscles as building back-end application behavior, while tweaking CSS seems to flex similar muscles as tweaking element widths in photoshop. I'm genuinely curious what the common designer point of view is on this!
As a compromise, we had some luck syncing the PSD files with Box and checking in the exported static assets to git, but it was more of a patch than a solution.
*A PSD file has a max height and width of 30,000 pixels, and a length limit of 3 Gigabytes. Hence, Photoshop created PSB filetype which supports max height and width of 300,000 pixels and the length limit to around 4 Exabytes. https://en.wikipedia.org/wiki/Adobe_Photoshop#File_format
Depending on how hard the PSD format is to grok (purposefully or otherwise), this may be nigh impossible, but it also seems like it would be a great exchange format (which may be a another reason Adobe wouldn't want it). Then again, maybe there's already something like this...?
As a designer who codes (or a coder who designs, not sure at this point), I can see what he means about learning Git. It was tough for me to grasp until I saw this:
My point was that a primarily right-brained designer should teach fellow right-brained designers how Git works. Things just make more sense that way.
We aren't quite at that point where designers are saving out all of the assets for you, then that would be different. You can source control individual assets, but not a large PSD file properly. I've begun to train the designers at my work to save out assets for pretty much everything leaving me to solve the engineering problems like how everything is going to work and less time cutting out images from a PSD file, but we aren't quite there yet where this is a universal thing that designers just know and willing do.
Some people might disagree with point #6, but I wholeheartedly agree as someone who works for a company where designers design and developers develop. I think to be truly great at design, you need to devote at least 90% of your time (minimum) to bettering your design skills. If you're a developer, the opposite rings true. I think it is important for design/dev to have a mutual understanding of one another, but I don't think you can truly be a great designer and great developer in one. Having an understanding of the other perspective is important. You'll never meet a surgeon who specialises in brain and heart surgery, why should design and development be any different?
Fortunately, the employer I work for doesn't compartmentalise the teams from one another. There is nothing more horrible than working in a place where design and development teams are on separate sides of the office or even different floors with the only communicative layer being a project manager or team leaders. Designers and developers sit down and tackle problems together and educate one another in the process. This is something that happens through the whole process from wire-framing to prototyping to final build. I think designers and developers should work together at every step. I have met talented design/developers, but great ones of both fields are extremely rare.
PS. Joshua, if you're reading this comment, you might want to reconsider the 670kb background image on your site. I loaded your blog on my slow ADSL connection and it was painful.