The last time I went to a user group meeting I got to meet a very interesting fellow named Udi Dahan. I've seen him a couple of times before in previous meetings, but I didn't know him. Apparently he's been reading my blog(and all the other blogs in this great community) for a while, and has a lot to say and contribute in many .Net areas.
You can spot him easily in the user group meeting - he'll be the tall guy wearing military uniform and asking all the right questions. Truly, he seems to be one of the most intelligent persons I've met. We got to talk by email a bit, but in the last meeting he came up to me and introduced himself. After the meeting ended we got to talking a bit about what he does(hush hush) , how he does it and all the other stuff a developer asks the first time he meets another developer.
In one of the past emails to me, Udi suggested that I take a more active approach and start lecturing in the user group circuit. I always thought about doing that, but always “chickened out” at the last moment. When we met he told me that after he emailed me about it, he asked himself “why don't I do as I preach?”, and got himself his own lecturing gig!. He'll be lecturing in the upcoming .Net web developers users group next month about performance Do's and Don'ts in .Net. That is so cool. I really admire someone who just goes out and does stuff like that. I should do the same. I have no idea what subject I could talk about though.
Anyway, getting back to the meeting with Udi, we talked about what performance issues he'll bring up. Turns out the talk will be about what you shouldn't do just as much as it will be about what you should do. Sometimes people can go in wild and crazy directions just to get performance gains that are insignificant compared to the amount of time they lost researching it (on project budget!). What Udi wants to say is that sometimes you should know when to stop and look back and get the bigger picture. Or maybe have a different way to achieve almost the same results.
I just know this will be a talk that won't go down easy with the crowd. Every developer thinks they know best when it comes to their code and technique. It's hard for people to accept new ways of doing old stuff. Whatever happens, it's gonna be an “energetic” and probably pretty interactive discussion. Of course - it's gonna be very very interesting. I should come in with an open mind.