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.

The generally argumentative Internet has, of late, turned its bickering sights from name-calling about PCs vs Macs (my least favorite argument, since Macs ARE PCs, but I digress) or iPhone vs Android (how is this even a fight? I love Android, but for an end-user, it’s a ridiculous choice still) to an even more apples and oranges comparison. We are currently arguing about whether tablets or laptops are better.

(Spoiler alert: the answer is “if you’re asking this question, you don’t understand computing enough to participate in the discussion that follows,” but it’s plausible I’ve just become cynical in my old age.)

Let me being by saying, I used to carry a laptop, and it was annoying.

If I was going anywhere outside of my home, before I walked out the door I had a decision to make: do I take the laptop or do I leave it behind. This was a non-trivial decision with a lot behind it: do I spend 5 minutes breaking down my system wherever it is set up and throw it into the laptop bag? Am I going to have a place to keep it where I’m going, or is its not-inconsiderable bulk going to be hanging from my shoulder all day? Is it going to sit in my car waiting for a break-in? Am I even liable to use it? Am I going to have time? Is it worth bringing the laptop at all?

In the face of these questions I often chose not to bring it. A flash drive with important programs and a Dropbox full of important files often served as a replacement for lugging 5 to 15 pounds of laptop, bag, peripherals, and accoutrements.

When I did bother to even bring it, I just didn’t bother to use it in most cases. Oftener than not if I wasn’t leaving to go to work, the time and space required was greater than I was willing to invest. After setting up camp, I needed to extract my laptop from my bag (and depending on the state of my power and my plans, my power brick and mouse), power it up (and hope that it suspended reliably last time…a crap-shoot on Windows and Ubuntu), open the files that I am planning to work on, and get to work. If everything went optimally (a rarity that involved a confluence of events including a full battery, a reliably suspended operating system, work spaces already configured for how I was planning on working at the moment, files already opened, the Internet already configured, the sacrifice of a lamb to our dark lord, three cups of coffee, and a partridge in a pear tree), I was out 5 minutes of setup. In the mundane version of events referred to as ‘reality’ I was generally out closer to 10 or 15 minutes and a few ounces of frustration and annoyance.

Compare that to my new work flow. I have doubled the size of my laptop with a ruggedized case and it still fits comfortably in a small bag that I carry with me always¹ roughly the size of a smallish purse. No decision needs be made; it is just going with me. If I am going to work, I’ll grab my briefcase too which—even with keyboard, peripherals for presentations, a mouse, and all of the paperwork I might need—is still lighter than my laptop was alone.

If I decide to do some work, I can pull out my tablet and work without even setting down my murse². If I need to type a LOT, I can do so by pulling out the keyboard too, which still all requires approximately the same amount of space as my laptop. Getting to work is nearly instantaneous. I can go from thinking about what I’d like to work on to actually working on it in under a minute. In a WORST case situations (wherein the things with which I want to work are on the cloud but haven’t been synced to my system, I’m not connected to the Internet, I need both keyboard and mouse, my battery is low, and I have to reboot my tablet), I still am working in under 5 minutes. That is pretty damned handy; so handy, in fact, that I find myself working to fill small breaks in my day far more routinely than ever before with a laptop.

“But Jer,” I hear you saying, “I am a(n) $x!” where $x is some nominal job description that conveys an inherent inability to use tablets. “Tablets are useless to me for my job!” To that I respond with the following:

1. Depending on what your value of $x was, you might be right. It is also not an airplane, so if your $x was ‘pilot,’ you will find that the tablet will certainly fail to fly us to far away lands. It is also not a large truck, so it will not transport merchandise from warehouse to store. It is not even (despite obvious similarities) a spatula, so it will not help you flip burgers at the place of employment wherein you first learned your rhetorical and debate skills. It happens to be a tablet. It is best used for tablety things.

2. You also might be surprised about what a tablet can actually help you do. If your concern is that it won’t run the software you need, that is often easily worked around. For example, I am a software developer: it has taken me a trivial amount of time to push my C, C++, or Python development to remote systems that I connect to through SSH and VIM.

   When developing in PHP, Perl, Javascript, or other web languages, I SFTP files to and fro. When developing in .Net or Java, I VNC to my desktop. True, if I were principally a Java or .Net developer, I would probably carry my laptop far more often…VNS is a stopgap, not a real solution. If you are a developer that requires a specific, GUI development environment, you might need to read response #1.

3. If your big problem is input speed, I have found that with or without a keyboard, inputting isn’t a considerable problem for me. Using Swift Key or Swype, I can generally program at pretty close to my standard speed—most of the time I spend coding is burst typing while thinking…even an on-screen keyboard handles that well. When I am grading papers or corresponding, the on screen keyboard or voice recognition tends to work very well for me.

   When writing long-form (as in blog entries, term papers, etc), the external keyboard becomes necessary. It, unfortunately, slows my 110+ word per minute typing speed considerably: I type at a mere 60-80 WPM on my external keyboard. Amusingly, 60-80 WPM is closer to my long-term sustainable typing rate anyway.

   Often, I have to do finish work on a desktop; this is true whether I began the coding/writing/correspondence/grading on a tablet or a full system. I need editing, that is a given. If you have read this far, you already know that.

   If your needs cannot be served by any of the above, you might need to re-read point number 1

Regardless of how well it works for me, the tablet doesn’t fix everything. It is not a gaming rig…my occasional forays into gaming will not be satisfied without my laptop. It’s also not a power house; if I’m going to really dive into work, I want multiple monitors—each with more real estate than my paltry mobile screen provides. In either of those cases, desktops are ubiquitous enough at this point, though, that I can almost always find one where I’m going to be working if I need to…and I rarely need to.

Are tablets for everybody? No, don’t be stupid. Neither are shoes, cars, glasses, or pine nuts. Are they sufficient for most people? I’ve found that to be true (of tablets…but also of shoes, cars, glasses, and pine nuts). Most people’s needs can be boiled down to consumption, correspondence, and creation—in descending order…on a STEEP curve. A tablet works well if your needs fall into that pattern; hell, it could work if your needs do not, but can be made to emulate that pattern. If your creation, however, is of a sort that does not lend itself well to low-power, low-end devices (media creation, .Net programming, etc), then you might want to give tablets a miss for a while.

All I know is that the power supply on my laptop fried half a year ago, and I still haven’t bothered to get it repaired. I’ve missed having the laptop about twice since the beginning of the summer. I should probably get on that. Your mileage, as they say, may vary (but what they don’t tell you is…that’s because you’re doing it wrong!)