Friday, December 15, 2006

Why (Most) Men Don't Get It

My posts on the subject of women in IT seem to continue to be drawing controversy, primarily from men who clearly don't "get" what women want from computing.  On Richard Jones's original post, numerous women pointed out the same thing that I did: for most women, "computing" is all about doing something with computers, not achieving mastery of computers themselves.  One woman commented that the entire paradigm of computer science education was in fact based on male concepts of computing.

A few women griped about the porn situation, although the same women also sometimes dismissed it as a symptom rather than a cause, if they mentioned it at all.

But here's the thing: none of the guys are really asking how to get more women in IT.  They're asking, "how can we get more women in IT without actually changing anything, except maybe being more careful not to offend women."

This is a case of not really understanding what women want, and therefore working on the assumption that they are basically like men, only more sensitive.  Thus, the presumed fix is to avoid offending women, rather than rethinking how things like organizational structure, hiring, and education happen.

I'm not going to repeat what all I had to say in my previous post, or try to dig into this topic in more detail, since a some people seem to have already decided my opinions are evil and not to be trusted.

But I do urge you to read the comments on Jones' original post, specifically the ones that come from women.

I mean, really read them.  Don't just man-read them, by skimming through to spot the parts that support your position on the subject.  Don't dismiss what they're saying about what IT needs, because it's not in man-speak.  Assume that when a woman says that porn is a symptom, but the real problem is systemic and it's the male paradigm of computing that's the real problem, she actually means it.  Assume that when another one says that women want to do other things with computers, it's not just an idle comment, but an insightful point about the subject, with deep relevance to how women's most important needs can be met through change in the IT field.

In other words, when several "real women" in IT showed up to comment on this subject, a lot of you seem to have ignored their comments quite as thoroughly as you attacked mine.  Attacking me isn't a problem, but ignoring the women is.  If you want more women in IT, the first step is to listen to them, and not just to the parts that fit your preconceptions.

Speaking as a man, I know this is a tough thing to do.  My wife and I have been together for almost 16 years now and we still occasionally discover we're speaking different languages when we think we're being crystal clear to each other.  Nonetheless, if you won't listen to me trying to explain what to do about this in man-speak, then for heaven's sake go study what's already been said in woman-speak.


P.S. My main reason for not enabling comments on these posts is to avoid being distracted at work by the email notices of new comments.  By leaving the comments to other people's sites, I can control when I choose to observe and comment, and I don't feel like I have to address all the dumb or off-topic comments that may occur, and just focus on answering what I perceive as the relatively sincere ones.  As an added bonus, it lowers the instant gratification factor for flamage.  If somebody has to post on their own blog or hunt down my email address, they're more likely to produce a thoughtful comment that's worth reading.  So far it seems to have worked well, so I'm sticking to it for this post as well.

This should also be my last post on this topic; hopefully my next "PJE On Programming" (POP?) post will be about something less controversial, like CD duplicator automation with Python.  Although it will probably be a while before I write about that, actually, since I've got a bunch of self-improvement articles planned for my main blog that are likely to occupy most of my posting time in the next month.

So, my most likely next POP will be about Zope's status as the red-headed stepchild of the Python community.  That article is already written, in the form of a Foreword for the new edition of Web Component Development with Zope 3.  (Amazon currently lists me as the author of the foreword, but doesn't let you browse the current edition to read it, and I told Philipp I'd post it as an article around the time of the book's US debut, to help publicity.)  Hopefully it will be less controversial than these "Women in IT" articles, although perhaps not by much.  ;-)

Wednesday, December 13, 2006

The Real Reasons There Are Few Women In IT -- And What YOU Can Do About It

Anthony Baxter takes me to task for being part of the problem, not the solution (while having his mind blown through a weird misinterpretation of my previous article):

Saying "if there's a hostile work environment that discourages women, too bad for them" is a mind-blowing attitude to me. (I'd have also thought that someone who's all about efficiency and that sort of thing would recognise that a more heterogenous team produces better outcomes all around.)

Leaving aside for now the the question of how he managed to twist my position on workplace hostility 180 degrees, here's my wife's verbal response to Anthony's comments:

"The reason there aren't more women in IT is because they're not being hired (or not applying) in the first place!  Not because they're being driven away by hostile environments!"

Actually, she said a lot more than that, but I'm not going to include the rest because some people might be offended.  ;-)

