One question that I always enjoy posing to people to discern their leaning as more of a designer or an executor is the “Magician Problem”. The scenario is as follows- You are in a magic show, in the audience. The magician challenges any member to figure out his next trick for monetary incentive. As he performs it and in the aftermath, each member inevitably scrambles to discern his secret using their best thought methods. The question that I find interesting here has nothing to do with the trick itself (as you may have noticed considering I never even mention what the trick is) but instead the approach used by the members to figure out the illusion.
In my experience a certain percentage of people would evaluate his performance, maybe try to watch it again, and try to figure out how he pulled off the feat. Another group would instead approach it from a different angle- asking themselves how they would do such a thing and working backwards to see if that might be how the magician executed the trick. These methods are vastly different but equally valid, and they represent two groups of people that are entirely necessary to the world of engineering and making.
The differences between those who try to immediately solve the problem and those who attempt to first generation their solution and work backwards tends to heavily underpin the architecture of the field of engineering. Examining these differences is both interesting in discerning compatible working type personalities (useful when building a team) but also when designing tools for either party.
A relatively popular example of the discrepancy is revealed when a “designer” and a “coder” are both asked to draw (as best they can) a simple shape- Pac Man. What is interesting is many of the designers started in the left top corner and drew a line around, effectively tracing the shape – in contrast many engineers simply traced a circle then using a triangle cut out the mouth from the circle, erasing the excess arc.
While this might seem like a trivial difference, it belies a deep discrepancy in how each person’s brain instinctively jumped to solve the problem. In addition to being interesting, this kind of observation can have implications when designing software and interfaces for each respective party- for example how many more groups of people might use 3D printing if the modelling software was based around the designers process and less the engineers? And what if we did the same with conventionally “designer aimed” software?
Yet when it comes to the working relationships between these Ideators Vs. Executor’s, Right brain vs. Left brain, designers vs. developers, they can be rife with animosity. To fully appreciate this rivalry we must go way back in the history of the people involved.
For many of us these sorts of labels have followed us since the earliest school days. This pigeonholing can happen early on, and can be detrimental as it tends to isolate us away from the unselected subjects. How many times have you heard “I am just not a math person” or “I am an engineer, writing is just not my thing”?
Often we are instilled with a fear of trying things that do not fall within our pre-assigned jurisdiction of “skill set”, which is damaging both the individual (I have personally met many engineers who ended up surprising themselves with their writing skills once they gave it a chance) as well as the individual’s ability to respect a representative of the “other” field in a professional or team setting.
So it should come as no surprise that with this decades long background of identity and tension we might find some issues when we are inevitably asked to work with team members from alternate skill sets.
I believe that on the darker side of this debate it boils down to a simple human tendency to lack respect for what we do not value, or know we value. We tend to internalize and develop our values based on many things, including environment, the company we keep, our upbringing, ect. But among those things is a deep desire to value ourselves, which will often manifest in tendency to value what we find ourselves to be naturally good at, and in turn we tend to not ascribe as much immediate respect to that which we do not understand.
However I do not think that we are doomed to stay locked in this age-old rivalry, especially since it can come at the expense of overall productivity both in our tools and our teams. At the expense of sounding corny, I think if we started by taking a second to just see (Not even immediate understanding) the “other” side and their valid contributions this could go a long way towards smoothing over this historically torrid relationship.