Check out the new book by one of our favorite authors Peter Psichogios

Leading from the Front Line: Learn How to Create Exceptional Customer Experiences.

Click here to learn more about Peter's new book!

5 Things Writing Code Can Teach us About Working With People

I’m a writer, not a programmer. But I spend much of my life surrounded by people who write code and it’s hard not to cultivate at least a passing familiarity with something that permeates your work environment. You’ll know what I mean if you’ve ever jumped into source view in your content management system, or asked a co-worker to explain that strange combination of English and…whatever…on the monitor.

Feeling a bit like a stranger in a strange land, I decided to learn a little about the local customs and language: just enough to help me feel a little more at home. After completing a few introductory computer programming courses through Codecademy, three things occurred to me.

  1. Memorizing the phrase book doesn’t make you fluent in a foreign language!
  2. There is some real validity to the whole right brain/left brain thing. For example, trying to think like a computer physically hurts a predominantly right brain.
  3. Aside from understanding how to program computers, writing code also offers some important lessons about understanding in general.

Yes, in my never-ending search for meaning, I took the following lessons from my experimental foray into computer programming.

1. It’s not just what you say; it’s how you say it

In programming words matter. A computer can only do exactly what it’s told to do. But what it’s told to do must be communicated in the right form, with the right syntax, and based on the right requirements or it will be misinterpreted. And each language is different. To be effective, you have to master the nuances of the programming language and make sure you “write it right.” You also have to be sure you understand what’s required and that you’ve accurately communicated those requirements. As an example, consider this version of a common inside joke among programmers:

“The programmer’s husband asked her to bring home a dozen eggs and bacon—she brought home 12 of each.”

Computers (and sometimes programmers) interpret things literally and sequentially, so how you say it really matters.

In the world of human dynamics and interpersonal communication, words matter too. But so much is communicated by tone, tempo, and facial expression that the words being used are subject to misinterpretation and may go completely unheard. Just as a line of code with broken syntax, or instructions that rely on inference can break a program, how you say something often makes the difference between a successful transfer of meaning and a communication train wreck!

2. The importance of coming full circle

As I cursed the noncommittal text editor on my screen, another fascinating parallel (between dealing with computers and dealing with people) struck me. Computers need closure. For everything you tell them to do, you have to tell them when to stop. Every tag you open must be closed. Every process initiated must be halted, and every byte of memory allocated released. If not, “baggage” accumulates, bugs wreak havoc and stuff simply goes off the rails.

The same thing happens in the workplace when intended messages get derailed and the resulting people challenges go unresolved. So much of what makes people struggle with thier co-workers and managers is caused by loose ends: thoughts left unfinished, lack of follow-through, leaving people hanging and incomplete (or non-existent!) feedback loops. No one wants to carry around that kind of baggage. People need closure too.

3. Getting to the source is not about blame

When you write code and something doesn’t go according to plan, you start debugging. The default assumption is that the error is in the code. Since the computer can only do what it’s told, there must be a problem with the instructions. Through systematic review and retesting, you identify the root cause of the problem and fix it until everything runs the way it’s supposed to. Once a problem is fixed, you may add a test or put a system in place to prevent it from happening again. In software development, finding the fault has nothing to do with assigning fault. It’s just part of the iterative process.

When communication breaks down between people, it can be a little more complicated since both the transmission and interpretation of messages are prone to error. Many people focus on the other person’s inability to “get it” when things go sideways. I can’t help but think the programmer’s approach, of assuming responsibility for the miscommunication and systematically searching for its source, is a great way to tackle human miscommunication too.

4. We are not alone

While some might suggest that the emergence of true artificial intelligence is just around the corner, that’s not what I’m referring to here. We are not alone because few programmers can excel alone. Writing code is a solitary activity. Writing excellent code needs multiple eyes. Just as a professional writer relies on an editor and proof-reader, good programmers appreciate a consistent code review process.

We all strive to work effectively with others. And we could all benefit by a little review from time to time. If you haven’t asked someone at work to objectively review your interactions with co-workers as well as your deliverables, chances are you’re missing opportunities to polish your work and to learn in the process. No one excels alone: not computer programmer or anyone else.

5. Some things aren’t fixable

Every so often, all the debugging in the world doesn’t make a program work as intended. When that happens, you have to throw the code out and start from scratch.

Likewise, with relationships and workplace dynamics, occasionally something isn’t fixable. Sometimes the potential benefit of solving a problem doesn’t justify the amount of effort it will take to do so. And sometimes no solution exists given the current level of knowledge and resources available. When that happens, it’s time to move on—whatever it may involve.

Whether or not I continue this coding journey, it was fascinating to discover meaningful parallels between two areas often seen as polar opposites. Here’s hoping it will help me communicate better with the programmers at work!


Workplace communication is easier when it’s social (and logical!).  Experience Social HCM with NetSuite TribeHR. Sign up for your free 30-day trial today.


Photo Credit: Image by Stuart Miles, courtesy of

Link to original post


Leave a reply

©2016 Human Capital League Your business online - made simple!

Log in with your credentials


Forgot your details?