In the more-printable parts of what she said, though, she reiterated the fact that most IT departments in Verio had a ridiculously low number of women in them, when compared to the department I ran.  Somehow, I ended up having half women 90% of the time in a six-person group, while other IT departments with 40 or 50 people were composed of 90% or more men -- all of the time.

Well, as it happened, I hired an equal number of men and women over the years, but NOT through a quota or some kind of "affirmative action".  It simply worked out that, on average, half of the qualified candidates we got were women.

That's probably because part of our definition of "qualified" was whether the person would get along with the group... which means there was a social element as well as mere technical competence.  So, we usually ended up rejecting more male candidates than females for "fit" problems.

So, as it happens, I've actually done something to have more women in IT: I hired them.  And I didn't hire people who would have made our workplace less pleasant, because yes, efficiency is important to me, and morale drives efficiency.

And I know, from actual experience, that men making a fuss about what does or doesn't bother them, is something that's not at all positive for women's (or anyone's) morale, because it highlights them as being different from other people on the team!  When I run a team, everyone is treated equally: with respect for their abilities.  We don't have a "girls team and boys team"; there is just one team, with one vision and one goal.

In short, worrying about inappropriate presentations is far downstream of the actual problem.  The real problems are:

  1. Women don't apply for the jobs,
  2. When they do, they aren't hired (or at least not for the best positions), and
  3. When they are hired, they're sometimes driven out by having to deal with a**holes of whatever variety

The way you fix problem #3, however, is by not hiring a**holes.  Not by trying to teach them Social Skills 101 (like "don't use porn in a slideshow, a**hole").

See, the difference between me and the people who are talking about how we should fix this "problem", is that they believe that it's possible to reform the attitudes of the uncivilized en masse, and I don't.  Instead of trying to reform them, I simply don't hire them in the first place.  No amount of technical competence is enough to make up for somebody being an a**hole, and it's not my job to teach somebody how to be a decent human being.  I'm running a place of business, not a charm school or etiquette academy.

Meanwhile, the way that you fix problem #2 is also by not hiring a**holes.  Not hiring a**holes causes you to hire fewer men on average, thereby leaving more room to hire women (by causing the positions to stay open longer, thereby compensating for the smaller number of women applying).

Now, as for the way you fix #1, I haven't a clue.  My wife's rant on this subject as she left for work this morning implied that there are issues in education, culture, etc., that are relevant here, but she didn't have time to get into any detail.  I've asked her to write a guest post (rant?) but I don't know if/when she'll have time in the near future.

However, I don't know if it actually matters.  If women aren't applying because they aren't interested in IT, is that really a problem?  If they're not applying because they're being discouraged by society in general, well, perhaps that's a problem, but it's not especially actionable on an individual level, so why worry?

But #2 and #3 are  easy to fix (by comparison, anyway), because all you have to do is raise your hiring standards all around.  So, in my view, the people who're so desperate to have more women in IT ought to try doing something about the actual problem, instead of sitting back on their asses talking about how bad other people are (like the socially-challenged porn presenter).  If it's necessary to protest, take it up with whoever hired the presenter, instead of blogging about how bad all those other people are, and oh, won't someone think of the poor defenseless women.  The way things change is when you take action to change them systemically, not by twittering about how bad they are now.

So, to paraphrase an old saying, I would say to those people, "I've upped my hiring standards....  now up yours!"  ;-)


