Programmers Vs Designers

Those who can, program. Those who can't, design. -- EricHodges

Those who can, argue. Those who can't, quip. -- so quipped RichardKulisz. :)

The left side of the equation applies equally to all technical experts (engineers, 99% of architects in reality) and the right side to all creative experts (good authors, exceptional architects, artists, et cetera). The basic idea is that they are different.

ProgrammingVsInteractionDesign are different activities
Programming vs designing require mutually exclusive values

Plagiarism is considered a good thing in engineering circles (a good way to learn, educational and so on), and an abomination in artistic circles. Redoing someone else's work is anti-design. Actually, Plagiarism as it relates to publication is considered a bad thing in both engineering and artistic circles. It's considered a good thing in both circles purely as a learning tool. There is no distinction. Plagiarism as it relates to publication in artistic circles is considered appropriation or sampling. Artistic circles are the place where 'good/bad' thing have no useful meaning.

ProgrammingVsDesigning require mutually exclusive mentalities and are based on fundamentally different brain wiring.
- XP casts suspicion on this claim.
- If XP results in a good design, then it's by accident. XP is based on having no high-level design.
  - No. XP is all about keeping your high-level design in a state that can accommodate change without failure. There all all kinds of XP practices that give a high level design, and most programming teams should have a huge whiteboard with the current design anyway. And yes, this applies to any definition of high-level you care to take, within the scope of a software project. -- DaveFayram
- Any critical thinking casts suspicion on this claim. RK made it up. Until he shows us scientific studies backing up his claims of programmers and designers having fundamentally different wiring, it's just bullshit. Mutually exclusive mentalities are a far cry from immutable differences in brain wiring. Mentalities are changeable.
Programmers are incapable of coming up with a GoodLanguageDesign, designers are capable of designing products they'll never use and designing them well
- Some of the best languages I know of are made by programmers. Smalltalk, Ruby, Python, Lisp, Objective-C... all were designed by people who were, in some capacity, a programmer. Other languages that never quite made it were designed by committees.
- You do realize that this page is full of generalizations, yes? And that we're not interested in the freak 1% who can successfully cross between programming and design? And perhaps you'd have grasped this if you'd read the corresponding page. Or perhaps not, but either way your comment would be on a more relevant page.
- You do realize that its difficult to think of even one good computer language that wasn't designed by a programmer, right? Name one. It doesn't even have to be terribly successful, just interesting, powerful and usable. COBOL and Java need not apply. And, "good" doesn't mean "successful" here, it means conceptual purity, along the lines of whatever a designer thinks is good (you get to go wild here!). Heck, I'll throw you a bone. It doesn't have to have been implemented, just show me a whitepaper or description somewhere. -- DaveFayram
Expecting technical know-how from designers is idiotic
- Yet some designers seem to have a fair degree of ability in this field. I guess some designers are better than others.
- No, some designers are just freaks. Or they're willing to put up with a lot of shit that compromises their ability to design. And saying that a designer is "better" if they have technical know-how is exactly the kind of idiocy that's disputed on that page. But I guess you didn't read it. Huh, I'm not dealing with anymore of your comments.
- Way to dodge the hard ones, Richard. You have decided it compromises their ability to design, but I've never seen any place where you offer any evidence supporting this claim. "Socrates is a man, therefore all men are Socrates" won't fly here. I've read all pages in this node, and I find no evidence to support this claim, merely statements. -- DaveFayram
Designers are good at ThinkingOutOfTheBox, engineers are good at thinking within the box
- See above example about programming languages, and consider that many of the revolutions in computing and HCI as we know it were designed by people we'd consider to be programmers.
programmers value a design for its results in a product and value the product for its own sake, whereas
designers value a design for its own sake and value a product for its results in users
designers value ideas regardless of realizability, engineers value artifacts regardless of consequence; this is why the A-bomb was a triumph of engineering
programmers try to get into design, designers try to get out of programming
- Untrue. Some interaction designers actively program and continue to do so. The late JefRaskin for example, according to his site.
programmers think designers are unnecessary, designers don't have such luxury afforded them by economics
- This entire site is the home of a school of thought that says design is so important that everyone always has to be engaged in it to some degree.
if other designers previously came up with the same design, then that proves the designer is competent
if other programmers previously came up with the same program, then that proves the programmer is incompetent
- Completely untrue. Counterexamples: Mono, SchemeLanguage, OpenOffice, FireFox. The general opinion is that these people are doing the community a valuable and difficult service.
if a designer knowingly repeats previous work then they're wasting their time
if a programmer knowingly repeats previous work, then they're gaining valuable experience
- This is not universal. See DontRepeatYourself. See also PaulGraham's musings on SoftwareEngineering. See also ThePragmaticProgrammer. For examples of this in action, see the documentation to RubyOnRails, which is designed entirely around removing the repetitive work from WebApplication design. See also Apple's Cocoa documentation. Cocoa revolves around trying to remove repetitive work (persistence, preferences, UI, serialization, binding of data to UI objects) from application authoring, freeing the developer to worry about the design and the unique code.
ideas which everyone knows (eg, array vs list stacks) are valuable to a programmer and worthless to a designer
- Is there any evidence to support such a claim?
  - Designers might wish to use a higher level of abstraction - rather than concerning themselves with a "list" or a an "array"; they just know they want a LIFO or sequential or associative data structure. Or they may not even care about that, and just know they want a collection.
  - But sometimes they do care about the nature of it (LIFO, FIFO) for interaction purposes. Therefore, the claim above is false. Trust me when I say the vast majority of programmers don't care about the implementations of their data structures either. Languages are moving people further and further away from such details. See Python and Ruby and Perl for examples of the direction this is moving.
the value of a completed implementation is evident to non-programmers, the value of a completed design is not evident to non-designers (though this is mostly due to a lack of tools and education which is in turn due to the dominance of programmers over designers)
I have yet to meet a productive systems designer who was not capable of being a good programmer.

What a silly distinction. All good programmers design and if a programmer wants some feedback on design he can ask another programmer. That's like saying you can write a good chess program without ever playing chess, or that chess players would have no useful input on how a chess program should be designed. The context is inextricable. A design that fails to account for the language, database, tools and code methodology is less useful than a programmer's design. Pure designers by definition strip the context of the application's implementation, thereby making their designs inferior.

Actually Big Blue was programmed by people who barely play chess and without any input from chess players. Wrong. The DeepBlue project retained several grandmasters to evaluate its play and opening preparation (an OnsiteCustomer, if you will).

A 'design' that takes into account the language, database, tools and code methodology is a specification. A design is not 'inferior' to a specification anymore than a sketch is inferior to a sculpture, it's a different thing and useful in a completely different way.

Designs which abstract away (non-domain) implementation details are often useful (though in the end, never a substitute for a specification or a working product). "Designs" which abstract away details of the user's problem, OTOH, are utterly useless. Unfortunately, our profession is riddled with examples of skilled programmers attempting to build systems without a good understanding of the problem to be solved, and/or the human factors necessary to produce something which is usable.

CategoryComparisons CategoryAboutInteractionDesign