[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.