An eye-opener about your own biases

Even though I have been preaching about this stuff, and admitting I have non-conscious biases, it still caught me off guard to see it in myself: a web demo of Harvard's studies on our implicit, unconscious biases that you can take yourself in 5-10 minutes (per test). 

Filed under  //   diversity  

Comments [1]

My response to the pushback on my diversity talks

After I gave a couple inflammatory talks on diversity and discrimination in the ruby community I got some feedback and pushback.

Here is my response

To use your example, plenty of hockey players are probably racist, actually, even if they don't realize it. Not to pick on them, but part of my talk was about how pretty much everyone is, they just don't consciously acknowledge it. I'm not talking about overt racism, just the basic assumptions of the privileged that come out in everything because they don't realize the are privileged and how underexposed to other cultures, races, ways of life, etc, they may be. 

Athletes in all nearly white fields certainly aren't immune to bigotry.  Having grown up a competitive bump skier I can attest to that.  Like most winter sports it's a very white field.  Often bigotry is strongly linked with lack of exposure and diversity.  Due to the very fact of not having more minority and female colleagues we start subconsciously building assumptions.  

In SF, the majority of downtown business people's exposure to black people is the homeless.  I'd put a fiver on that negatively affectively their biases.  There are studies that watching the Summer Olympics, which has a lot black role models performing well, temporarily counters some of the subconscious racist bias in test subjects. And I think everyone has anecdotal experience with racists justifications they've overheard that negative experiences can create biases.

A large part of what sparked my initial talk, was a) @bryanl giving a talk where he had a line about it being about time we (the white audience) were the uncomfortable ones in the room and b) @gigglegirl4e gaving a talk titled "Whose wife are you?" because that is something she hears, especially at conferences.  As long as she is hearing that...

You really should read up some on feminist theory and privilege.   I really, really don't care if a bunch of straight white males get a little offended that they don't realize how good they have it and how exclusionary they are.  I am queer, and yes the field is to blame. Not entirely, no.  And maybe in part it's better than other fields, but it's far worse than many. We are an awesome, low bullshit community, based around a very easy language to learn.  We should be the best community there is on this topic.  It's not that I don't love us, it's that I do enough to have set a higher bar for my expectations.  As @dnscollective said in his far gentler, more inclusive lightning talk, let's be the industry and community we want to work in.

If you think being offended at having people say the field is discriminatory and that you have biases is rough, then you should sit down longer and listen, not talk to, but listen to some of the black guys or women in the field, on the topic.  Not all of them may have had a rough time, but most will be able to talk your ear off.

As for the other example, I think comparing the cultural stereotype of interior designers all being gay, to the straight, white, male predominance in ours is actually offensive.  For one, it's based on a huge assumption without any apparent research backing it.  It comes off as a defensive knee-jerk rather than having to admit that being a white male in a field making giant amounts of money, while the rest of the country swirls down the drain, might be a pretty cush situation, that being excluded from is actually a form of class warfare.  Do you think Interior Design and Ruby Programmer are equivalently powerful positions in our current economy?  Also, there are some long standing reasons for straight men not being as prevalent in Interior Design (which has actually shifted farther in the last 5 years than our field, so hah, its a straw man AND moot!) and they have mostly to do with sexism and discrimination.

Interior Design has been the domain of housewives and openly gay men, because the "real men" were busy dominating the "real jobs."  Do you think Jewish people were discriminating against the goyim by keeping them out of the money-changing field, during a couple hundred (or thousand?) years of European history?  By my admittedly limited reading (not being a history major), largely not, it was actually discrimination the other way that drove Jewish people into that field as one of the few jobs they were allowed.

Also, I don't get what our whole field's anti-intellectual and academic obsession is.  We seem fine saying "Well I haven't read the Gang of Four, but it's not much use anyways" or "Well I haven't really studied this field, but I have lots of opinions based on my own personal experience which is obviously applicable to the position of the historically discriminated-against and oppressed." This stretches out to me, too - I am a college drop-out.  So I do understand the bias against overly academic CS, but unfortunately, we've let it bleed over so far into anti-academia that we sounds like George W. Bush supporters ranting against those damn liberal (feminist) snobs, sometimes.

Usually, I just write negative responses off as the classic example of what happens when you speak to power and privilege: offense, defensiveness, and pooh poohing.  "There isn't any problem with black people having to use separate water fountains; they get the same water."  Almost universally, IME, when you explain the huge difference between discrimination by the majority, by the patriarchy, by those who have always had it easier, without even realizing how much so, versus discrimination up the ladder by the oppressed, you get anger, justification, and dodging of responsibility.  

In fact DHH, is one of the few counter-examples I can think of - after the first Gogaruco, when these concepts were explained to him he said roughly "Hmm, that makes sense, if you are already the minority in the room, and here for professional development or work, that wouldn't be very fair, to be forcefully exposed to something that highlights just how in the minority you are."  When he did that I gained even more respect for him than when I got in a technical debate with him and only realized how right he was 3 months later, when I learned more.

 

End of my response

