In a talk on IDE tips and tricks for Visual Studio, I asserted that good programmers are ten times as productive as ordinary ones. I didn't remember where I'd read that, but I knew it was true. I've just worked with so many folks who need a week to do what some superstars can do in a morning. The ordinary guy needs half a day to find some samples that are similar, half a day to tweak them so they fit into the current situation, a day to test and realize they aren't quite right, a day to adjust them and then fix the things that broke while adjusting them, half a day to get distracted and lured into scope creep by some comments during user testing, then another day to fix up what they did that they shouldn't have, and finally a half a day to clean things up and make documentation. The terrific guy only spends an hour finding samples, stays focused, documents and tests along the way, and makes short work of a specific small task. And I find this holds over months and years as well as over the course of a week.

Now I bumped across a proper cite of that, and not surprisingly it's from the Mythical Man Month. The quote and some related musings is over on Phil Haack's blog. Worth reading and worth thinking about. There are many ways to be productive ... write code that solves the real problem, don't write buggy code, don't write brittle code, and so on.

Kate

One of the things that people comment on when they work with me is how much of a keyboard shortcut person I am. In fact I really like the fact that Vista supports my typing-preferences and doesn't make me mouse so much. But when I'm presenting, I try to use the mouse as much as I can and stay away from keyboard shortcuts. I just find such presentations hard to follow myself, when I don't know what the demo-ing person is typing and what shortcuts they are using. It's easier to see what they are clicking on.

This became a bit relevant during Speaker Idol when I mused aloud about whether to dock Mark Miller for using CodeRush while demo-ing. Anyone else I would definitely have told not to, but perhaps Mark has a dispensation. I just find that many attendees can't follow along with the blazing speed that CodeRush enables and really lose track of the demo.

Roy Osherove has put together a little utility that displays your shortcuts as you type them. His first post on the topic suggests its value to presenters, while his second one focuses on using it to become more keyboard oriented or to train a coworker to be more keyboard oriented. If you really can't switch to the mouse while presenting, consider using this utility so that people can see what you're doing.

Kate

Can you lose weight by coming to Canada? Yes you can, but not mass, just weight, because apparently gravity in parts of Canada differ from elsewhere in the world. And this is some sort of slow rebound from the retreat of the glaciers...

http://www.livescience.com/environment/070510_odd_gravity.html

Kate

Just a small personal observation. My oldest child turned 18 and is now technically a grownup ... though of course still living at home and still technically in high school ... graduation is only six days away though. So many of my fellow RDs and MVPs are new parents, it seems strange to be approaching "the end of the beginning" of my parenting journey. But that's how it is.

Kate

There is a lot of confusion about writing your own exception classes. I see far too much code out there that just catches "Exception" anyway, that I hate to complain about someone who has set themselves up to have different catch behaviour for "The server is probably offline" than for "you probably don't have permissions on that file you just told me to use". However those who write their own exceptions have generally derived them from ApplicationException. If you ask why, they say things like "well" and "er" and "um" a lot because there's no extra stuff in an ApplicationException compared to an Exception. It just made it possible for you to catch "ApplicationException" and know it would be one of yours and not from some framework code.

Only thing is, that didn't really work out -- some framework code throws exceptions that derive from ApplicationException. And really, catching ApplicationException is just as generic as catching Exception. What can you meaningfully decide to do when all you know is "some code I wrote is unhappy in a way that the built-in exceptions (invalid argument, access denied and so on) cannot properly express" ?

So the word is out. Don't inherit from ApplicationException. Got it.

Kate

Here is something really cool. If you happen to hold Shift while you right-click a file in Windows Explorer, you get more options on the menu:

The one I'm most likely to use is Copy as Path. Lets say you've just put a file on some shared drive somewhere and now you're emailing someone that you've done so, or you're passing the full file name to another application, or you're recording the file name in the files itself so that printed copies make sense. You need to copy the path from the address box, then the file name - it's annoying. This little trick doesn't save a ton of keystrokes, but I like it.

Kate

