I was trying to describe to somebody what it is that I do in relatively specific terms—a task that proved to be immeasurably more difficult than it should be—and I was casting about trying to find some way to convey what it is that I actually accomplish. I know what I do, I’m there for pretty much all of it, why would it be so difficult to summarize in any meaningful way (or, more to the point I guess, in a way that is meaningful to people that don’t do the same thing). After a series of increasingly embarrassing false starts and fumbled trail-offs, I staggered into a description that I feel is pretty close.

I am a story teller.

When I teach, I teach through metaphor and anecdote. Facts are fun—I love them and they are necessary—but facts don’t teach, they inform. Building a connection to facts, that is how we learn. That is how everyone has always learned (give or take a few). So rather than spew a list of concepts, methods, or algorithms at my class, I teach by using stories to build those connections. I tell stories about how I used this function wrong and it yielded a comical result. I talk about how mis-application of some idea ended in tragedy. We, as a class, explore examples of certain algorithms in our daily lives. We weave stories in order to build context for the facts in our minds and so that we can retain them.

I’m no less a story teller when I develop software.

When developing software, I have to be a master storyteller if I want to do a great job. I can’t tell the story, I have to help the customer—the end user—tell their story. I have to elicit from them how they think they do work; then I have to dig deeper and get them to convey how they actually do work. Through anecdote and informal chatter, I draw out context for otherwise disjointed facts like “I want it to be busier” or “the old way was just too clustery.”

Once I’ve helped the user build their story, I build my complementary story. I take what they have taught me and spin it into my own tale using code and graphics and requirements documents. I deal it back to them like a serial novel—pieces at a time in a way that allows me to gauge their reaction and keep their interest engaged. By the time they have seen the story in total, there should be precious few surprises (and among those precious few, only good ones) but a great deal of satisfaction with the denouement.

This is why it pains me to see the artless, engineering way to do requirements analysis. I cannot do my best work as I slog through a checklist of context-less questions and categorized facts. I need connection, and so does the client. In my experience, we are all infinitely better off sitting down together and listening to one another’s story with a checklist as a backstop to ensure that all bases have been covered than to rigidly adhere to a few hours of discovery done in a conference room.

So I’m not a software developer. I’m not an educator, a father, a manager, or a leader. I’m a story teller; I suspect that your software developers are yearning to be one too. Do yourself a favor and help them get there.

As a regular reader of tech news and various forums, I am regularly witness to articles addressing women in technology—and let me begin by saying that I am profoundly grateful for that. It wasn’t terribly long ago that the very idea that a woman might participate in a STEM field was absolutely shocking. Even as recent as my time in high school some 20 years ago, home economics was for girls, shop was for boys, and computer class was for nerdy boys with poor hand-eye coordination. This shift, from then to now, only happens as a result of this ongoing conversation that happens in the media, on the web, and in our offices.

I am concerned, however, with the narrative that we follow in discussing the shortage of women in technology. We discuss (ad nauseam, some times) who these women are and what they do. We bicker about why they are insufficiently represented and about whether or not there is a pay disparity. We even discuss what women can do to address the gap—like they’re the only part of the equation. Here’s the thing, if we’re going to resolve this, there’s work that’s going to have to be done on both ends of the equation. Certainly, women are going to have to (continue) to do some heavy lifting to continue to stake out their place at the table—but shouldn’t the rest of us consider what we should be doing, too? So that’s what this is, this is the conversation we can have as men as to how we fix this gap…at least part of it.

The most important thing that we can do is to stop pretending that trying to fix this gender divide is a thing we are grudgingly having to do for “them.” I’ve worked around developers more of my life than not at this point, and there is no doubt that we are a supremely homogeneous group. Homogeneity stands firm between a team and progress. The more alike the membership of the group is to one another, the more the group becomes a feedback loop for itself; inflating the importance of its own ideas and confusing concensus with popular opinion.

It is in our best interests to fix this thing. We need our ranks to be filled with as diverse and broad a subset of the human experience as we can manage. Adding women to the mix is just one way, but it’s an important one, and the fix begins easily enough. We can cover serious ground by making one these two simple fixes:

Imagine, for a moment, a person you do not want to have sex with. I don’t mean someone you find hideous or repellant, mind you, just someone that is completely physically unattractive to you. Perhaps you even enjoy the person’s company, but dating or sex? No way!

Stop picturing me, that’s uncalled for.

Now, imagine that they are participating in a development project with you. They are a member of your team and you see them in-person and online on a regular basis. You are in pretty close to daily contact. Oh…and he or she will not stop hitting on you. Now, I don’t mean that this person is aggressively forcing him or her self at you; that would almost be actionable. Instead you are subjected to all of the flirty behaviors you aren’t interested in. They make jokes-that-are-clearly-not-jokes, they sit too close, they check you out in obvious ways, they invite you on dates-that-aren’t-dates-that-really-are-dates; and they do all of this relentlessly. Take a second, actually picture it.

