A couple of new blog posts (1, 2) by Anil Dash have sparked a lot of discussion (see here and here, for instance) about the value of diversity–specifically in this case, gender diversity–in high tech.
This is a timely topic for me. At work, I’ve recently joined a newly-formed development team. As we were sitting in team meetings this week, I realized that there is only one woman on this team (and she is the product owner, which, in our development methodology, makes her kind of an adjunct team member).
Our other two teams at work have at least two women members (all QA and technical writers; we don’t have any female programmers), and I’ve been very pleased with the team dynamics of both those teams.
For several reasons, I’m currently slightly uncomfortable with the dynamics of the new team, and it struck me this week that one of those reasons is that it felt kind of ‘good-ol-boy’ish. After reading Anil’s posts and some discussion of them, I emailed the team lead to discuss the issue of gender diversity on the new team. We’ll see what happens.

I’ve heard repeatedly that there is an order of magnitude difference between the most and least productive programmers. I have no doubt that’s the case, but recently I’ve experienced that difference first hand, and I’ve also come to appreciate the effect of experience on that difference.
We hired a new QA engineer a couple of months ago, and I’ve been working with her closely the past few weeks. She’s very smart and seems to have high technical aptitude, but she doesn’t have much experience with the type of tasks we’ve been working on–dealing with various DBMSes. I’ve worked repeatedly with three of the four DBMSes and know quite a bit about the subtle differences between them. Furthermore, I’ve worked with DBMSes enough to know how to figure out how to do different tasks in each one. This experienced also helped me to get up and running with the one (DB2) that I’m not experienced with.
In this situation, I was an order of magnitude more productive due to my experience.

Guy Kawasaki offers twelve skills “students should learn in order to prepare for the real world after graduation.” They are:

1. How to talk to your boss
2. How to survive a meeting that’s poorly run
3. How to run a meeting
4. How to figure out anything on your own
5. How to negotiate
6. How to have a conversation
7. How to explain something in thirty seconds
8. How to write a one-page report
9. How to write a five-sentence email
10. How to get along with co-workers
11. How to use PowerPoint
12. How to leave a voicemail

(Go read the entire blog post for Guy’s comments on each item)
I don’t think that these skills should be explicitly taught in college, but I agree that they are valuable career skills.
For the record, I hate it when people refer to ‘the real world’ vs. college. It tells a lot about the speaker though.

As the video below demonstrates, getting computers to work with human language is hard–even after decades of research and development.

The scene: Sitting with several coworkers in the conference room waiting for someone in another location to join a conference call. Everyone is awkwardly quiet.
Coworker 1: So, how about those Mavericks? Wasn’t that an awesome game last night between them and [some other sports team]?
Other coworkers and me: <blink>
Silence.

For my new job, I’ve been re-reading Agile Project Management with Scrum by Ken Schwaber. In the Introduction, the author says that common sense is a critical element of the processes that he outlines.
I’m usually wary of appeals to common sense, as they are often used in conjunction with various logical fallacies. In this case, however, I really like Schwaber’s definition of common sense. He says that it “is a combination of experience, training, humility, wit and intelligence.” It really surprised me to see humility and wit in his definition, and it was a good sign that I would like the author’s point of view more generally.

Three weeks ago, I started a new job: QA engineer with Borland Software. I couldn’t be happier. The group that I’m working with is implementing a full-blown agile/scrum process. When I was interviewing with Borland, I told my interviewers that I’d used some agile methodologies in previous jobs. But now that I’ve been participating in a real agile methodology, I realize that there’s a fundamental difference between adopting some of the methodologies and adopting the philosophy of agile/scrum: it’s all about respect, truthfulness, collaboration, visibility, continual feedback, putting individual egos aside for the greater good, etc.

I filled out a form on a web site this morning, and I noticed the date below:

It’s an awfully long time past the year 2000 for something like that to still be showing up.

You know, I fully embrace the principle of doing HTML layout via CSS vs. the old fashion table layouts, but the browser implementations of CSS still differ so much that it’s been a huge pain every time I’ve tried to implement more than rudimentary CSS layouts. As you have surely noticed if you visit here regularly, I recently converted this blog to one the newer MovableType templates, and then have been tweaking it to my liking. But the stylesheet for this template is over 1000 lines long, and every time I’ve tweaked it, I’ve encountered different behavior in Mozilla and Internet Explorer. Frustrating.

So, my coworker from Professional Services walks over to my desk with his laptop and our company’s application running (names changed to protect data integrity).
Coworker, pointing to laptop screen: “Where did all this [blah blah] data come from?”
I answer: I entered it into our application from that spreadsheet you sent me about [blah blah] data configuration.
Coworker: What spreadsheet?
Me, typing furiously, then pointing to my laptop screen: the spreadsheet attached to the intranet wiki page about [blah blah] data configuration.
Coworker: Where did that spreadsheet come from? I didn’t send you that.
Me, typing spreadsheet filename into Google Desktop Search, results showing an email from Coworker with said spreadsheet attached: Ah, but indeed you did.
Coworker: I’ll be darned.
Score one for Google Desktop Search.