It is with great hesitation that I point out that boc is on Stand Out Jobs. I can’t stand hearing myself on the phone little on seeing my mug in a video. In our defense, we had no script, came up with the concept almost on the spot, and only had 1 take.

Stand Out Jobs is a new startup founded by Austin Hill and friends. They’ve charged themselves with “changing the face of recruiting”.

“Don’t forget, if someone tells you they have the answer, they probably don’t understand the question.”, C.K. Prahalad.

So that’s what a DemoCamp in Guelph looks like.

#2 is in the works, it’ll be sometime mid July, sign up! Get on our google group as well.

Well it’s done. As someone says somewhere, DemoCampGuelph1 is in the can! I’m clearly biased but I’d say it was a success. I met some new folks and had some pints so personally I achieved my only goals. In the end we managed to fit in six demos after a late start:

• Mark Roseman: CourseForum
• Chris Iwanowski, “speaker’s corner” kiosk application we just developed for Guelph Museums.
• Simon Clark
• Holden Karau
• Kevin Thomason, aideRSS, Filtering/managing your RSS feeds – basically, taming the RSS beast
• Colin Smith, Adobe.

Highlights

• Great venue. You can’t go wrong with 1/2 price burgers.
• Great gear. Once Colin showed up and got his pimped out gear out. The downside is we’re hooked on the good stuff now.
• As Holden would say, awesome set of demos.
• Somehow managing to have David Crow not only bring up Apollo but ask Colin from Adobe about it.

Need to work on

• The host, or MC, was a dud.
• Better structure and timing of the demos to ensure everyone gets similar showing.
• Maybe nametags next time? I had bought some but forget to put them out.
• More heckling and casual banter. It was great to have David Crow there to stir the pot and show us how it’s meant to go. We need to keep working on this and get the interactivity up but for first timers I think we did alright. I think part of this is just getting to know each other so we’re as comfortable saying “piss-poor effort” as David.

Thanks once again to everyone who showed up and helped make this work. Now get signed up to our google group and help us start planning #2!

Last call for DemoCampGuelph1. Tonight, Albion, second floor, 6:30 to 8:30pm.

Hopefully it’s not just bubba and I having pints….

I just read Lifehacker’s top 10 ubuntu applications and discovered two lovely applications I hadn’t tried:

• Katapult, similar to Mac’s quicksilver.
• CheckGmail

I agree with their take on Amarok and may give Kopete a try someday but Gaim works fine right now.

Along similar lines as my email usage post, I’ve returned to the way I previously used IM. That is, explicitly turn it on when I need to have a conversation. I used to always tell people, don’t rely on my IM status as an indicator of whether I’m ‘online’ and my usage reinforced that.

Unfortunately, my usage of the past year or more has been the opposite, which means over the short term people will assume I’m not ‘online’ much.

Does this make me less available? In my opinion no as my phone is still here on my desk and I’m still answering it. It does, however, place more burden on callers to triage. Not having IM open all the time places that same burden on me. Where I often wouldn’t hesitate to IM someone about a topic, I’ll now hold off, solve it myself, or pick up the phone and have a quick conversation.

In the end I’m not phoning people as much as I used to IM them. That means I’m doing a better job of triaging on my side and therefore interrupting people less. I’m being interrupted less, I’m interrupting others less, and when those interruptions happen they tend to come to resolutions faster as we’re on the phone talking instead of hacking away in IM. The main reason I use IM, even when on the phone, is to send http links to people I’m talking with. IM is better at that than the phone.

Of course I’m sure some of the people I phone all day long may state otherwise.

I’m looking into moving some of our projects to some form of a tool-assisted code review process. The intent is to stay clear of traditional ‘big company’ reviews and all the emotional baggage that goes along with those. The goal of our reviews will still be better quality, more maintainable software, however, almost equal to that is to generate team collaboration in the context of actual code.

This is about mistakes and finding them, however, that cannot be a negative experience. To state it the other way around, he who makes the most mistakes wins. This will be about finding mistakes as early as possible, learning from them, and moving forward. If you fail on that part and drift into using the number of mistakes as a carrot or stick then you’ll build development teams that are very good at hiding their mistakes which is terrible for everyone involved.

Bugs are good. Mistakes are good. If you aren’t finding mistakes then something’s broken. Your testing could be broken, your developers may be hiding or not fulling disclosing bugs. Another, equally bad possibility, is that your developers aren’t pushing themselves and are instead only doing what they are 100% certain they can safely deliver. If that’s the case then I guarantee you that you’ll be sitting in a meeting someday soon titled “How do we get our developers to innovate?”.

I’d like to try an open source product but at this point I’m most impressed with what SmartBear has. Some related links:

http://smartbear.com/docs/BestPracticesForPeerCodeReview.pdf
http://www.ganssle.com/Inspections.pdf

and a free book offer…
http://smartbearsoftware.com/codecollab-code-review-book.php

I only saw this related post now, I swear.

Timothy Ferriss is getting a load of press these days for his recent book. He also has a nice preview of the book available in the form of a ChangeThis manifesto.

I haven’t read the book so I can’t comment on it directly. I do know that one of his key suggestions is to take control of email. I’m in complete agreement with him on this, however, I’ve managed to drift away from the practice in the past two years.

The basics? Close your email client. Only open it once or twice a day at explicit times.

I first began practicing what is essentially the same thing Timothy suggests back in my MKS days. I was inspired to do so after reading The Tyranny Of Email, written back in 2003.

In short, I’m working my way back towards this. The migration is less about my email habits than it is people’s expectations of my habits. Everyone’s used to me responding almost instantly so I need to work them towards a new pattern. Or technically an old pattern that I somehow abandoned.

If you’re in a rush to get back to your email, Ole has a great summary:

1. Turn your email client off. Pick the moment at which you’ll be interrupted.
2. Never criticize anyone in email, and avoid technical debates. Use face-to-face meetings or ‘phone calls instead.
3. Be judicious in who you send email to, and who you copy on emails.
4. Observing some formality is important.
5. Don’t hesitate to review and revise important emails.
6. Remember that email is a public and permanent record.