I have an adage I like to trot out from time to time: "You cannot solve sociological problems with technological solutions." It's a wonderful, useful phrase, one that causes my team to want to pun by the time I say "solve" because they have heard it so much. Yet it appears that my adage has never been more true than it is now.

There's an ongoing debate about maintaining civility in online communities. StackOverflow has discussed their version of this problem several times in their short history, and now we are starting to see this issue spread to other sites that want to encourage community, such as GitHub. It's always the same problem: people are being rude to one another, and other people are pissed off at the rudeness (whether or not it's directed at them personally).

I've been thinking quite a lot about this problem. It seems, to my outsider's view, that all online communities have this issue, or will eventually. On first glance it's easy to say that certain online communities are not inviting new people, even actively discouraging them from joining. I think this view is shortsighted. The issue not that people are generally mean, or rude. The issue is that the very few people who are mean or rude have their comments exist in perpetuity, and given enough time, come to represent (fairly or not) the community as a whole if nothing is done about them.

Lifecycle of a Community

Communities are a fragile thing. When they are new, they are inviting, willing to take on all peoples and all problems. The people who "get in on the ground floor" as it were become respected members of their community, to whom other people look up to and respect. In the beginning, the community is on equal footing, so everyone shares everything equally. The problems arise later, and they have to do with the very nature of the Internet and people: namely, the Internet "remembers" everything, but people need to forget.

IT'S THE CIIIIIIRCLE OF LIIIIIFE!

People tend to remember bad experiences more readily than good ones. The problem now, in online communities, is that because the nature of the internet is to "remember" everything, nothing ever gets forgotten.

As a community grows and adds new members, so too does that community's knowledge pool. This includes not only what people seek in asking questions, but also tangential ideas, unwritten rules, and other etiquette which is rarely written down but will still be adhered to. Given enough time, the respected members of the community, the "elders" as it were, start to notice when their rules of etiquette aren't being adhered to.

In the best case, these elders issue gentle reminders that these rules need to be followed in order to be a member of the community, but in the worst, the elders lambast, make fun of, ridicule the knowledge-seeker as being someone who "didn't do the research." The people who are targets of these slights tend to come to the conclusion that because this one individual thinks their question is stupid, the entire community must think so as well.

In short, the elders unwittingly become the oppressors. This happens entirely without their consent, and sometimes without their knowledge. But it happens.

And once you have oppressors, you start to have oppressed. The people who were rejected or treated roughly by the community they once sought to join are now stunned, shocked, heartbroken. They merely wished to be a part of the group, and now the group doesn't want them. They might channel this frustration into something useful, like starting their own community, or finding a better way to ask a question. They might simply give up their endeavor altogether. One thing they are guaranteed to do, though, is talk; given enough people, the odds of someone talking and venting their anger rapidly approach 1.

The Internet is, in theory, egalitarian. It gives everyone an equal platform for their voice, their opinions. But the Internet remembers. As the shunned people become more numerous, they start to voice their opinions, their issues with the communities that shunned them. They write diatribes about how their once-longed-for community drove them away, and other people start to take notice. They gain allies in the perceived fight to come, the fight for the soul of these communities that started as welcoming but evolved to forbidding.

Those who still believe in the mission of said communities also take up arms. The extreme fringes of this group begin painting the shunned as people who didn't do enough research, or should have been in the group from the beginning if they really wanted the knowledge they supposedly sought. Of course they didn't get a good answer, they didn't ask the right question! They paint their perceived enemies as oppressors themselves, bad actors wishing to steal the soul of their beloved community by polluting it with poorly-researched questions and demands on the members' time.

We started with communities, and ended up with armies. And then we get a war, a war in which no winner is possible and everyone ends up pissed off. A war with no good outcome.

We will fight in the forums and in the tweets! We shall never surrender!

Be Nice!

It seems, from the outside, that this kind of war is inevitable, a tragic and unavoidable path down which all online communities will eventually travel, and this is because the solution to avoiding this war requires both sides to assume good faith in the other. To be fair, comparing this kind of virtual mud-slinging with actual war is a bit exaggerated (but what is the Internet if not collective exaggeration?) The members of the besieged community must assume in good faith that the askers have done some research, at least attempted to answer their question; and the learners must take it on faith that someone will deign to help them. It seems to me that good faith is in short supply.

The solution to this conundrum is known, and not technological: civility. Patience with our fellow man, understanding for where s/he is coming from, kindness when dealing with them. We were all knowledge seekers once, and the good ones among us still are. Civility, however, requires time and effort. I will argue that people have a limited supply of these things, and it can easily become a fool's errand to use them on someone who is no more than a series of words on a screen. It becomes easy to disregard the importance of civility when one's time or effort runs low.

But we must keep on. We, the "elders", who are the de facto gatekeepers for our profession, who have the power to decide who feels welcomed in programming and who doesn't, must be civil, and to all parties, real or not. That is our responsibility as leaders.

Civility online, despite our haphazard first impression, isn't dead, it's just more noticeable when it isn't there. But the lack of civility is a sociological problem, and requires a likewise solution. At the risk of being cliche, said solution is simple: Be nice to people! Yes, even them! It is on both sides, the elders and the knowledge-seekers, to remember that we are all in this together.

It was almost imperceptible. A slight shift in her gaze, a miniscule shake of her head, a flash behind her eyes. She knew, and then I understood. I had done it again.

I didn't mean for this to keep happening. Really! Interruptions like these just slipped out, before I had a chance to rein them in, to hold them back. I might have read an interesting article, saw a cool TV clip, listened to an engaging podcast. I learned things, and enjoyed it. What was the problem in sharing my knowledge? They'd want to know too, after all. Doesn't everyone?

I said it, and as I did she gave me that look, the one I'd seen so many times before. The look that says "come on, not this again." The mingled disappointment and resignation and half-buried hope were clear as day, just for a split second.

She rallied admirably; she kept the conversation going with barely a hiccup. Our friends that had come over for dinner didn't even notice. You'd have to know my wife like I do to be able to realize that something had happened. But I do know her, so I did realize. For being weightless, thoughts sure do hit you hard.

I was that guy. I was the guy that told you all about the things you thought that were wrong, the things that you believed that were incorrect. I was the guy that spouted opinions as facts, that proclaimed my beliefs and understandings as the true way of the world. The ones who try to make you believe you've been in the wrong this whole time. I did none of this intentionally, often not even consciously, but it happened all the same.

I was the "well, actually..." guy. And it took me thirty years to realize it.

I don't think of myself as an opinionated person. I doubt any of us do. That doesn't mean I don't have opinions, just that I don't think of myself as a person who needs to shout those opinions from the rafters. I like what I like, and so can you, provided you admit you're incorrect.

I am also a programmer. In my mind, this contributes significantly to my "well, actually" syndrome. Computers are inherently stupid machines. At heart, they understand two possibilities: on, and off. Everything ever produced by computers has been made by manipulating groups and collections of these states to compose something far more interesting. Consequently, programmers tend to think of problems in binary: either it works or it doesn't. Either it's right, or it's not. It's strikingly simple, even elegant, in the way that life isn't.

I want to know, and I can't stand not knowing. I want to understand, to learn, to grow, so I can put it all together. I want to be seen as smart. I want to comprehend my world as fully as can be imagined. I want people to know that I know things, that I am intelligent, that I am worth knowing. Doesn't everyone?

And in her look, I saw the problem. Was I just trying to help, or was I trying to be smarter than them? Three times in four minutes, she told me later, I had corrected someone who was talking. Was I really trying to be helpful? Or had I mistaken my insecurity, my need to be seen as smart, for magnanimity?

I looked. I saw. And I understood.

That was a year ago. Now, in the present day, I'm making efforts to not be that "well, actually" guy. Efforts like trying to not interrupt people, picking my verbal battles, or just saying "cool, man" and letting it go. Efforts that remind me that even though I know things, that doesn't mean everyone else needs to. Efforts which I think, I hope, I pray will start paying off soon.

In the meantime, I keep going. Life doesn't stop because a realization thirty years in the making knocked you on your ass. The difference is, now I occasionally remind myself that well, actually, I might have been in the wrong this whole time.

]]>

