Technical problems can almost always be solved, but people problems are hard

By Jim Grey (about)

I’ll never forget the revelation it was when I figured out how to write computer programs. You mean, I thought, I can make this machine do what I want it to?

It was a watershed moment in my life.

I was a teen then, shy and introverted. People often frightened me, at least a little. I struggled to interact with people I didn’t know well, and to assert myself with people I did know well.

And then here was this machine that I could order around. It had limits, but within those limits, it was all about what my mind could imagine and then code. I wrote games that my dad and my brother played. I wrote programs that illustrated concepts of geometry, which I demonstrated to math classes in school. I wrote a payroll application for my aunt’s small business. I even wrote a very rudimentary operating system once – it was terrible, but I learned a lot.

So I went off to college to learn more about how to make software. When I graduated the job market was terrible, so I took the only software job I could find, which was writing user guides for a software company. Later in my career I moved into testing, and into management. I’ve delivered a lot of software since I started 29 years ago.

Here’s the crazy thing I’ve learned: The hardest thing about making software is not the technical stuff. The hardest thing is getting people aligned and pointing the same way!

I’ve often said that it’s a modern miracle when a software project succeeds. Any software development project that involves more than about two people will have coordination challenges, differences of opinion, and all the other normal issues of working together. My experience has been that the programmers and the testers can do whatever you need them to, short of, say, developing a telepathic user interface. They will work hard at it and they may struggle to get it right. But those struggles can pale in comparison to how hard it is to get everyone to agree on what to build, how to build it, and what it means to be done. Here’s how code is better than people:

Code	People
Once coded, code stays coded and reliably does the same thing over and over.	You think you have people all organized and then they go off and do whatever they want anyway.
You will sometimes struggle and work hard to make your code do what it needs to, but you can almost always get the job done.	Sometimes you simply can’t influence people. Drat their free will.
Change your code, it doesn’t mind. It knows no fear.	People hate change! When change is thrust upon them, they often resist it or even run away, screaming.

By the way, the WordPress editor doesn’t offer a way to create tables, so I wrote some quick HTML to generate one. Fear my mad, l33t sk1llz.

Unfortunately, even if you have the best coders in the world, if you can’t get them to work together their projects will fail. Fortunately, I understand geeks, for I am one. I know what makes us tick. I’ve learned how to influence us and get us all reasonably pointing the same way. And I’ve built on these skills to learn how to influence non-geeks such as upper management, salespeople, and customer service folks to get them all working together. It’s not easy, and it’s impossible to ever get it perfect, but I’ve had pretty good success over the years and it’s contributed strongly to any number of successful software releases. And it’s helped me come out of my nerdly introverted shell.

I can’t remember the time I last wrote any serious code. I don’t miss it. To my astonishment, I’m having much more fun and success on the people side now.