If you are like me, you are already a little bit uncomfortable, because almost all of us have been in this situation at one point or another and we know how awkward it is to be stuck here. This is not something you are comfortable calling harassment, but he or she won’t take a hint and there’s nothing you can do about it without coming away feeling like a heel.

Now, imagine one more thing for me…imagine that you weren’t even sure that you belonged on this project at all. Imagine that you already felt a little out of place, and THEN all of this happens. How long before you decide that this particular project just isn’t the place for you? How many of these places will you decide aren’t for you before you think that this entire industry just isn’t the place for you?

Listen, from a purely practical sense, it’s a simple concept: the only circumstance wherein you immediately and clumsily hitting on a female on your team is going to end *well* is if she is into you, is looking to be hit on, and doesn’t mind your ham-handed style of flirting. Only if all of these three are true does this end even close to well. In all other cases—if she’s not into you, if her intentions happen to be (*gasp*) focused on this project rather than your libido, or if she would just like to spend some time doing this without having everyone trying to climb into her pants—all you are doing is alienating her. That hostile environment that we just described, that’s what you are creating. The best of the likely outcomes is that she quietly puts up with all of this while tries to focus on this thing that she is actually here for, but the most realistic scenario tends to be that she just goes away.

The fact of the matter is, even if you stop hitting on all of the women as they arrive in your group, your fellow men in technology are probably still doing it. The next step is to make your work spaces safe, inviting ones for everyone that you wish to attend, including women. It is easy to put together rules and regulations that legislate spaces into safe and inviting ones—and when the space is a place of employment, you almost certainly should do so—but merely putting rules together isn’t enough. The sort of off-putting behaviors that legitimately sends women the message that they don’t belong is notoriously difficult to pin down with any degree of specificity in real life situations.

Social pressure, however, is an amazing thing. Let’s face it; this sort of behavior is truly embarassing to be caught doing. Relentlessly pestering a woman for a date—or doing all of the show-off, plumage-flaring behaviors meant to draw the attention of one’s desired mate—these are humiliating things to be called out on. Use that fact. When you see someone singling out the female in a group for attention, call attention to it.

It doesn’t have to be overt or in front of an entire group of people. In one of my classrooms a year or so ago, I had a very attractive student in a web programming class, one of perhaps 2 female students in a class of nearly 20. She was very good—if not top of the class, then very near it—but that didn’t stop one male student from offering outside-of-class help. After observing a few such offers, I finally had to intervene…

Me (directly to the student): Hey, are you offering additional help?

Student: Yeah…

M (to the class): Hey gang, S is offering to help those of you who are struggling. It’s really cool of him to offer, so, take him up on it.

At the end of class, alone…

S: Hey, I didn’t mean that for the entire class

M: Oh, I’m sorry, I just figured that since offering to help just her is sort of creepy and stalker-y, you must have been making it kinda a general offer.

At this point, the student and I had a brief discussion as to why it is frowned upon to do what he did, why it might be creepy, and why it wouldn’t be allowed in my classroom. Who knows if this ‘teachable moment’ had a lasting impact on him, but at the very least he ceased hitting on this young lady in my classroom. She had one safe space to learn, at least.

Now, there are probably dozens of other things we can do—right off the top of my head, I suggest not letting our impostor syndromes manifest as uber-aggressive know-it-all posturing, for example—but this is a start. Simply recognize how essential it is for all of us that we fix this, then start fixing it by trying not to be a douchebag and pointing out to your friends and co-workers when they are being douchebags. Perhaps we can end this boy’s club that someone created for us. I know I, for one, don’t want it anymore.

When I’m teaching PHP or Perl, a conversation invariably springs up early in class related to loose data typing. The format is almost always the same…a student with some moderate amount of programming experience in a strongly typed language (C or C++ generally) is elated to find they can just stuff anything into a variable. When I opine that this is a terrible and dangerous flaw in the languages, the argument proceeds down the lines of “it’s so much easier” or how “archaic” my point of view is.

Listen, weak data typing is not easier; it’s sloppier, which is not the same thing. In fact, that sloppiness often makes things harder! This weekend, for instance, I whipped a quick little script together for a friend that would parse an automatically generated XML file and make a series of corrections for him. In mid stream, however, I was stymied by a troubling little bug…one of the fields would occasionally cause a crash.

As it turns out, XML::Simple was reading a blank tag (that the program generating the XML erroneously output as <tag></tag> rather than <tag />, but I digress) and rather than storing it as a null string, it opened up a new, empty hash.

Of course, it is stupid of the initial app to output the XML in that format…and yes, XML::Simple was being idiotic for not noting that edge case…but these are the exact sorts of real-world situations that strong data-typing would have prevented (or, at least illustrated earlier).

I spend an enormous amount of time looking at other people’s code whether it be working for my ‘day job’, for a consulting contract, on open source projects, or examining the work of my students—an a single, unifying theme in loose data typing is that it is a gotcha that is often terribly difficult to track down.

So instead of adopting the burden of explicitly casting your data from type to type, you adopt the burden of searching for edge cases to prevent…to my mind, not easier.