"She's a project," my boss said to me. "She's green, and even though she's been working here for several months, you should consider her like a brand new college graduate. She'll need a lot of oversight, a lot of hand-holding and you'll still be expected to finish

"She's a project," my boss said to me. "She's green, and even though she's been working here for several months, you should consider her like a brand new college graduate. She'll need a lot of oversight, a lot of hand-holding and you'll still be expected to finish your projects on time."

"Excellent," I said.

I'm not sure why my boss felt the need to warn me. Melissa is a new, green developer. I know that; I knew that from the moment the coding section of the interview began. She had trouble with the FizzBuzz test, stumbled over the differences between an abstract class and an interface, and generally showed that she needs some experience. This ain't my first interview; I know she's a newbie, that's she'll need some help (maybe a lot of help) to get started.

And it doesn't friggin matter. I'm happy to have her on my team.

We need junior programmers. And I don't mean my company specifically, I mean our industry as a whole. This profession runs on the backs of the juniors. They're the one who get the crap work, who check the nitty gritty details, who learn and advance and become seniors and leads and managers. They are the people who will eventually replace me. I'm not scared of them; I want to see them succeed. But to do that they're going to need teachers, mentors, someone to help answer their questions.

I've been saying for a long time that what this profession needs is more teachers of technology. The problem, I'm now beginning to realize, goes much deeper than that. The real issue is not a lack of people willing to teach others, it's a lack of compassion in doing so.

