Women in technology

Great rumination about why computer science is the only field to suffer declining women participation. Think about that: even if you want to troop out the arguments that skills get rewarded, you need to come up with some explanation why computer science dismally stands alone.

Even the comments, which you always expect to devolve into blathering screeds that eventually result in someone being compared to Hitler, especially on a topic like this, add nuances to the discussion.

I also wonder if there's an east coast difference, or perhaps a financial industry difference. I don't run into a lot of those stereotypical, non-communicative, "don't touch my code" types around me. We still don't have a huge percent of women in IT, but that could be because women are smarter and go work on the trading floor where they make up a significant percentage and the pay is much higher.

The managers I've been around and the hiring I've participated in have actively tried to recruit more women.  Everything being equal, we'll actually hire a woman over a man simply to increase our diversity.  I would go so far as to say that many people I've worked with would pay a bit more to hire women.

But the financial industry, for all its faults, does a relatively good job at institutionalizing the need for diversity.  And New York is diverse like no place on earth.

Unlimited vacation

I've been noodling over this idea of unlimited vacation.  It appeals to my feeling that people should manage themselves. 

And this argument really resonates:

In Freedom, Inc. Gordon Forward of Chaparral Steel talks of the danger of ”managing for the 3%.” In a large enough organization, there might be a couple of people who would take two or three months’ vacation–but if a vacation policy is the only thing holding them back from that, they’re probably “vacationing” at their desks anyway. And so the policy is concealing the problem with that “3%,” not eliminating it.

This relates to the idea that, if you're hiring correctly, then you won't have abuse.  It makes me fear that I might have hired the wrong people.

But just recently I met a guy who actually works at a company where they have unlimited vacation.  He pointed out a critical factor that I completely overlooked: company culture.

In his company, everyone pressures everyone else not to take vacation.  If you ask for a block of 2 weeks off, they'd laugh at you.  You'd have to explain it to a lot of people, because it would keep coming up.  Even a short vacation doesn't go unnoticed.  "Must be nice to have a vacation.  What, not enough to do?"  It's public humiliation.  The company culture doesn't allow for violations. 

My new friend finds that he takes less than 2 weeks off in total every year.

