This is an article about the difference between these "jobs", or "positions", or "mindsets" in regards to making things on The Internet. I think they exist within separate spheres but encompassing the same general principle of the importance/balance of creativity vs knowledge. The jobs exist in different realms, with each side weighted differently; it's the age-old left brain vs right brain, and how different responsibilities require different mixes of the two. The juggling/emphasis of each is what makes the job unique. It's tough to go from being one to being another; people tend to be born predisposed to one of them. Kind of like being introverted or extroverted. These are constructs, yes, and they can be changed, but they're often deeply ingrained in our ways of thinking. I'll cover Designers, Developers, Engineers, and Architects. (And one more at the end.)
A designer is someone whose creativity is their weapon. A designer pulls from the air, their work is ideas. Their creativity is crafted into the form of actual things - though they are usually not the ones who make that form happen. But they have the best ideas, they're supposed to be the ones who have the ideas that make the most sense. Which is why having a separate UX Designer is nonsense to me. The designer should have the social skills and the design research to know whether something will work. While ideas (seemingly) come from the air, no one designs in a vacuum. Users are made to be deceived; the best designs are ones that seem obvious but at the same time magical and original, the trick is that they just are obvious and you've probably seen it before. The designer's job is to bring beauty out of seemingly nothingness which a user would be able to understand.
Designers often become either too aware or too unaware of what they are designing and who they are designing for. They can be lost in research, trying to craft the perfect design for an intended audience, or they can be so blinded by that research or their own intuition (wherever ideas come from) that they miss any audience. Great designers, working together, almost always rely on a singular common focus; the best contemporary example of this is Apple's approach to design. Simple, elegant, ethereal. They tap into the stupidly-simple yet profoundly difficult notion of the cool. They use phrases like "it just works" and "it feels right in your hands". A designer may spend decades finding the balance between the sophistication of their approach and the simplicity required for highly usable and memorable experiential design. Again, a great designer makes the obvious so intensely intuitive that the experience feels like magic.
But how does that design go from a sketch to an implementation? If pure creativity is the lifeblood of designers, it is merely the tool of the developer, albeit an important tool. A lot of people mix up and confuse the roles "developer" with "engineer", but there's a big difference. Developers rely more often on creativity as their primary tool, while engineers rely heavily on knowledge. To highlight the word explicity: developers develop stuff. Like old-school film photographers, the good ones walk through a longer process. A photographer has to have a good eye to make a great photo, but also frequently has to have the technical skill to make that film expose and print properly to make the photo something you can hold in your hand (as opposed to something that just exists in the photographer's memory).
Developers require the ability to wield and channel creativity in their execution more than they can have the luxury of getting lost in that creativity as designers do, usually because they're in a strange position. Over the last 10 years or so, a developer is the person you'd talk to when you have a great idea for an app or a website but no idea how to make it. A developer is the most common bridge between the average person and the technical world of computers. The developer's job is to be a magician; to bring forth from an idea the actual implementation. Often an amateurish one-stop shop instead of a formalized team of designers and engineers; developers are often self-taught and informal.
The two parts of these jobs need to be meshed almost 50/50 in developers. They should rely on creativity as much as knowledge. Developers are creative problem-solvers, ruled not by calculus but instead by common sense. The creative part of the job is figuring out how to transform that idea into something real. That doesn't leave a lot of room for a wealth of knowledge, rather it requires an understanding of shortcuts. These shortcuts have become easier thanks to the internet and the creation of simpler, more straightforward programming languages. But it means frequently using the quick-and-dirty way instead of the most studied, efficient way, which is their primary drawback. Prototyping - quickly making real, functional, and minimally designed things out of ideas - is the major craft of a developer. Getting the ball rolling; generating a fast reliable result.
Developers usually don't mesh well with designers or engineers. Designers think their designs have little room for compromise and engineers always think there's a better way to write code. That's hyperbole; but I have always found developers (myself included) to exist in a weird uneasy middle-ground between the two. Sometimes an advantage, but dangerously nebulous. A developer may not have the very best most refined solution, and they might not have the most air-tight design, but they get shit done. And that's the difference: developers aren't bureaucrats. A good developer should be a beacon of progress for the sake of progress itself.
As I said, engineers know the best way. Engineers rely on knowledge. You can ask an engineer to sit down and figure out a problem in its entirety and have the path from problem to solution. And they'll have it for you, probably using the most efficient methods, in the best-fit programming language, which they've most likely studied extensively. (Hopefully not Java.) Their strength is in that totality of ability. An engineer is the one who figures out how to safely build a bridge from one side of the river to the other, and the strength of their calculations is paramount. Real engineers carry this with them whether they're building a skyscraper or programming a banking interface; their vocabulary revolves around the stakes and not their creative whims.
You can't ask them to make the solution quickly, or ask them to put a red ribbon on it. Engineers largely can't give an application a feeling or emotion or a reason to use it beyond its function. There's creativity in their job, but it's subservient to their knowledge as a means to solve a problem. Knowing how to do things isn't as good as knowing how to do things right. And to real engineers, there is definitely a right way. There's always a perfect, elegant solution because there has to be. Computers are made by man within logical limits; there's always a results-driven procedure that shows the best use of its zeroes and ones.
Engineers can be powerhouses, but they can also be monsters. They can define and enhance productivity as often as they can destroy it. A great engineer can halt production on something because they're afraid of some small potential security flaw, or simply because they doubt the integrity of their own work. This is compounded when several engineers work in concert, and reinforce each other's doubts by re-writing each other's code or simply writing code in different styles. Anyone else helping with the project will be met with obstacles because of this. This attitude toward absolute perfect execution isn't found as much with designers; they compete over ideas more than procedure, and ideas are far more maleable than the rigid definitions laid out by code.
Above these roles, having an architect can be essential. In a team of engineers, designers, and possibly developers, there needs to be someone to wrangle them. There needs to be a unified vision, and it needs to come from someone who knows pieces of each process. The architect is someone who can bring that vision, usually because they've been in one of the three roles and then transcended it. Notice I do not use the word "manager" or "supervisor", who are typically useless. An architect is someone who knows and has experience with some or all of the processes involved. A "project manager" most often just wants to get things done as fast as possible without knowledge of what that speed potentially sacrifices, usually involving politics into their executive decisions. Managers and supervisors generate bureaucracy.
The architect is hopefully the end result of anybody in one of the previous three jobs. All of the three jobs should realize that there are larger concerns than their own independent vision can show them. More than that, though, the previous three jobs may easily become obsolete with the person's own complacency. Engineers can quickly become useless if they refuse to learn a new, more robust and widely-supported language. A designer may not read into the changing of the times, and may make something that worked ten years ago but won't appeal to anyone now. In this case, a broader, more comprehensive and platform- and language-independent mindset is required to survive. As I said in the introduction, the three roles described above are just different uses of the same tools; each has the chance to become something that encompasses pieces of all of them.
Regardless, the overall problem with all of these positions is that they are rarely good enough as one person working alone. Making things well requires a collective, with a very simple and easily-defined core idea. There are, of course, various other entities (like support personelle, and nitty-gritty stuff like system administrators) who contribute, but not really to the experience of creation. It's those (typically small) well-formed and informed teams that build massively elegant projects that stand the test of time or, better yet, evolve as time requires them to.
Briefly, I'll mention here that there are no such things as Social Media Experts involved in the creative process. They're a waste of time and money. They don't exist alongside the people who actually make things happen. They might get a few other social media experts on Twitter to follow a product, but really that means nothing. Thankfully for them there currently is no way to truly measure their results, other than through means created by other social media experts. So it's a bubble that will soon burst, hopefully. Marketing a good product shouldn't be a difficult chore requiring social media experts. You shouldn't pay anyone to sit on Twitter.
That's not to discount the use of social media, merely I am discounting the reliance upon it, and the sudden belief that has grown surrounding the necessity of its usage and the throwing of money at it. Social media works well largely because it is untamable, and a product's existence within or without it seldom determines whether that product is good, or works well, or is well-designed. Great projects largely find their own audiences if the stars are right, and you don't need a social media expert to get a great product to its audience; thanks to the internet, that work is already done by merely existing. There's no such thing as intentionally making a viral video.