The odd thing about programming is that it's entirely mental (with all the different usages of that word applying). There's no real physical component. Sure, we type on a keyboard, but that's the result of the mental work in progress, not the end goal. And it's tiring. Programming is mentally exhausting work. If the brain is a muscle, then programmers work it to the metaphorical bone each and every day. Good programmers solve people's problems using code in an efficient, skillful manner.

When you think about it, that's also the issue with teaching: it's a mentally exhausting job. Now, instead of trying to work out problems, you're trying to work out how different people learn and then teach to their skills, which is infinitely more difficult that just solving static problems. People are dynamic, changing, varying from one to the next. If you're a good teacher, you can innately understand how people learn, and then construct situations in which they will acquire the skills they need in the most efficient manner.

Here's the rub: the skills that make you good at programming (solving problems) and the skills that make you a good teacher (solving people) are not, and never will be, fully compatible. You can be the greatest damn programmer in the world, and yet anybody you try to teach will be just as bewildered as before, if you don't have compassion for the learner.

Compassion bridges the gap between teacher and learner. The less skilled you are at teaching, the more compassion you need to have for your learner.

(I'm tempted to use the word patience here instead of compassion, but you can be patient and still not be compassionate. It's the difference between a boss needing work done and a teacher helping a student study; they might both wait a long time and be perfectly fine with that, but the boss will simply expect the work to be done, while the teacher will understand why it took such a long time and work to help the student improve that.)

Look, not everyone will be a good teacher. Not everyone will be a good programmer. But those of us who are in a position to help others learn should take advantage of that. At the very least, attempting to teach others will help your communication skills; by describing a problem, you increase your understanding of it, otherwise rubber duck debugging would not be a thing.

But everyone can be a compassionate teacher. I can, you can, even newbies like Melissa can. Skill doesn't matter, ability doesn't matter; compassion matters. Compassion is what makes a good programmer into a great teacher.

So, bring it on, Melissa. Bring it on, junior devs. We need you. And we'll be doing our level best to be compassionate, to be teachers, even if we're not very good at it. Despite all our misgivings, despite all the hate and impatience and intolerance you might run into out there in the wilds of the Internet, there are still those who want to see you succeed, and are willing to use our compassion to help you reach your goals. This industry runs on the backs of the junior developers, and we would be loathe to forget that.

