Does being a programmer mean that you can't design?
Friday November 7, 2008
There is a wide-spread belief in the Web design world that if you're a programmer, that automatically means that you can't be a good designer. Something about the nature of programming made it impossible for them to have a decent stylistic sense. This was probably aggravated by the fact that programmers stereotypically wear mis-matched socks, plaid shirts, broken glasses, and pocket protectors. After all, if they can't be bothered with how their wardrobe looks, how can they possibly know what looks good on a website? Whether or not this is true (and one of the best designers I ever met was also a crack programmer - and I don't think I ever told him I thought so, sorry Steve!) nearly everyone can benefit from this article on Stefano's Linotype Why Programmers Suck at CSS Design. It offers a lot of great tips and clear directions for creating a good looking design.
Comments
More often than not the programmer is not a designer and vice versa. They are two different and opposed hats. Progamming is logical and objective. Design is usually gut driven and subjective.
The key thing here is that both work together on projects. Realize each others quirky bits and you’ll probably be okay.
The article on my site (linked) deals with an aspect of this.
Ted nails it in fewer and more sensible words than I could ever hope to — which tells you which of us is programmer and which is designer! o(^-^)o
A lot of the problem - and I believe the issue is not “programmers *can not* be good designers”, but “programmers *often are not* good designers - is lack of preparation.
Design, art, aesthetics - these take introduction, mentors, experience, feedback. The tools seem about as straight forward as an HTML editor, or text editor for Perl. Deceptively similar.
Because programmers often take up their task in a community of programmers. Insights and goals and rules of thumb get traded informally and formally in classes.
Most programmers could jump the fence with success - with similar exposure and training in the fundamentals of aesthetics, color, light, perspective, font design and application, of UI design and principles, etc.
As a “web developer” I stand somewhat between the hard-core programmer and the artsy designer.
I often grab a bit of open source code, usually from SourceForge, drupal.org or HotScripts. Inevitably, I need to “finish” it not only for its appearance, but also for the specific use. I suppose many “programmers” assume the code will be prettified and adapted, so why bother making it look like anything in its raw state.
I admit that I am a bit design-challenged, and I prefer to work with a designer (I am fortunate to know a couple of excellent designers) so I can concentrate on the architecture and function of the project. However, I can spot an egregious design flaw, like overlapping or cropped elements or mismatched fonts…
I use php/mysql and xhtml/css (Drupal, usually) so content is separate from presentation. That works well for me.
I have seen horrible programming by designers.
One designer used four frames for the quadrants of a single page brochure site, and Flash for a graphic logo. I had to optimize it for SEO, and the first part to appear in the search results was the only frame with text - so I had to add a script to display the parent frameset.
Another designer pal sent me some forms that were not working in php mail. The reason? The $_POST variables had been stripped out, nowhere to be seen… Then she followed up with a form that was only sending the last of a series of entries. The problem? Each section omitted the concatenation period before the assignment equals sign (.=) so the final set of values wiped out the previous one…
So, I ask you, is the question whether programmers can design, or is it can designers program?
IMO, either scenario can lead to unexpected results…
I am a programmer and a designer : I am programming a C++ 3D game and a PHP site package by myself from scratch. I design websites on Notepad only.
But on the other hand my education is art only - art high school, and currently in an art Academy, my programming is self-taught…
So I would say I am deep into both, but I consider myself to be an artist - not a programmer OR a designer…
This is a very widespread and also stupid belief - such people who can make both design and programming DO exist.
This is called being narrow-minded, also like putting applied arts below fine arts.
I think programmers can design, and designers can program. While it’s true some have no interest in doing the other I think the problem is people tend to limit them selves, few of us are born geniuses or child prodigies most of us had to learn and work at what ever it is we do well. If a person doesn’t get discouraged or let others tell them they should stick to one thing there’s no reason anyone can to both.
Programmers “can’t” design and vice versa simply because it’s different professions. Just like how an accountant can’t be a scientist and vice versa. They CAN, but it’s completely different professions to train for, so they often DON’T do both.
If you mean simply Graphic Design and Computer Programming, then, sure, it’s a logical possibility that someone would have both skill sets. They may be different, but they don’t interfere with each other. They also don’t reinforce each other and the likelihood that someone would be talented in both is low. ON THE OTHER HAND, if you mean Interaction Design and Programming ON THE SAME PROJECT, then I think the case can be made that there is in fact interference between the two sets of concerns such that no one “can” do both well. One shouldn’t think AT ALL about implementation issues while one is designing the user-system interaction (there needs to be a distinct process for assessing the cost of doing things and accepting or rejecting designs based on that - it shouldn’t happen through self-censorship by the designers). Programming can proceed much more smoothly and coherently if the issues of Interaction Design have been addressed in advance. If one can somehow keep the two activities and the mindsets that go with them entirely distinct, then OK, otherwise, they will foul each other up. Generally, within the framework of a single project, the only way to do this is to have separate individuals performing each of these functions (which in turn leads to increasing expertise in the distinct fields, which leads to an ever stronger argument to keep them separate).