(P.S. My wife suggested this evening that this post would read better I clarify that neither of us is saying that Verio's hiring practices in any other departments were discriminatory.  It's just that if you hire the first person who has the technical qualifications for a position, without taking group fit and other personality characteristics into consideration, you're far more likely to end up filling the position with a man, due to the generally-smaller female applicant pool.)

(P.P.S. If, after reading both of these posts, anyone somehow still thinks I support porn at development conferences or having hostile workplaces, their comprehension skills have failed them.  Not only do I not support these things, I've actually done something about them besides flapping my jaw on the internet about how bad they are.  'Nuff said.)

Tuesday, December 12, 2006

Is porn driving women away from the computer industry?

Due to the sensitive subject matter of this post, and my probably-controversial and certainly unconventional opinions on the subject, you'll have to click here to read the actual article in order to prove that you at least think you won't be offended.  Even though 90% of you probably will be, anyway.

Saturday, December 02, 2006

Choosing An Automated CD Duplicator

In the past few weeks I've been spending a lot of time evaluating CD duplicator/printer units, sometimes called "CD publishers".  That's because the business I'm building around my self-improvement blog is finally getting to the point where I'll be selling courses on CD, not just a book or a teleseminar series.  And, my first two courses will have 6 and 16 CDs in them!  Plus, next year I'll be doing a monthly newsletter+CD by subscription.  So, I need to get a machine that will:

  • Accept audio files and graphics from a PC
  • Duplicate and print the CDs, and
  • Stack them in groups!

Now the funny thing is that the last of those items is surprisingly hard to find in an off-the shelf duplicator, without doing any custom programming!  Most of them seem to be optimized for duplicating one CD, over and over, or else producing unique CDs, with no duplication.  That is, just being sent a bunch of files to create a one-off CD (e.g. with photos, just-recorded music, data files, etc.).  But virtually no manufacturer that I found, offers a way to say, "okay, here's a batch of six different CDs, make me five batches, stacked in the output so that I can just grab off each batch of six and pack them to ship to somebody!

I evaluated systems from probably 5 or 6 companies in all, each with many models of machines.  The top three finalists (in descending price order) were:

What these machines have in common is that they all support unattended operation for batches of at least 100 discs, do 4800dpi inkjet printing, and at least 48X recording speeds.  And, unfortunately, none of them provides any official support for collated multi-CD batches, without custom programming!

Evaluating the Discmakers Elite2

My initial preference among these units was the Discmakers machine, because it had a high capacity, and didn't require a PCI/Firewire interface like the Rimage does.  Although it costs somewhat more than the Bravo, it seemed more rugged-looking (metal vs. the Bravo's plastic) and it had a 175-CD capacity to the Bravo's 100.  (Indeed, the Bravo only supports running 100 CD's if you attach its "kiosk mode kit": a flimsy-looking plastic bin that hangs off the front so the machine can dump CD's into it!)

And the Discmakers folks were very helpful on the phone.  Steve tried to answer my questions as best he could, but explained that the included software could only do multiple CD's in what they call "relay mode".  In this mode, you put a master CD on top of a bunch of blanks, followed by another master and blanks, etc.  The duplicator reads the master, and then writes copies of it until it detects the next already-recorded CD.  Then it reads that disc and continues.

At that point, I asked if there was any way to record disks from the command line, or if there was an API available.  But it turns out that their basic software doesn't have any kind of job queueing built in, so there was simply no way to tell it to burn a set of discs in series, except for relay mode.  But, Steve offered, they had a network package that you could get for about $400 more, that added a network-based queueing system for jobs, and had both an API and a command-line interface.  He sent me the pfcnet documentation, so I could investigate further.

At first, that approach looked promising.  I wasn't keen on spending an extra $400 just to get a command-line interface, but the total price was still competitive with the Rimage 2000i.  The "pfcnet" program took a simple text file definition of how to burn the CD, with impressive flexibility.  Any needed file, be it a disk image, audio track, or label graphic, could be specified as an FTP or HTTP URL, a UNC (Windows network) path, or a straight filename.  There was also a web interface, in addition to the command line one.

But then I realized the problem, as I dug deeper into information about the cache files setup and the web interface.  The paths and URLs and whatnot weren't being processed by the server. They were, as far as I could tell, being processed by the client, and then the actual bytes would be sent to the server.

And that would mean that if I submitted these jobs individually, I'd be streaming each individual CD over the network, even if I did it from the same PC.  The files would get read off the hard drive... and then written back to the hard drive in a cache file, before burning each CD.

And as you can imagine, that really wasn't what I wanted.  So I started looking at the Rimage more closely.

The Rimage 2000i

Now, the Rimage, as the highest-priced unit, was also in some ways the most attractive.  Although it only has a 100 disc capacity, it doesn't drop the discs out the front into a plastic catchbin.  The catchbin is built-in, and metal.  Also, the robotics on the Rimage are extremely simple: all the arm does is go up and down, picking up and dropping CD's.  It doesn't rotate or slide horizontally or anything: it just goes up and down.  And, most importantly, its software description strongly implies that it can do multi-disc sets!  That is, it says:

Save single disc jobs, multiple disc jobs, and group multiple jobs for easy resubmission

Sounds good, right?  Well, sort of.  I talked to their sales department, who were fairly sure you could do multiple disc jobs, but weren't sure if you'd actually get them in order or not.  They thought that you would probably get N copies of one, N copies of the next, etc.  But to be sure, they sent me to their "application engineering" department, where I left a message and received a call back the next day.

