As a developer/designer, I spend a lot of time getting this _exact_ message across to developers who "don't do design" and designers who are afraid of code. I've given that same schpiel many times before -- in almost the exact same words ("false dichotomy", "labels", "we can be skilled at anything we dedicate ourselves to").
What's wrong with being a developer and saying that you "don't do design"? Even in the context of this article, that can very simply mean that, you've never done design and therefore aren't good at it because you haven't worked at it. (This is certainly true for me; even though I'm both a talented coder and musician, I've never spent an hour trying to get better at design and hence don't try to foist my mediocre design skills on anyone.)
Becoming a great (or even a competent) designer or developer takes time and practice. There are no shortcuts.
The issue is that many of us think that without becoming great (or even just competent), there's little point to attempting it at all. That's where I come in.
Both design (a very diverse field, with sub-specializations and sub-sub-specializations, et cetera) and software development (ditto) are _disciplines_. You don't have to master them in order to become conversant with the fundamentals.
Designers can learn the rudiments of programming. Variables, logic, control of flow. These are not difficult concepts to master, and they are universal among languages. Even the principles of object-oriented programming are accessible without going to a four-year college.
The same is true of design, however skeptical programmers may feel about it. Artistic ability seems to be innate, creativity so hard to define that programmers write the field off, like wishing that you had red hair when it is brown. Nothing could be further from the truth.
Others have pointed out in the comments that the best course of action is to start small and localized. Learn about typography; it has a lot of impact given that we read a lot of text on our screens, and it's a field with a lot of simple, prescriptive rules. Learn a little about cognitive theory—how our minds process our sense of sight, and how you can help the viewer's mind process your message more efficiently. Learn a little color theory.
As software engineers, we are constantly learning a new language, a new framework, a new version of something. I fail to see why design topics are verboten in this regard, except for irrational fears. You're going to suck at first, but is that really different than how good you are the first time you pick up a foreign framework and start playing with it?
I think you might be surprised at how much you can contribute and recognize in a collaborative design environment. If just one person spoke up at an architectural design session (well.. meeting..) about how they hate how they cannot tell which way a door will open, there would be many less frustrating doors in my life :)
Inexperience at design means that you shouldn't be leading but that does not mean you cannot contribute!
Unfortunately while this may work for design, it doesn't go the other way with programming, and so I then cast doubt on it working for design. I've never had opening problems with doors, so obviously I wouldn't think about designing them differently. I highly doubt I'd be the guy to think "Hey, we should put a 'push' or 'pull' sign on this door!" Several weeks ago someone posted on HN the fact that on some cars, the windshield wipers speed up automatically as the car speeds up, and vice versa, and concluded that the people who originally designed the wipers had never driven in the rain before. I've driven in the rain many times, and such an automation never occurred to me. My mind is elsewhere.
As others mentioned, maybe if programmers wanted to, they could put in the 10k hours and be designers. The tricky word there is want, and it's not very easy to change core desires. And wanting isn't always enough, some people can put in the 10k hours and still suck. Some people can immerse their minds in a subject and still suck. To me, all-equal ability is as mythical as natural born ability.
If you're just starting out, you have to break it down a bit into some of the component parts. Typography, composition, color. Print design is different than web design. 3d design is another thing entirely; and so on.
Let's say the goal is print design. Get hold of a layout program, such as Quark, InDesign, or Illustrator. Start by doing basic things like business cards and letterhead. Work on just the type first. Use only 1 font at first; then different weights of the same typeface. Then start trying to add in drawn elements or even just geometric shapes.
Remember: if it doesn't work in black & white, it won't work in color. When you are ready for color, keep in mind that the 3 strongest colors in design are black, white, and red. Black and red are the easier of the three; so put extra attention into the use of white (negative space).
I'm a programmer who isn't so hot with design. But I certainly know how to use a program to layout objects;
that's trivial to learn on the grand scheme of things.
What I (and other non-designing devs) don't get is how to know what "doesn't work". I have at most a fuzzy idea of what are considered good and bad designs, much less how to produce them.
One of the biggest issues is the lack of feedback. With beginning programming, you are getting constant feedback from the computer. It even tells you where you are going wrong (line numbers, variables, etc.)
Design lacks such an objective feedback system. Sure, there's the times when your friends will agree that iteration B is superior to A. But actually getting feedback on what to do next? Pretty tough.
Time to learn the term "design brief," which relates to the design like a program specification relates to the program.
What is the design supposed to accomplish? What should it convey? What kind of reaction should it elicit from the viewer? While these ideas may not be completely objective, they can be expressed in written form. Doing so is one way to bring some objectivity into the the process, as well as a way of keeping everyone "on the same page." Adhering to the spec is a also a good way of finding out if your spec is useful or not. If you find the design veering away from the brief, go back to the beginning and start again; re-write your brief, and re-iterate the design.
Now a quibble about your mention of knowing how to use a program to lay out objects. (Note, "lay out" is the verb and "layout" is the noun.) One such "object" is of course type, and learning how to size, lead, track and kern your type is more than just placing objects (letters) in proximity. Knowing how to use the program is one thing; achieving great visual results is another.
How to learn what works and what doesn't? Get some design annuals, subscribe to design magazines, start reading design blogs. Most importantly, find a good designer who will critique your work. All of these activities will develop your eye and your design sense.
In my opinion there is nothing more frustrating than starting working in a layout program. I usually just end up feeling like I am moving crap around on the screen until something sticks.
The best way to start is to hear how a well spoken designer will explain their client's problem, how they worked through it, and pick it apart. This will help you understand the dynamic conversation between elements that occurs in design. I would recommend reading a few books from older, well regarded designers who's work has stood the test of time. Paul Rand, Herbert Bayer, and designers from the Swiss design movement stand out as good examples of clear, well reasoned design that is easy to understand.
While doing this, I would recommend that you try taking some of their designs, and recreating them. Try making a version that looks web 2.0 like, one in black in white, etc.
Personally, I don't think you can learn design without appreciating it first.
A good place to start is to study Bauhaus. There's tons and tons of books on Bauhaus. It's ridiculous how influential Bauhaus was on everything in western culture.
I don't know, I was really into design in the past, and am probably more designery than most devs, but I wouldn't do TOO much reading.
Design isn't about how much knowledge you've accrued, it's mostly a journey of self-exploration through work, and looking hard at what you've done in relation to yourself and others.
If you can find someone who will give you an encouraging AND bullshit free take on your work, that'll be a huge help. Oh, and remember how much your first code sucked? Your first design will suck just as hard.
I usually know what I want with web design and know how to use html/css to get me half way there. It really becomes more efficient though to then hand the vision off to someone experienced with design to get the rest of the way.
Sure I could spend a lot of time to learn how to take it to say 90% but I think a lot of the time that is better spent focusing on my core areas.
I guess this is similar to a designer who will jump in and modify view code to work better with their design, but leave the heavy lifting on the backend to the programmer.
Identifying myself as something of a developer/designer, I'm always interested to see what others are doing. There's no info in your profile, got a blog or something?
Can't upvote this enough.