At my company, many people take 2 week blocks off every year.  (In fact, it's a requirement for systems security.)  You get 3 or 4 weeks, and if you don't use it all, you carry it over and have additional time the next year.  It becomes your right to use it.  This seems normal to me, because that's what I've always had.

Would the social pressure work in my company?  On the whole, no way.  It's too big, and it's tough to change the culture.

On the other hand, there's frequently pressure to work long hours.  It usually emerges as joking jabs -- "Wow, you're leaving at 4:50?  I mean, before 5???" -- but underlying it is the general expectation that people work long hours at investment banks.  That starts with the bankers and trickles down.

So, in my group, if we had an unlimited vacation policy, it might very well turn into a vacation deprivation policy. 

In retrospect, it's almost surprising that more companies don't go to unlimited vacation.

"The real challenge of outsourcing"

From Seth Godin's Meatball Sundae:

It's clear to me there are only two paths.  One path is to take every repetitive, by-the-book task in your organization and outsource it or mechanized it.  The other path is to take every repetitive, by-the-book task in your organization and give the people who do that task the freedom, the incentive, and yes, the imperative to do something that cannot be outsourced.

Either what you're doing is repetitive, in which case you ought to outsource it, or it's homemade, insightful, and filled with initiative and judgement, in which case you can charge for it.

Too often, managers try to have it both ways, and end up with clever, skilled people who move on due to boredom, or "idiots" who can't do the job.  Their failure to make a strategic choice ends up in a bad personnel result.

Similarly, software development -- including app support -- should be thought of similarly.  Programmers, almost by definition, should not be doing something twice.  Give the clever, skilled ones the freedom to minimize the mundane and repetitive.  And if you still have a lot of it around, you've probably kept the wrong ones.

Interview techniques: best man for the job

 Sometimes, literally:

The other question I ask is if they’ve ever been in anyone’s wedding party. If someone has asked them to stand next to him on the most important day of his life, at least one person thinks they are responsible. It means they’ve been able to establish and continue a relationship. It’s not always true, but if you build strong relationships with people, you tend to go into a management meeting or a negotiation and come out of it with some respect.

An offbeat idea, to be sure, but at least it catches people in a moment of honesty, and it provides a reasonable minimum personality requirement.  Not to mention, it beats the heck out of the standard way, which Seth Godin neatly and swiftly destroys.

Your company may not do the trial / intern thing, and for technical jobs, a coding test should be 100% standard.  I don't necessarily go for a 10-line program like Jeff Atwood -- I like more open-ended, longer tasks -- but I prefer any real coding task over asking very specific questions about language syntax, which, to me, are the job interview equivalent to "What did Huckleberry Finn eat for lunch?" questions my English teacher would ask on tests to try to make sure you read the book.  Even if someone knows the answer, what does that prove she learned about the story?

Out of business

I passed by an empty store front that used to be a restaurant.  Above the front door and window, they had a big awning with the word "RESTARANT".

Maybe they had the best food in the world there.  Maybe the nicest wait staff, and the most organized owners.  Maybe.

But I'd be willing to bet no.  Even if they hadn't been out of business, I would hesitate to go there just based on the sign.  Can one typo really mean that much?  Well, if they can't bother to spell correctly a few words that they're paying thousands of dollars for, what are the odds they're going to do the $10 dinner really well?  Sure, if all my friends ate there and assured me it was delicious, I'd give it a shot.  But chances are they won't get that shot from my friends either.

One reason I like to give code exercises on job interviews is to see the coding grammar of the applicant.  Basically, I want to know how easy to read their code is.  So I also look to see if they've modularized, or they just have one big function.

I also want to see how complete it is.  What kinds of errors did they anticipate?  How robust is the solution?  Is it extensible? 

What I don't do is give knowledge tests.  In fact, I like to sit someone at a computer, and they can have all the time they want to google up however much help they need to finish the code.  Because, frankly, if you can walk in not knowing the language and write me a very small mini-app in a few hours, well, you're probably the right kind of person we want to hire anyway.

But, more importantly, even with the time constraint removed, and knowing that this work will be reviewed, it is surprising how many people will sloppily have typos and lazy naming.  All single-letter variables.  No naming convention.  Very basic words misspelled.  No indenting.

Does this stuff matter?  Some might say no, but I think if you can't bother to get this right when you have no time constraint, and your own money and career are on the line, what are the odds you'll do it under pressure and it's someone else's (the company's) money at risk?

The wrong way to hire someone

According to Seth Godin:

The wrong way first: interview someone for an hour. If you like them, have them interview three or four other people in your organization for an hour each.

Hmmm, that sounds strangely familiar -- oh yeah, it's pretty close to how I've done it. And frankly my results haven't been that great; I've made a few stinkers along the way.

In my defense, it would be bureaucratically impossible where I work to use freelancing and trial periods, which is what Seth recommends. On the other hand, I have a feeling that doing 3 or 4 people for an hour is the default, I-didn't-give-this-any-thought method. Which makes me suspicious.

Hiring is too hugely important to do without a well-considered strategy, even more than compensation.

Investment banks commonly go the other route: an hour interview with 10 - 12 people. This sounds ludicrous compared to Seth's ideas, but then Goldman, Sachs does that, and their staff regularly beats up the other Wall Street firms.

Toward the end of the last hiring phase (which was a very long time ago now), I changed to 5- to 10-minute phone interviews as an initial screen, and then 20- to 30-minute in-person interviews. I don't know that the results were any better, but I don't think they were worse, so the time saved made it a net plus.

Hiring is tough because it's a little like picking someone to marry after a round of speed dating. You only know if it's going to work once you're in the relationship, which is Seth's point exactly.

In lieu of that, companies try to do group activities, written tests, psychological exams, etc. -- all attempts to get beyond the words.

One great idea was Jeff Atwood's suggestion to have the developer give a 10-minute presentation about their last project to 4 or 5 people. Not only are you looking for clear thinking and communication, but what someone talks about says a lot about how they learn and what they do well.

Once things turn around, I'm looking forward to trying some new hiring techniques.

Software development as group activity

The stereotype of a software developer is a kind of loner cowboy who gets the job done.

What bugs me about this is that, occasionally, a developer will create something from scratch that the guy in the next cube built a couple years ago. Or the implementation will be ill-conceived, even though the best architect sits no farther than a paper airplane could fly.

This makes me appreciate Agile development. I find it gets developers talking, even if it's simply an extended version of, "I'll do this, you do that." Developers who talk about their work are more likely to generate new ideas or solve problems effectively.

Teams are powerful.

In my experience, the basic tenets of Agile development -- e.g., daily scrum, rapid iterations, burndown, backlog -- together provide a useful scaffolding for getting individuals to work as a team. The first time I got all the pieces working, I was actually amazed at how the team took off on its own. The individual parts of Agile practices actually serve as a metaphor for a team: each part can be ineffective by itself, but together they become very powerful.

I only wish for better alternatives to pair programming. The guidelines for pair programming seem oppressive -- switching pairs every 4 hours! I haven't yet met anyone who actually does it as specified, and I haven't been courageous enough to try it myself (nor strong enough to convince any of my bosses).

But I definitely like the idea of getting programmers to work even closer together.

Jeff Atwood mentioned a very clever idea (which he apparently had 4 years ago) for how to screen for developers who will be more inclined to work with others:

I have my own theory about the ideal way to interview developers: have the candidate give a 10 minute watercooler presentation to your team on something they've worked on. I think this is a far better indicator of success than a traditional interview. You'll quickly ascertain:

• Is this person passionate about what they are doing?
• Can they communicate effectively to a small group?
• Do they have a good handle on their area of expertise?
• Would your team enjoy working with this person?

This is absolutely something I will try.