I had a meeting with a customer (let's call her Kate) last week, and she wanted some changes to a web-based messaging application that my group owns and manages. That meeting didn't exactly go as planned.

Blame Tennis

I had a meeting with a customer (let's call her Kate) last week, and she wanted some changes to a web-based messaging application that my group owns and manages. That meeting didn't exactly go as planned.

Blame Tennis

Here's how the conversation between myself and Kate went:

Matthew: OK, so the request you submitted said you wanted the icon on the task bar to flash orange whenever a message comes in from the messaging application, right?

Kate: Right.

Matthew: Unfortunately, that kind of thing is basically impossible in a web app.

Kate: What? Why?

Matthew: Well, it's a completely different environment. The old app was a Windows application, where this kind of thing is trivial to do. But now, the app is a Web app, so it's a totally different environment.

Kate: I don't understand.

Matthew (exasperated): ...See, the web app only exists in the browser, and the browser exists in Windows. But the code can only call it's container. So the web app can call the browser, and the browser can call Windows. But the web app cannot call Windows.

Kate: You just said it could. The app can call the browser, and the browser can call Windows. So the app can call Windows and make the icon flash orange.

Matthew (confused): No. That's not how it works, because if it did work that way it would be a massive security risk. Imagine a malicious website being able to screw with Windows without you downloading something. That would be incredibly bad.

Kate (desperate): But the old app did that!

Matthew (resolute): Right, I know, but that was a Windows app, not a Web app. Making the taskbar icon flash in a web app is basically impossible.

Kate (angrily): It can't be impossible! They did it before.

And around and around we went. She wants something, I say we can't do that the way she wants, she says "but you did it before," ad infinitum. It's an endless game of blame tennis, where she serves with "we did it before!" and I return with "we can't do that now!" over and over until one of us collapses from exhaustion. It's maddening.

Throughout the game, it struck me as odd that she held steadfast to the idea of "well you did it before, why can't you do it again?" Because, to me, the very idea of a web app making Windows do something is preposterous, laughable. It's so far removed from "normal" web development as to be obvious to even the most junior web programmer.

But that wasn't at all obvious to Kate, and I should have known that would happen.

Basically Magicians

Developers, programmers, tech people in general (yes, including me) often forget that to all the people who don't work in the tech world, we are basically magicians. We take abstract ideas and turn them into concrete applications by using indecipherable texts and acronyms known only as "MVC" and "IDE" and "HTML". We are wizards using tools and laws that seemingly break the rules of physics and are seldom understood by persons who are not part of our "exclusive" club.

With that kind of power comes the responsibility to explain ourselves, clearly and thoughtfully, without resorting to name-calling or annoyance. Because, despite our myriad skills, varied experiences, and entirely different tech stacks which we work on daily, to the vast majority of people it's all just software. It's all the same.

This is the key thing that I failed to remember in my conversation with Kate. To her, to anyone who doesn't deal with these things on a regular basis, it's all just software. It's all 0s and 1s and true and false and math and colors and little buttons that won't do anything and links that don't open new windows unless you count to 6 and summon Beelzebub. It's all just crap that gets in the way of doing their job. If they didn't have to deal with it, they wouldn't.

Check Yourself

Kate and I eventually reached a point where we could solve some of her other issues with this system, and she felt pretty good about those agreements. We never got a resolution on the taskbar icon flash thing, and we never will. But eventually we got to a consensus where she understood why this was impossible, and can now go to her boss and try to find alternate solutions (like providing her teams with two monitors each instead of one). We got to a resolution, it just took a while.

We could have gotten there faster if I'd left my attitude at the door.

It is not the customer's job to know the ins and outs of our daily lives. It is our job to explain it to them, so they will know that we are not magicians but craftsmen, plying a trade and solving their problems with code. It is their job to explain to us what they want us to do, so that together we can work up a viable plan for getting their needs met. Both sides must do their part in order for anything to get done.

Nobody wants to play blame tennis; everybody just wants to find a solution. Leave your racket and your attitude at the door, and we can work it out together.

A few days ago I was summoned to a meeting where one of the most basic ideas a web programmer can have wasn't obvious to our non-technical customers. Something had gotten lost in translation, and now I had to try to explain myself.

Our customers (let's call them Kate and Harold) wanted us to develop a web site that would allow users to type some answers into a questionnaire on a webpage, then take those answers and insert them into a PDF document that would be placed in their document database. We needed to keep these questionnaires for review later by our internal auditing group. All of this was completely doable, since we already had the PDF document template that we could insert values into.

While the programming group and the customers had had some emails being flung back and forth, discussing the various ways we could implement the system they wanted and the amount of time it would take, something just wasn't clicking for the customers. It should be said that this group of customers is very non-technical, and so they called a meeting to ask us programmers (specifically me, being the lead programmer on this project) some questions about the kinds of things we could do to implement this questionnaire system.

The meeting went pretty well for the first twenty minutes or so. Then, Kate started asking about what would happen when the content of the questionnaire changed:

KATE: So what would happen if we added a question to the questionnaire?

ME: Well, we'd need some time to work up a new template and add the question to the webpage.

KATE: That takes too long. Can't we set up the tool to allow us to just edit the webpage ourselves?

ME: We can certainly do this, but I'm not sure why you would want to. You want to be able to edit the questionnaire?

HAROLD: That's correct. We can incorporate changes a lot more quickly than we can now if we have this. How long would it take to set this up?

ME: Not too long I think, since we already a foundation for this kind of change in place.

KATE: Perfect!

HAROLD: Let's just be clear about this. You're going to enable us to edit the questionnaire, and the changes that we make will be in the document that is submitted to our document storage, right?

ME: ...That's why I said I wasn't sure why you wanted to do this. We can certainly enable you to edit the questionnaire on the webpage, but that doesn't automatically mean the changes you make will be included in the PDF document; we would still need to write some code to do that.

HAROLD: I thought you said you already had the foundation for this in place.

ME: We have the part that allows you to edit the webpage, yes.

KATE: So we will be able to make changes to the questionnaire?

ME: Yes.

HAROLD: I must be missing something. If we can modify the questionnaire, and you already have the foundation to do that, why does the programming team need more time?

ME: (annoyed) Because we still need to write code to make the appropriate changes to the PDF document.

KATE: But why do you guys need time to make those changes if you can already allow us to edit the questionnaire?

ME: (realizing the problem) Because the webpage and the PDF document are not the same thing.

Apparently this was news to them. It was not obvious to them that the webpage and the PDF document were not the same thing, that we programmers still had to write code to keep the webpage and document in sync. Further, I repeatedly failed to draw that connection and explain it to them, and just kept repeating myself using different words.

My immediate reaction was to be annoyed. Seriously, I thought, that's so basic! A webpage and a PDF document are OBVIOUSLY not the same thing! My annoyance faded quickly, though, because I realized that I was expecting non-technical people to know technical details.

Let's face it: customers don't give a crap about the code. All they care about is "click here, type this, submit that, done," and frankly that's all they should care about. I had incorrectly assumed that something that was obvious to me would also be obvious to them, and because of this assumption, I had failed to properly communicate to them the amount of effort it would take to implement the process they desired.

This miscommunication between technical developers and non-technical customers is a gap that I've seen a lot of programmers (including myself) fail to bridge: we're so caught up in the details of an application that we forget that not everybody knows what we know.

My old self, the one that was locked in an ivory tower, didn't see any reason to be able to communicate with customers. After all, that organization employed project coordinators, people whose job it was to communicate back and forth between the programmers and the customers, and I was perfectly happy to let them handle the customers' inquiries. It wasn't until I accidentally ran into one of these customers in the hallway (and utterly failed to explain to him what it was that I was doing) that I realized I should be putting more effort into my communication skills.

Communication skills are essential for programmers. I believe we should always be able to explain ourselves to both technical and non-technical people. At some point in our careers we will be placed in a situation where we need to explain our code and logic to a non-technical customer. If we can do this in a way that they end up understanding what we are saying without needing to know any technical details, then we've bridged the communication gap. If we can do it repeatedly, then we've become more effective at communicating than many developers out there.

And, hey, if you find yourself at a meeting similar to the one I was summoned to, maybe you'll be able to explain yourself better than I did.