Sign up to get our featured articles delivered straight to your inbox every month or two.
RSS feed of all articles
Follow us on Twitter
Alternate dimensions
An Insurgency of Quality
Making pagination meaningful
Are programmers tiny gods?
Tim sparked an interesting discussion around the office last week when he circulated a post from Derek Powazek's blog called "Programmers are tiny gods." It offers a provocative analogy for the designer/programmer relationship:
Programmers are the Gods of their tiny worlds. They create something out of nothing. In their command-line universe, they say when it’s sunny and when it rains. And the tiny universe complies ... So if you’re working with a programmer, you have to treat him or her like a God. You have to pray. You cannot issue edicts. You have to come on bended knee. “Here’s the problem I have. I need a solution. Please help.”
It's from a series called “Things I learned the Hard Way.”
Tim McCoy: It's a nice insight into the psyche of many development organizations. This is meshing with a sentiment I’ve heard a lot lately: “Don’t tell me what to build. Tell me what you need built.” It’s a subtle distinction that replaces the feeling of micromanagement with one of empowerment.
David Fore: Right. But this sentiment begs a fundamental question. When a programmer objects to being told what to build, how can biz decision makers ensure they aren't wandering into the weeds, building a taco stand rather than a playground, let's say. In other words, taken to the extreme, this sentiment means the inmates shall run the asylum. Alan, do you want to rewrite your book?
Tim McCoy: For me, it doesn’t challenge the notion that design has the responsibility of describing the product and development the responsibility of creating it.
I recently had a conversation with a developer who said “I want the definition of behavior as soon as possible, and I want to delay the definition of implementation for as long as possible.”
The issue is that being told what to build is a command, not a dialogue. Being told instead what needs building is an invitation to collaborate. That acknowledges programmers as professionals with expertise designers don’t generally have. (In turn, it assumes programmers acknowledge designers as professionals with expertise they don’t generally have.)
Programmers then have the flexibility to assess what building that thing would entail, express concerns over feasibility, timeline, motive, etc., and offer alternatives or adjustments that impact their ability to be successful.
So it’s about removing the friction to object to in the first place. Derek is being sensational with the bended knee bit, but the sentiment is sound. The payoff of his post is this:
The good news is, programmers want their work to be used, and the good ones know that the design matters. So programmers and designers actually have the same goal: getting the stuff used. If each can honor the talents of the other, great things can happen.
It’s about approaching developers as co-conspirators in producing great work: designers know what needs to happen and developers know how it can.
Lane Halley: I think you’re right on when you say “being told what needs building is an invitation to collaborate” and that designers and developers can be “co-conspirators in producing great work.” However, there are some nuances to the situation.
I think that when SW developers are removed from business decisions about what they are building (e.g. work for a salary, or code for hire), there’s a sense of relief when someone, anyone, steps up and takes ownership for the “what” of the product. However, at many companies, this responsibility for the “what” isn’t totally owned by Designers, it’s a space shared with Business Analysts, Product Managers and other folks.
I’ve also seen small teams of collaborative generalists at Web 2.0 companies and startups who have a different attitude. Those folks don’t think of “design” as a separate role, it’s more like an activity, or a skill set that has to exist within the team, somewhere. SW developers who work in this environment feel a greater sense of ownership of the product, and expect to be involved in defining the “what” too.
Tim McCoy: That’s a great point. The dynamic in a small team, startup, or indie development shop is usually much different from the situation Derek describes. I think it’s a side effect of the traditionally down-stream role developers have in larger established organizations that leads to this outlook, and why it’s design’s responsibility to say “hey, I’m not coming down here to drop a spec on your desk, I want to talk about how we can solve this thing.”
Filed under: Design & engineering, Trends
Comments
Having experienced this first hand 15 years ago in a former career I find it interesting that this challenge persists. I think what you said here hits the heart of the matter "The issue is that being told what to build is a command, not a dialogue. Being told instead what needs building is an invitation to collaborate."
Yet the biggest challenge I have seen to collaboration has been establishing the mutual respect for each others contribution that you point to as necessary. And I think it goes way beyond expertise and knowledge. I think what gets missed when either party assesses the value brought to the table by the other is the context, thinking and perspective they bring. That is what allows us to deal effectively with the complex business problems we face today. In the end success requires a collaborative effort of give and take, not just a hand off. And the best point of hand off can't be pre-determined, but rather must come from a negotiation of what will work best in this situation.
Arthur C. Clarke wrote "Any sufficiently advanced technology is indistinguishable from magic."
In the preface of his excellent book The Pattern on the Stone, Danny Hillis writes the following:
I etch a pattern of geometric shapes onto a stone. To the uninitiated, the shapes look mysterious and complex, but I know that when arranged correctly they will give the stone a special power, enabling it to respond to incantations in a language no human being has ever spoken. I will ask the stone questions in this language, and it will answer by showing me a vision: a world created by my spell, a world imagined within the pattern on the stone.
Mystics? definitely. Geomancers? sure. I'm skeptical, however, about elevating programmers to the pantheon.
Incidentally, Hillis's following statement is "[a] few hundred years ago in my native New England, an accurate description of my occupation would have gotten me burned at the stake."
We need to get over the notion that programming is some kind of arcana and that developers are some kind of mystical beings.
I can't wire a house, but that doesn't make my electrician a descendant of Loki in his world.
And just like I don't tell the electrician HOW she should wire the house -- she knows the building code, understanding what the best practices are etc. -- I do tell her where I want the outlets, the location and type of lighting I'll need etc. and I expect her to know what needs to be done to optimize those requirements.
The same holds true for software developers. They make their contribution on how best to meet product requirements.
Why not elevate Marketing to god-like status? There's a function that is truly arcane and mystical and even successful marketers will tell you they're not always sure why their efforts are successful! :-)
Saeed
My office manager acts more like a "tiny god" than any of the 15 or so programmers I've hired over the last 10 years. She understands that it takes an entire company to develop, market and sell a product -- everything that's required to pay all of our salaries. With a few exceptions, my experience with programmers is that they think they are gods when they're really just one of many employees working toward a common goal. Please don't encourage them to think otherwise.
I'm sure I cannot be the only one to see the irony in this article.
Essentially, this says that "only designers know what they're talking about".
Perhaps there should be an article entitled "Why do Designers think they're gods?"
Barry, how about backing up that statement? Where are we saying anything about designers having dominion over the truth and all deeds? It's a matter of responsibility: the person responsible for the design of a system should have the skills, insight, and opportunity to determine its purpose, shape, and consequences in the hands of those who will use it. No different than how anything else in history has even gotten built. Does that mean that those who take this responsibility must be Gold Certified Designers? Of course not. Does that mean that those who take this responsibility can't also be programmers? Of course not. But it does mean that those who do this should know when design ends and construction begins, and in software that can only be done through mutually respectful collaboration.
I've learned this exact lesson the hard way, and still struggle with it on occasion. As a product manager and UX lead, how I communicate requirements ultimately depends on who I'm talking to. Not all developers, teams, or company cultures are created equal.
I will say that, even though execution is the most important thing, creating an environment where designers and developers actually enjoy their work should be a high priority. I consider close collaboration during the creative process as core to creating an enjoyable experience for both designers and developers.