So, building on the first installment of this series, lets take a look at what, in my opinion, is the largest difference in the two fields. Execution, or the way in which the objective is achieved.

Execution: Designer

When a designer comes on the scene, it is her job to take the wants, desires and vision of the client/customer and visually realize them. To make ideas a reality. While this is incredibly thrilling and satisfying, it is also fraught with peril. Your customer feels a certain ownership over the visual aspects of the project, as well they should, and they usually begin to "suggest" additions or subtractions to the design you are working on.

This isn't a problem until the moment that a suggestion doesn't jive with what you as the expert knows to be right. Then begins the great dance, wherein you attempt to convince them of the error of their ways, and they ignore you and continue asking for a picture of their cat be added to the logo.

To make matters worse this usually moves beyond the bounds of the customer, to the customers friends and family. Quickly your well crafted masterpiece can become a myspace website. And since the customer is ultimately paying the bill, you will lose in the end.

Now, lets say this up front. The picture I have painted for you is by no means the only way things can go down. I am sure there are a number of you designy types that are given complete and total freedom when executing on the vision the client/customer has. My experience and that of a great many designers I know, is this is not the case.

Execution: Developer

In contrast to the frustration that I just laid out for you, the land of the developer is filled with rainbows, ponies and unicorns. In most cases the customer will never see the code that is written to achieve the objective, and even if you wanted to show them the awesomeness they would politely decline.

They just don't care.

All the customer/client cares is that the code you write achieves the desired effect. They don't care if it is object oriented or procedural. They don't care if you used a framework or if you rolled your own system. Hell they don't care what language it is in usually. They just want it to work.

All this adds up to bliss. The only person I have to care about pleasing with my code is me, if I love it and it achieves the stated goal the world is a big ol' bucket full of win. End of story.

It was very eye-opening, and liberating, the first time I sat with a customer/client and began showing them the code and explaining what was going on, looking for feedback, and the customer stopped me. They had no idea what I was talking about, and didn't care to. They just wanted to know if when they hit enter did the widget change.

It did, I win and I am the big hero. It was like a new day had dawned. From that moment on I decided to, with very few exceptions, only design for myself from there on out. The frustration just wasn't worth it to me anymore.

Alright, I think I have pontificated enough on this subject for one day. As always comments are open, and twitter replies are being pulled in. Happy discussing.

Part two of this series "Execution" is now live. Go check it out!

Recently at $work, where I am in charge of herding the cats in the engineering department, I took some time to hammer out my vision of where the company could go with its core product. This meant I was creating feature specs, design and UI mockups.

I had a blast doing so, and I think the result was fairly well thought out, beautiful and most importantly, compelling. After the presentation to those above my pay grade, which went well, the obvious question was asked:

"Wow Chris, I didn't know you had this skill set, why are you over in engineering?

Indeed, if I have talent, drive and vision when it comes to the creative side of the business, why on earth am I over in the stodgy, boring world of development?

The question, and the eventual answer I gave started me thinking about the larger picture of why I made the move from design to development professionally. I still operate in both worlds in my own work, but I have very firmly hitched my horse to the development wagon. Why was that exactly? The answer it seems, is much more complex than one would think at first blush.

Setting the record straight

First of all, lets set the record straight. There is nothing stodgy or boring about development. If that is the way you feel, you're doing it wrong. Development can be one of the most challenging, creative and beautiful things one can ever do.

The beauty can be harder to see, but that doesn't mean it isn't there, in abundance. As I started thinking about the decisions and actions that have led me to this moment, I can begin to see why the development path became the more appealing to me. Today I will talk about the foundational concept that the rest of this series will be built upon. Philosophy.

Philosophy: Designer

The designer is looking to create a compelling, beautiful experience for the user. In achieving this result the designer draws from a wealth of tricks and techniques that build up the UI. There is a very definite additive process to this.

I wouldn't say that there is a disregard for efficiency and simplicity, but they are definitely more apt to be sacrificed upon the altar of the experience. Agree with my assessment or not, you can't argue that the entire creative process is based on adding, not subtracting. This isn't a judgement call or an attack on designers. It just is.

The designer asks the questions:

"What do I need to add to this page to make the user experience better? How best can I communicate what the user should do next? What would make this less ambiguous?"

The answer to some of those questions could be to remove something, but more than likely, it is to add something that better demonstrates the elements use, function or meaning.

Philosophy: Developer

In contrast, the approach taken to development is subtractive. How best can I achieve my goal, with the least amount of code and the least amount of duplication and effort. Simplicity and stability are the two most important aspects to any piece of code written.

The developer asks the questions:

"What is the quickest, most elegant way to display this data to the user? Have I written code already that does something like this that I can re-factor so that it now handles the previous task as well as this one?

The challenge, or beauty in my opinion, of development is in the efficiency and drive for simplicity. The best piece of code is one that is obvious what it is for when you look at it, is incredibly efficient when you execute it, and is stable when you depend on it.

Ultimately, I think it is this difference in philosophy that draws me more to development. I don't see anything wrong with the philosophy that is usually employed by designers, it just doesn't resonate with me the way the core tenets of development's philosophy does.

Well that is it for this introductory entry. The next installment will deal with the most satisfying difference, in my mind, between the two paths. As always comments are open, and I ask that you be civil to one another.