[phomer]

Programming and Graphic Design are opposites. Logic, reason and lots of self-discipline makes for good programmers. Art on the other hand is grounded in emotion and perception. It's more about escaping discipline, while allowing yourself to get in touch with some inner irrational being (so that you don't mess up the design with logic and symbols). Art touches you, while programmers build things. Graphic Design in some sense, is just the industrialization of Art for specific purposes (although often less emotional).

It's best to realize that a good Graphic Designer can outrun a programmer in the same way that a good programmer can outrun someone that can't think logically, although some programmers seem oblivious to this. If you need good Graphic Design, it is best to hire a professional that is well suited to the task.

If you really want to try to bridge the two worlds, then a degree in Graphic Design is a good idea. Drawing, painting and photography are also good hobbies that can help you develop an aesthetic. A good reference to start with (and explain why logic and rules fail) is Drawing on the Right Side of the Brain. It's an old classic, but helps in understanding how our brains interfere with our perceptions.

[Zev]

Programming and Graphic Design are opposites. Logic, reason and lots of self-discipline makes for good programmers. Art on the other hand is grounded in emotion and perception.

If you think there aren't "rules" to graphic design that are typically followed, you're fooling yourself. Just like there are times when the best answer to something in programming isn't necessarily the intuitive or logical answer.

[phomer]

There are "rules of thumb" which nice people have put together, but they are just a starting point. If you follow the rules pedantically or even closely, the results won't be good. They're just hints to get you going. It's not about obeying rules, it's about how it looks.

The book I referenced is a great resource in explaining why this is true. Part of the brain sees things symbolically, so that when someone is drawing a face for instance, they don't draw what they see as the eye, instead they substitute a symbol in its place. To the person drawing this might look OK, but to other people it looks like a kid drew it. To get good at drawing, you have to shutdown that symbolic part of the brain, and just draw what you see, not what you think you see.

[Zev]

Rules was in quotes for a reason. Yes, there are a bunch of "rules" that are generally followed. Except when they aren't. Hot and cold colors, mixing font families and types up, etc.

A good designer will know when to break the "rules". Like a good coder will know when to hack something together, rather than obsessing on architecture and keeping code "clean". Its all perfectly logical. Except when they said "Fuck it, it will work better this way."

Massimo Vignelli had his grid, but David Carson threw it all out the window. Coder X might spend a few days writing his code in what he thinks is a clean, maintainable manner, while Coder Y might hack it together and worry about maintenance later. In both cases, both approaches can be right.

[phomer]

A designer breaking the rules will generally enhance their work. A coder violating an architecture will often just create long-term technical debt, at the expense of some short-term gain. That is, they'll get their piece done faster, but leave in its wake a nasty problem for someone else. Of course that only applies if the architecture is reasonable and its rules are correct from an engineering standpoint. In practice, many of the 'coding rules' are too brittle for the circumstances, thus making things worse, not better.

The difference is that one change is done purely for the improvement of the aesthetics, while the other is done because of some fundamental disagreement about the underlying engineering principles. One change is done irrationally because it "feels" right, while the other is a disagreement on the nature of the rules (or a lack of understanding of the purpose of the rules). But there are rules (whether or not they've been articulated).

Usually when programmers "hack" things, they cause a raft of other problems in their wake. As software development progresses from an art, to a science and onto engineering, hopefully the desire to hack at things will diminish. We can actually reliably build complex systems, but only when we choose to think about the right way to do it, rather than just react to our environment. Personally I don't think good programmers "hack". They build. It's very different.

[thereddestruby]

Re: Drawing on the Right Side of the Brain: You're projecting. The whole book is about following a system that teaches you to draw.

[phomer]

Actually it is deeper than that. It's really teaching you how to see... (and then draw what you see).

[thereddestruby]

Exactly. It teaches you how to draw. An orange is just an orange to me unless I'm drawing it. Then it becomes an orange I have to focus on while I draw.

[blahblahblah]

What the book is really teaches you is to not see an "orange" at all. The process is pre-verbal. By the time you see "an orange", the information you need to produce an effective drawing of it has already been condensed down into a verbal token and your attempts to draw it fail because you're drawing the visual archetype stored in your brain instead of the specific spatial pattern of hue and value that is in front of you. The exercises in the book are intended to help you gain access to your visual processing pipeline at a lower level before object recognition has been applied.