I never sent it, because the guy in question wrote the nuancing reply that I mention in my previous post and gave me the go ahead to use his anonymous words for a discussion point. And now I add him to the small pool of guys who, even when pushed hard by my intentionally inflammatory, discussion-starting claims, actually listen, process, and admit that maybe those crazy feminists aren't totally making this all up. ;)

UPDATE

Thanks for the edits @alexch

Filed under  //   diversity  

Comments [1]

Pushback from my diversity talks

This is part of the exchange that occurred in response to my talk on diversity at gogaruco, where I pointed out the the entire audience, and myself, are a bunch of sexist, racists, homophobic bigots, and the slightly more nuanced followup at rubyconf.

I'm anonymizing this to avoid causing a flame war for the quite reasonable guy who posted it, and because he followed up with this:

Well, I'm glad we had our conversation last week. I feel less strongly about the issue now than I did before that conversation. I think I was mostly reacting to the inflammatory nature of your talk (ie. opening with calling the audience racists, bigots, and misogynists). I've gone back and watched your talk on confreaks, and it doesn't seem as inflammatory as it did that night (chalk that up to either having more perspective after our conversation, or being over the shock value of those statements).

...

So I feel I've gotten my thoughts out of my system, and don't feel strongly enough to post them publicly.

 

His original thoughts are below:

 

I care about equality and despise discrimination, and yet I am concerned and offended by a growing trend to accuse the technology sector, and the software industry specifically, of being bigots, racists, and misogynists. Think about this question: Are the interior decorating power elite keeping straight men out of their industry? I don't know the answer to that question, but I doubt that they are. Some may suggest that the analogy isn't a good one, because straight men aren't typically systematically oppressed. I'm not sure I agree with that either. I'll return to this analogy.

 

I've not studied discrimination, oppression, women's issues, etc. beyond that which is taught in a typical American college education and that which is generally reported in major news media. But I do have eyes, ears, an open mind, and I generally don't see evidence of discrimination in the software development industry.

 

I do see that the industry is dominated by white males. There is no question of that. Furthermore, I personally would greatly welcome more diversity. But are the demographics of the software development industry an indication of systematic oppression/discrimination? Is the white male dominance a malignancy?

Surely there is discrimination. I would be foolish to suggest that it doesn't happen. It is a sad fact that discrimination persists everywhere. So when blaming a lack of diversity of a group on discrimination, then surely the accusation is that the group discriminates more than the population on whole.

 

[need to flush out more of my thoughts prior to wrapping up]

 

Returning to the analogy of the interior decorating industry, I would argue that fewer straight men are interested in interior decorating. I would also argue that there is nothing wrong with that. To argue otherwise would to suggest that there should be a uniform distribution of interests and competencies across all genders, races, and sexual orientations. I don't believe that belief in human equality in general means a belief in uniform distribution of interests and competencies.

 

[Other analogies include: Are ice hockey players racist since most ice hockey professionals are white males? I'd argue that socio-economics play a bigger role in determining someone's likelihood of becoming a professional hockey player.]

 

Filed under  //   diversity  

Comments [1]

Comments [1]

My 2nd diversity lightning talk - rubyconf

A less rapid and angry diversity lightning talk for rubyconf 2011.  I think I might mix it up and continue to give some variation of this at each conference I attend.

Filed under  //   diversity   monoculture-lightning  

Comments [1]

Filed under  //   diversity   monoculture-lightning  

Comments [1]

My upcoming speaking events

I had a blast speaking at the Database meet-up that Wellness FX put on last month where I talked about managing migrations in Mongo. I'm pumped to follow that up with speaking at Madison Ruby this coming week-end where I will be expanding the material from that initial 20 minute talk to the fuller 30 minutes allotted at Madison. I'll definitely be fleshing out some of the positives of working with MongoMapper that I glossed over in the initial talk - namely the incredibly fun power of the DataMapper pattern combined with a schemaless datastore.  Hopefully this helps alleviate some of the anti-Mongo vibe my first talk seemed to give off; MongoHQ are speaking at Madison as well and we wouldn't want that to lead to a pub brawl during the post conference drinking (we're rubyists, the drinking is a given).  Don't worry though, I won't let that entirely keep me from speaking my mind. ;)

Next I'm organizing a panel on hiring rubyists, coming up in Sept, with some very well known names in the local ruby community. I'm honored that they all seemed to jump at the chance to do this panel with me.  As a consultant, how to deal with hiring rubyists is a question that comes up constantly and it will be great to get these 4 views on the topic posted up on the web so I can point to it and say "that's how."  I definitely have to say thank you to Engine Yard for graciously offering to host the event.

And to cap off my continuously expanding talk on Mongo and how to deal with your lack of schema, data validity, migrations, etc, I will literally be closing down the conference at RubyConf.  I'm hoping that even though I am speaking dead last, my immediately following Tom Preston-Werner will help motivate attendees to stay to the bitter end for my talk.  I will have already added some code examples to my nearly Bauhausian minimilist slides from the Wellness event for Madison, but talks are 45 minutes at RubyConf, so there will certainly be even more of the nitty gritty and code examples that people have been asking for.

