3 minute read

🎄Merry Christmas 🎄! Full disclosure: no, I’m not writing a blog post instead of spending Christmas with my family. My blog posts release on Saturday, but they are almost always written earlier and saved for later.

Ask anybody to describe a stereotypical programmer and you will probably get a lot of phrases that boil down to socially awkward. A classic Office Space scene comes to mind.

"I have people skills!" yells Tom Smykowski in a scene from Office Space

What people never tell you about the software engineering job, however, is that you really do need people skills. So much time is spent talking about writing code and hunting down bugs, but very little focus is put on the human aspect of the job. Software requirements do not appear out of thin air - they arise out of conversations with users. Often, those users are not technical people. Translating the needs of a normal human into technical requirements and translating your technical hurdles into normal human language is a highly important skill that gets completely glossed over in schools.

At my current job, our customers are state employees. If you have ever tried to go to a government office at this time of the year, you know that things more-or-less shut down towards the end of December. In order to get some feedback on our development before everybody disappeared for the holidays, we had a quick demo with the customers. In an effort to catch problems with our design early, we demoed code that was running locally on our development machines.

If you are reading my blog, I am going to assume you have some sort of software development experience. You probably know just how messy a codebase can get while you are working on it. It’s a lot like when I decide to really clean a room. I almost always pull everything out and make dozens of piles before sorting those piles back where they belong. If you walked into a room I’m in the middle of cleaning, you’d probably think it looked like a disaster. Same goes for any code I’m working on. If you look over my shoulder while I am working, you are going to see errors, a console full of log statements from JavaScript, and a ridiculous number of //TODO comments all over the place.
If you were a customer and saw that, it probably wouldn’t inspire confidence, and customer confidence is what drives sales and makes sure we all keep our jobs.

All of this is exactly why you probably shouldn’t ever demo straight out of your local copy of the code, but when you want feedback on changes that aren’t deployed yet, you do what you have to do. This is where those “people skills” come into play.

To be totally clear: I am not a naturally social person. In a lot of ways, I am a very stereotypical programmer. My years in the Air Force forced me to get good at public speaking, but I still walk away from every social interaction with shaky hands, feeling completely drained. The whole thing boils down to a performance. I’m not a social person, but I play one in customer meetings. In the case of a demo out of my local code, that performance is less like acting and more like a magic trick.

Magic is all about getting the audience to look where you want them to look. Yes, look at me wave my hands around mysteriously. Definitely don’t notice my assistant who is escaping through the trapdoor! So last Friday, I was sharing my screen, presenting to a dozen state employees, and dancing around the code I knew was broken. Another programmer on the team stumbled across a new error, but continued to chit-chat while he switched to a tab that wasn’t broken (the code demo equivalent of palming a card). When the demo was done, I walked away from the computer and let out a huge sigh of relief (with my mic muted, of course) - another social interaction completed without incident!

So if you think you want to be a programmer because you are not good with people, oh buddy, have I got news for you. People may not talk about it much, but customer interaction is a huge part of a software engineer’s job. So work on your people skills, people! Otherwise, you’ll have to find a new career - like inventing the Jump to Conclusions mat.

Updated:

Leave a comment