Only one of which is a computer programming language.
At work, we’re designing a new product. It’s a process that involves non-technical users, IT managers, programming colleagues, me, and the computer. It involves a lot of talking, a lot of language. At one end, it’s making sure the users are happy with the system’s capabilities. While talking to them, we use non-technical language, diagrams, and demonstrations. Way at the other, it’s actually typing code.
This makes me think it might be useful to split the languages we’re talking into four;
**User Langage:** Non-technical, example-laden, visual, and concrete. This is where you get into general discussions, produce photoshop mockups of the system, draw rough-and-ready whiteboard pictures, write XP user stories, write user manuals.
**Manager Language:** Your manager needs to know the technical and algorithmic overview, but he doesn’t need to see every class that’s going into the design. This language is the language of high-level functional specs, some UML diagrams, conceptual diagrams.
**Colleage Language:** At this level, you’re going to have to assure yourself that the code you write and the code your colleagues write start meshing together. Precision starts being important, and a real burden. Probably where most of the real thinking goes on. I think one of the reasons Pair Programming works is because it forces you to get into a lot more of these types of discussion, which reduces the possibility that the team’s work won’t gel together.
**Self Language:** This is the idiosyncratic, outboard-brain style of writing that you get into to make sure you understand what you need to be doing. This can be personal pseudocode, notes-to-self, todo lists, or code comments.
**Computer Language:** The code itself.
I think a great deal of the actual design and thinking involved in creating new products goes on above the level of the computer language. When people discuss, say, “Python Vs Java” or “Ruby vs Lisp”, it’s valuable enough, but the choice of language probably isn’t that important in determining the success of the project. I think these language strata go some way to explaining why. Most of the communication goes on between people.
Steve Cooper's Personal Blog 
2 responses to “Five languages for talking about programs.”
I’m heavily involved in the User Language section of this, but I don’t really pay much attention to any of the other languages, as I’m the technical author, not a coder. And I come from an eng lit background not a codemonkey background. There are times, though, when I’d like to get to know the rest. It’d be interesting, and I wouldn’t have to rely so much on the programmers for finding out what it is I need to tell the user.
How do you find you are at Userese? Can you pitch it right?
At work, one of the guys is an old-school computer programming engineer. In order to get any information out of him, it’s often a game of twenty questions. He speaks in binary. In order to get the right information, you have to phrase the question precisely. We don’t let him loose on customers.
Our audience is really our consultants — non-technical but familiar with the product. We do demos, where we can, and that seems the best way to get feedback.
If you want any help ‘learning the rest’ — say, learning a few bits of a programming language — then give me a shout and I can get you started.