Comments [1]

The unbearable flexibility of schemalesness

Everybod hates Single Table Inheritance, right?  MongoMapper has a similar concept, Single Collection Inheritance, but also a better alternative.  MM provides, and in fact is mostly built with, a simple plugin system that is a thin wrapper around ruby's include.  It includes the InstanceMethods, extends the ClassMethods, and provides a callback for configuring the model.

This better use of the ruby approach to grouping methods into modules becomes truly powerful when combined with the DataMapper pattern (which MongoMapper essentially implements) and a schemaless datastore like Mongo.

In the gist below I demonstrate using MongoMapper's plugin system to build aggregate models, in place of a pure single inheritance hierarchy with which it is fully compatible.  You can couple this with composition by using your plug-in to add associations and associated proxy methods for them.

I think this flexibility is the real power of NoSQL: not "web-scale", which people have been doing with SQL for years, but defining your data type once, in your model, with the full dynamism of ruby. I was skeptical about key-value stores as a default storage engine for web apps, until very recently, and still think MySQL is the right answer for many people and projects. But my most recent client project uses MongoMapper, and as we started to refactor and DRY up the models, I finally saw how truly useful not being bound to a datastore's schema is.

Migrations? Yes, you don't get AR migrations. The 'proper' migrations, which only affect schema, are unneeded anyways, in a DataMapper. And data migrations are done wrong 99% of the time anyways, imo; pretending they are instantaneous is a mistake. In either AR or MM you should handle you data migrations more robustly, via code switches and async tasks to transform the data. If I get a chance to make this a talk, I may explore that more fully.

Comments [1]

A pattern for testing class methods in ruby with rspec explicit subjects

RSpec's subject method, both implicitly and explicitly set, is useful for declaratively setting up the context of the object under test. If you provide a class for your describe block, subject will implicitly be set to a new instance of this class (with no arguments passed to the constructor). If you want something more complex done, such as setting arguments, you can use the explicit subject setter, which takes a block.

describe Person do
  context "born 19 years ago" do
    subject { Person.new(:birthdate => 19.years.ago }
    it { should be_eligible_to_vote }
    its(:age) { should == 19 }
    it "should be younger than a 20 year old" do
      twenty_year_old = Person.new(:birthday => 20.years.ago)
      subject.should be_younger_than(twenty_year_old)
    end
  end
end

The subject block is called after any befores. In fact, it is not called until it is referenced in the spec - the compact syntaxes of 'it { should }' and 'its(:property)' implicitly call subject as needed*. This means any method calls in the subject block reference the state of the system (like your db), at the time subject is called.

describe "the oldest person" do
  subject { Person.new(:birthdate => Person.oldest_person.birthdate - 1) }
  it "should be older than the next oldest person" do
    original_oldest_person = Person.new(:birthdate => 100.years.ago)
    subject.should be_older_than(original_oldest_person)
  end
end

subject thus provides a decent syntax for testing method calls directly. Sometimes, though, you have methods you want to test almost purely based on what is passed into them, with few other concerns of state, for instance, when testing class methods. These specs may have a little shared set-up needed, but really the true object under test is the method call itself. In these cases it makes sense to set that as the subject, and this leads to an effective and succinct, if slightly distasteful, pattern for setting the method arguments via standard rspec ivar trickery.

describe ".first" do
  before { Person.create_10_people }
  subject { Person.first(@number_of_people) }
  it "should return the specified number of people" do
    @number_of_people = 5
    subject.size.should == 5
  end
  
  it "should return a single person when so specified" do
    @number_of_people = 1
    subject.should be_a(Person)
  end

  it "should default to returning a single person" do
    subject.should be_a(Person)
  end
end

I was bemoaning the difference between ruby and more functional languages like JavaScript, where you do have ways of easily differentiating between a method reference and call (parentheses), and how that would make a pattern like this easier by letting you set the method as the subject and then call it in the spec. Then I realized, of course ruby has a way for creating a callable reference like this: a lambda.

describe ".first" do    
  subject { lambda { |number_of_people| Person.first(number_of_people  ) } }
  it { subject.call(5).size.should == 5 }
  it { subject.call(1).should be_a(Person) }
  it { subject.call.should be_a(Person)
end

If I continue to like this pattern enough after more usage, I'll probably see if I can get them to accept a patch to allow passing of arguments directly into subject itself. That could possibly get a little messy in the code for subject itself, but behind the scenes gymnastics to get a nice testing syntax is what rspec is all about, after all.

*The latter syntax actual resets subject, the getter, to be the result of the property access, allowing for the intriguing abuse of syntax: 'its(:property) { subject.should....'

Comments [8]

Simplest static site on Heroku (plain Rack)?

gem 'rack-rewrite', '~> 1.0.0'
require 'rack/rewrite'

use Rack::Rewrite do
  rewrite '/favicon.ico', '/images/favicon.ico'
  rewrite '/', '/index.html'
end
run Rack::File.new('public')

Filed under  //   hosting   ruby   tech  

Comments [1]