I have a tutorial at OSCON this year entitled Simple Ways To Be A Better Programmer. Initially this was just going to be yet another rehash of my "How To Be Lazy Without Really Trying"/"What Works In Software Development"/"Introduction To Software Engineering" tutorial that I've been giving for a number of years. But somewhere along the way in writing this one its changed focus. Half of the tutorial will be about the usual stuff as promised in the description: refactoring, reuse, iteration... coding issues. But the other half is going to be about something programmers are universally bad at.
I've been learning how to cook, mostly from a show called Good Eats which could be subtitled "Cooking For Geeks". The associated book, I'm Just Here For The Food does have a subtitle: Food + Heat = Cooking. This simple pseudo-equation neatly sums up the point of the book, learn about your ingredients and heating methods and you'll be a good cook. Accurate? Not really. A poignant and useful teaching aid? Yes!
Here's mine: Computer Science + People = Software Engineering. Algorithms and data structures and technologies are just one half of being a good programmer. Learning how to deal with and manage people is the other.
Now you're thinking "Wait, what?! People?! No, writing software is about computers!" Unless you're one of the few doing pure computer science research then people are intimately involved in the process. Take programming languages. That would seem to be firmly on the "computer science" side of our equation. But what are programming languages? Or better yet, *why* are programming languages? If it were all about computers we'd be programming in machine instructions, the very alien language of computers. But we don't think that way. Computers are discrete, binary and precise. Humans are analog, decimal and imprecise. Programming languages are translators between human thinking and computer thinking. The driving force behind modern computer languages is to allow humans to write code more and more like humans speak to other humans. Programming languages fall firmly on the "people" side of software engineering. Implementing them falls more on the CS side but few pepole write compilers as their day job.
"People" can be broken down into three broad sets. The first is the most important: "You", the programmer. How are you? Are you having fun? What are your problems? Your goals? Is work swamping you? Does your own code scare you? Probably the most important topic we'll cover about you is "how to learn" which is exactly what it sounds like. Most of us were last in school 5, 10, 15 years ago or more. We are inadvertently trained that learning is something that happens as a group, at a certain time, in a certain building, with a teacher, about a specific subject. And often its not an enjoyable experience. You go to school in the morning, you learn, you leave. Maybe you do some homework but for the most part learning happens at school. Now you're out of school and have a job and no parents to mooch off of and maybe a family and responsibilities. You have neither the time nor the money to go back to school again. Now that there's no school, no teacher, no parents to mooch off of, no structure, no special time and place to learn... how do you learn? As an adult you have to relearn how to learn. My tutorial will start you down this road. [1]
The second set of people is "Other Programmers". They look like you. They think like you, very analytical. But they're not you and you can't order them around. You work with them and their code. They're your teammates and competitors. How do you communicate with them? How do you deal with their code? Their style? How do you convince them off your point of view and how do you accept theirs?
Finally there is "Everyone Else". While lumping all non-programmers into one category might seem dismissive its meant to be poignant. Everyone else is the reason you write code. Everyone else are the people who pay you so you can live and write more code, the users and customers and boss. Everyone else doesn't think like programmers, they are not analytical, they are not devoted to doing the right thing. They have different goals and problems and you have to figure out what they are. Communicating with everyone else requires a different mode of thinking, try to speak to everyone else as if they're other programmers and watch their eyes glaze over. Everyone else are not idiots because they don't understand computers any more than you're and idiot for not understanding how to run a business, you each lack the other's domain specific knowledge. This is a gap to be bridged and we'll look into bridging it.
We, as programmers, don't put much effort to learn about people. Don't believe me? Check out the list of OSCON tutorials this year. How many are about people and how many are about technology? Technology is a "hard" subject in the sense that there are immediate problems with clear solutions. You want to run a web site, here's a web server, here's how you install it, how you configure it, how to make it run faster. People are a "soft" subject. Squishy, hard to nail down and difficult to analyze and generalize. We shy away from soft subjects and as a result we're horrible at them.
Soft subjects involve problems that lurk sometimes unrealized, sometimes ignored and worked around. They represent a small, steady, cumulative drag which can lead to an unspecified dissatisfaction with your job. Soft problems are complex and unique and don't lend themselves to easy or clear solutions. The problem is best solved by the individuals involved. Often the best thing which can be taught about soft subjects is how to identify the problems and the tools to begin solve them. Simply realizing what the problem really is often leads to a resolution. And that's what I hope to do with this tutorial.
[1] I have been referring to this tutorial, in my own head, as my most arrogant yet. I have to be very presumptuous. To get up in front of an audience of hundreds and tell them what they know, what they don't know and what they want to know takes some chutzpah. I may be wrong but I have to go ahead as if I'm right.
Like how you're saying programmers think analytically, I agree that it's really important to realize that different people think differently than you, and that these ways of thinking aren't necessarily inferior or superior. For example, Organics vs. Mechanics, or the different Myers-Briggs personality types. (Whether you agree exactly with the categorizations, I think the important point is that there are different kinds of personalities that we should keep in mind.)
Not all programmers are analytical, either. For example, my colleague and I are both programmers, and (as I've mentioned to him) are on opposite ends of the Organic-Mechanic spectrum. I'm Mechanical and tend to methodically solve problems, but that can be very slow sometimes. He's Organic, and sometimes brilliantly jumps to quick solutions but can also overlook certain issues.
Another example, I'm extremely introverted. Attending meetings exhausts me, even if I don't say anything, because it's like people are sucking out my energy. But for extroverts, not being able to communicate is like cutting off their fuel supply. Having direct, to-the-point meetings where the conversation proceeds rationally (like I'd much prefer) is stifling to them.
