For an industry that prides itself on its analytical ability and abstract mental processing, we often don't do a great job applying that mental skill to the most important element of the programmer's tool chest: ourselves.

“You're a what major, again?”

For many years, while interviewing for programming positions, I had to answer this question over and over again - because if it wasn't already obvious, I wasn't a Computer Science major in college. Or any other science, in fact. My degree is a Bachelor of Arts in International Relations, graduated 1995 from the University of California at Davis (Go Aggies!). If you are surprised, dear reader, believe you me, the thought of a Liberal Arts student interviewing for programming positions in the late 90s was, somehow, only slightly more incredible to some of these HR folks than a bear wearing a tutu playing AC/DC's “Thunderstruck” on the bagpipes while on a unicycle.

Despite that entrenched resistance to non-CompSci candidates, I still managed to find a few positions willing to “take a chance” on a candidate with some apparent C++ skills, and lo and behold, before long, I had a career. And people stopped asking me about my degree in college.

All of that was more or less behind me until today, when while reading my online copy of Foreign Policy magazine, I happened across an editorial/opinion piece entitled "The Five-Minute Commencement Speech (or, what IR theory can teach you about living a happy and productive life)", by Stephen M Walt. Reading through it, I felt a kinship to the author, not to mention a surge of vindication.

So, with that, indulge me a column, and allow me to explain what international relations theory can teach you, the programmer, about living a happy and productive life as a programmer.

Lesson #1: Change is the New Constant

Walt writes, "Until a few centuries ago, human society changed very slowly. It took more than 50,000 years for the world's human population to reach 1 billion, but that number has doubled three times since 1800. For most of human history, people were born, lived, and eventually died without experiencing significant social or technological change. And until a few hundred years ago, most people were unaware of the vast majority of societies that shared the planet with them. By contrast, today we live in a globalized world of mutual awareness and where the pace of change is positively dizzying. None of us know what will be humanly possible a few decades from now, or how scientific advances and diverse cultural forces will reshape attitudes, social interactions and political institutions.

“My advice: get used to it. Embrace it. IR theory tells us that globalization may wax and wane somewhat, but the pace of change is not going to slow. Nothing is forever - not vinyl records, not CDs, not the latest smartphone app - and some of our cherished notions about politics and society are headed for the dustbin of history too. Norms and beliefs and theories that millions once held sacred seem like barbaric relics to us today, and some ideas that you think are unquestionably true right now will look foolish to you a few years from now. This process is called learning, and if this university taught you nothing else, I hope it taught you that changing your mind is not something to fear.”

I really wish I could tattoo this entire pair of paragraphs on every developer's forehead. Far more so than the world itself, our industry continues to move at breakneck pace - in fact, we're part of (if not the core of) what's driving all that change in the world. Consider this: Without Twitter or any of the other social media sites, could the Arab Spring happen?

More importantly, though, look at the pace of tech in our space. Within a decade, mobile platforms went from a “maybe, someday, we'll have something close to as cool as what they had on Star Trek” to practical reality. (Matter of fact, the tablet or phone on which you're reading Walt's article is capable of things the Star Trek writers never imagined possible.)

You think this is going to change? Embrace it. Think your chosen language will be the last one you ever program in? Think your chosen platform will exist forever? Talk to the DOS developers, the Windows 3.X developers, the COM developers, and, yes, of course, the developers who spent years working on hard-drive compression utilities.

Lesson #2: Learn to Write and Talk Well

If the current discussion around working from home and distributed companies has taught us anything about programming, it's that effective communication is fast becoming more important. Think about it: if all we really had to do as programmers is put our heads down and type furiously on the keyboard, why do so many companies seem to be making so much money off of communication tools? Trello, HipChat, Slack - the list goes on for days. Programming is clearly a communicative process, as much as some old-schoolers may want to pretend otherwise, but being able to express yourself clearly - whether in a meeting, code comments, or email - is absolutely critical.

Brace yourself - bad news is coming, and you probably already know what it is: Most of us are terrible at it. Matter of fact, let's be honest, many programmers got into programming in the first place to avoid having to talk to people. More than once I've had a developer tell me they prefer computers because computers are deterministic creatures and people are not. Communicating with other people is hard work.

Here's the good news: this is a fixable problem. It doesn't take a ton of work, but it will take time and practice. Just like learning a new programming language, it begins with reading, and it happens through practice. Read about writing; Strunk and White is the Kernighan and Ritchie of writing, the place everybody begins. Pretty much anything by Stephen Pinker is a good follow up. As a matter of opinion, just about any non-technical non-fiction book is a good follow-up. Read. Examine why the writer seems able to communicate the clarity of his thoughts - how did she approach the subject? What was the organization?