Well, several calls, actually.  Because the person who called me back didn't really have the answers at first either.  But to make a long story short, she explained that the main issue was that their software was designed to absolutely maximize disc throughput, even at the expense of changing the output order.  Since the unit has two CD drives, it will basically choose to print and drop whichever CD finishes burning first, if both drives are in use.  So, the output order isn't really predictable, because it depends on how long it takes to print and burn the CD's in question.

There was, however, on their more advanced software ($999 extra), an option to set a "FIFO mode", in which CDs would always be printed in the job input order, even if it would slow down the overall throughput.  Also, there was an XML-based messaging queue system that the more advanced software had, so that I could send it stuff to do.  The "production server" of that software runs as a Windows service (daemon), so I could just write a program to feed it XML job files and do what I wanted.   Except...

It had the same damn problem as the Discmakers Elite!  The server wasn't set up to just burn images already on its hard drive, it was set up to read things and then cache them as images.  Basically, she explained, this mode of operation was designed for producing unique CD's... just like the Discmakers.

So I was a bit disappointed.  I really liked a lot of things about the Rimage: ruggedness, lack of assembly required, and the documentation I read about their network software made it look like they really had their act together, software development-wise.  Unfortunately, that act just didn't include what I was trying to do!  So it was time to consider other options.

The Primera Bravo Pro

I had more-or-less previously ruled out the Bravo machines.  In part, this was because I thought there was only one: the Bravo II, a single-burner unit with a maximum capacity of 50 discs.  But the Bravo Pro has two burners and a 100-disc capacity, putting it back into the running as soon as I realized the difference.  But now the question was whether the software would actually do what I needed.

What I found surprised me.  First, although the Bravo's Windows-based software didn't support multi-disc jobs, its Mac version did!  (At least, according to a few reviews out there on the net; I couldn't find any docs on Primera's site that indicated one way or the other.)  Second, although the basic Windows software didn't support multi-disc duplication, the Bravo Pro included a free network version of the software -- and I found documentation on their site for their PTBurn SDK's queueing API (PDF).  The queueing mechanism is actually based on inserting files into a queue directory, and there's some primitive backchannel communication of job status.

Most important, the file paths (including disc images) are processed directly by the server, rather than being streamed over the network, meaning that it should be able to simply burn each disc straight from the hard drives to the CDs.  And, since the server renames job files as it picks them up, I should be able to write a simple Python program to submit new jobs one at a time, waiting for the server to pick up the previous jobs before submitting new ones, thereby enforcing a serial order.

In fact, the PTBurn API provides a wealth of status information about the system, like how many jobs it has left, how many jobs are ahead of a particular job, and so on.  You can tell just from a job's filename whether it has been "noticed" by the server, whether it's actually being run, and when it's finished.  You can find out stuff like whether the ink is low, what time a job started, when it finished, and how many bad CD's got thrown out during the job.

Indeed, the richness of the PTBurn API was comparable to that of the Rimage...  except that the PTBurn network software comes with the base unit, at no extra cost!  Even without having the full PTBurn SDK (which includes a standalone installable version of PTBurn, and some sample code for creating job files), I could still use just the documentation I found to write some Python scripts and make a standard, off-the-shelf Bravo Pro do my bidding!

In Conclusion

So, after contemplating the options a bit further, I decided to go with the Bravo.  While there's still no guarantee I'll get it to do exactly what I want, there seems to be a much better chance than with the others, and the price simply can't be beat, especially on eBay.  Many sellers offer new Bravo Pro's for less than you can get used or refurbished units of the other types I looked at.

Meanwhile, its low-tech queueing API seems like just the tool for the job, and it looks like it would be easy to create a Python API that conveniently exposes all of its features.  Heck, I'll probably release it as a Cheeseshop package.  In fact, since PTBurn will accept .BMP or .JPG images for printing on the discs, I could perhaps use the Python Imaging Library (PIL) to generate custom-labelled discs with the name and a picture of the person they're being made for!  (I don't actually have a use for that right now, but it sure sounds like a cool idea!)

As of this moment, however, I haven't actually received the unit yet, and probably won't have a lot of time to play around with it at first.  I'll post more when I know more, and maybe again if/when I release a Python API for the machine to the Cheeseshop.