Gerry recently posted an interesting article about the mindsets of software developers and software companies. We had talked about this same topic on the phone for a while a couple days ago. The same phrase that jumped out at me then also jumped out at me while reading his post: Stop Thinking Like A Programmer. Of course, it’s the bolded opening statement of his post, so of course it jumps out at me.
But there I go, thinking like a programmer.
Analyzing why something happened, I think, is a lot like debugging. Describing how to do something is a lot like writing code. Rearranging sentences and paragraphs, deleting words, and choosing new phrases to replace others while writing this blog post is a form of refactoring, similar to what developers do to improve code quality. Adding new words to the spell checker to get rid of the annoying squiggle underline — that’s just me being unnecessarily picky.
So many of the things that I do, and that other software developers do, we do like programmers. So what? What’s the big deal? On the whole, developers (and other analytical types like mathematicians, engineers and scientists) are known for being thorough and precise. Those are good things. Right?
Yes, if you are in the process of actually writing software (or proving theorems, performing experiments, etc.). However, if you’re doing just about anything else with anyone who is not an analytical, you have to watch yourself. Some things I’ve learned over the years are that customers (or your wife, or the project manager, or you father-in-law) do not care:
- That the changes they want will be accomplished by adding three tables to the database with a foreign key to the Widget table, then using the Suchandsuch Control to display the WidgetDetail properties in a GroupBox on FormMain.
- That the hardware vendor’s newest firmware release better distributes its resources to make the scanning process more stable.
- That you will spend 4 hours on designing the data model, 24 hours building the data access objects and business objects, 12 hours on the UI, 3 hours in QA, and 1 hour on documentation.
They do care:
- Whether or not it can be done.
- If everything works right now.
- How much it costs.
They have different concerns. They have a different way of approaching the problem. They’re coming at the problem from an entirely different point of view in the first place. They’re speaking a different language. Gerry calls it Salesperonto, and I thought that was pretty clever.
Where I grew up, there were very many native Spanish speakers. Many of them also knew English, and some knew English very well. They were capable of talking to me in a language I understood well. However, when they got excited about something, or focused on something, they would often switch back to Spanish without realizing it, or worse, speak in sentences that were half English and half Spanish.
All to often, I’ve seen developers, including myself, do this. It’s dangerous for a few reasons. It can confuse the Salesperonto. It can stifle their creativity within the business domain by overwhelming them. It can bore them. It can make them think that you don’t care or don’t listen to what they are saying. There is a place for speaking Coderian, but make sure your audience is also fluent first.
Coderian is definitely my native language, but I’ve been working on my Salesperonto. I still have some practicing to do before I consider myself fluent. Does anyone know how to say "abstract class" in Salesperonto?