Start a blog. Don't settle for poor grammar or typographical errors. Ask a friend to copyedit, or find an editor online somewhere and pay them (!) to teach you what you're getting wrong.

The same goes for public speaking. Sure, programming is a communion of programmer and compiler/interpreter, but then you have to stand in front of a room of other developers and customers and explain what you did. Or why what you did works better than what they wanted you to do. Or why their million-dollar idea is entirely irrational. Wouldn't you prefer to be someone who can command the room's respect with your speaking skills while trying to tell them that they're all idiots? You don't need to be Scott Guthrie or Scott Hanselman - because (sssshhhh) they didn't used to be those guys, either. It takes practice, just as anything else does. Start by volunteering at your local user group.

Lesson #3: Be Reliable

“In international politics, states cooperate more readily when they believe that their partners will live up to their promises and abide by prior agreements. There's a vast literature on this topic, and one of the things it teaches is that if states want to work effectively with others, a reputation for reliability helps.” This isn't just about showing up to meetings on time; this is also about delivering what we promise, in the timeframe we promise it, within the budget we promised. Reliability is a reputation earned, not just handed out.

This doesn't mean that you agree to everything put in front of you - part of that reliability is a willingness to call BS when you see it and refusing to agree to expectations that are outside of your abilities. (Notice that I refrain from using the word “impossible” - nothing is impossible, it just may not be possible for you, or me, or anyone else we know personally.) When a customer demands something you can't do, then it's up to you to say so. But it's also up to you to figure out what you can do that would meet them some part of the way.

Lesson #4: Think Strategically and Plan Ahead

“World history is filled with suffering that occurred because national leaders didn't think through what they were doing and didn't have a coherent reality-based plan of action. Germany started two world wars for foolish reasons, lost them both, and millions of people died in the process. The Soviet Union threatened world revolution and built a vast military machine, which led the world's most powerful states to join forces to contain it until it collapsed. George Bush consciously decided to invade Iraq without the slightest idea of what he would do once Saddam was defeated. These governments (and many others) allowed myths, delusions, and wishful thinking to guide their decisions, and the world paid an enormous price for their blunders.”

Ah, if there is one lesson that history teaches those who would lead nations, it's that planning is important. Not just the immediate planning of “how will I accomplish this task in front of me,” but planning for what will happen after that...and after that, and after that, and after that. Military staff colleges “wargame” various scenarios all the time, so that they can present the President with suggestions and predicted outcomes. In fact, this was part of the thought process that went into the Architectural Katas ( when I put them together. As a developer, you need to be planning on two levels, both what you are working on and how your career will progress beyond the current day job. What do you want to do? What's your career goal? When do you want to retire? If you can't answer these basic questions, how can you know if the next job offer you receive is advancing your career or just another code-slinging gig?

Lesson #5: Choose Your Allies Carefully

And if there's any other lesson history can teach, it's that choosing allies can make or break a nation's survival. The United States has proven to be a good ally in two world wars, but arguably less so in Vietnam, Afghanistan, or Iraq. Italy historically has had less great a reputation. Poland discovered the USSR to be a poor treaty partner at the start of World War II. The list goes on, and on, and on.

In technology as in politics, choosing your allies - your coworkers - can make a huge difference. A good manager can make everything effortless for you. A poor manager can push your productivity to zero. And while some of us get to pick and choose coworkers, most can't. This doesn't mean neglecting them is a viable option. Your interaction with your coworkers will define how well they rally to support you when you're under the gun - and that will be more often than you might think. Their willingness to stand by you will often parrot your willingness to stand by them under similar circumstances, and the same will be true of your management. In any company larger than one person, there will always be politics - but these need not always be “negative” politics if you approach the discussions as “win-win” negotiations.

Just as most nations aren't hell-bent on psychopathic behavior, neither are most coworkers. Assume, despite the temptation to believe the contrary, that your coworkers are rational actors. They're behaving this way for a reason. What do they want? What are their goals? What resources are they craving? Find ways in which their goals and interests align with your own and push those positions. Even the crankiest coworker can become a staunch ally if you show them that you're genuinely interested in helping them achieve what they want and/or need.


International Relations isn't going to make you a better programmer, just as Computer Science isn't going to teach you how to be a better communicator. But contrary to popular opinion, both sets of skills are necessary to be an effective developer and will be for the foreseeable future, particularly if you look for opportunities to grow vertically in the industry (whether as management or as a “chief scientist” somewhere).

It's really a simple list. Embrace change. Learn to communicate well. Be reliable. Think strategically. Choose your allies well.

Maybe that liberal arts degree wasn't such a bad idea after all.