Recently we took a large SharePoint project live at a company that is acquiring others quite fast, and having trouble keeping its Active Directory situation up to date as new domains are assimilated. When the project first went live, everyone had to authenticate to the server when they first browsed to it, and in some cases a second or even third time, depending on what kinds of files they opened, whether they followed links to other internal servers, and so on. As you might imagine there were plenty of complaints from folks who didn't like having to authenticate all the time.

We as the developers couldn't do a lot about this, but we worked hard with their IT folks and did a few clever things of our own until we achieved single sign on glory. Workers throughout this global firm would sign in to their own Windows desktops, and from then on everything in their whole intranet was theirs with no more authentication needed. Of course it was all strictly controlled - only HR people could see the HR files, only Finance people could see the Finance files, and so on. But it was perhaps a little too transparent. After we achieved this lovely state people stopped emailing to complain about authenticating, only to be supplanted by a new chorus of complaints from people we hadn't heard from before. The most poignant read simply "Everyone can see all my files!" and was accompanied by a screen shot of a browser opened to the HR area. Our correspondent hadn't been challenged for a password and was therefore sure all these files were completely unsecured. It took an in-person visit that included "why don't we go over to Bob's desk so you can see what the portal looks like for him?" to finally convince this user that invisible security is still security.

For all I know, there are scores or even hundreds of people in that firm who don't realize their sensitive information is protected. Typing in a password annoys many users, but it soothes others.

Kate

I got a real aha moment when I saw this graph:

The blog post where I saw it was talking about "management by ..." but I think it also applies to the motivation that individuals are moved by. That is, relative newbies to a job tend to do things a certain way because those are the rules. As they progress over time, most of them move on to "this is the method I use" and then to "my team's objectives are" and finally "this is what my team values." I think this is a hugely important progression to understand.

Let's take one little thing, say source control behaviour - do you check in too often, not often enough, are your comments any good, are your changesets too big or too little, and so on. If I want to direct your source control behaviour I need to know what zone you are in.

• If you're in the "rules" zone, I must tell you the rules for source control. I need to write a long document with lots of examples and if there are exceptions, or different rules for different projects, I need to elaborate them all. Whenever you do something "wrong" I will probably hear that you were just following the rules, and I will need to update the rules to attempt to prevent that problem in the future.
• If you're in the "methods" zone, I must cover source control in the documentation of my methodology, put it into context, show you why we use it and how things you type at step 17 will be used by someone else at step 35. The rules don't need to be so black and white or so detailed, but there may need to be different methodologies for different kinds of projects or circumstances. If I correct you I am still likely to hear that it's because the methodology is flawed.
• If you're in the "objectives" zone, I need only remind you that we need to be able to pick up projects again for a version 2 long after we shipped version 1, or that we need to be able to recover from two people editing a file at once, or that we need to be able to explain to clients which files are different in version 2.3.4 than they were in 2.3.3. The detailed rules can go; you will choose your changeset size and your comments knowing which of our objectives you are supporting when you do so. If you make an incorrect decision and I point it out to you, your response is most likely to be "oh" and then you will adjust your own internal set of rules and methodologies accordingly.
• If you're in the "values" zone, it's even simpler - we value making money on each project, and serving our clients well, and you know that, and you have the capability to make the right decisions in order to support those values. I barely have to manage you, just provide you from time to time with information.

In contrast to the blog where I found this graph, I don't see it as just being a matter of how managers choose to manage their projects and people. I see that some people cannot be motivated by values alone, or objectives alone. Either they lack the career maturity to recognize that supporting the team's objectives is always in their own self-interest, or they lack the skill and knowledge to choose correctly (should I check in now? or wait till I have tested? or wait till I do those other changes?) knowing only what outcomes are important to the team.

I personally don't care for the rules-oriented phase. Writing out exhaustive "if this happens do that" documents is not really fun work. Hearing that a flaw in the document is why something went wrong also doesn't really work for me. Yet it seems all team members (and by this I mean not just my own staff, but my clients and their staff, other vendors, and so on) need to go through this phase when adapting to a new process. Well, knowing it's going on makes it easier for me to cope with it.

Kate