You've reached the internet home of Chris Sells, who has a long history as a contributing member of the Windows developer community. He enjoys long walks on the beach and various computer technologies.
Wednesday, Feb 15, 2006, 4:50 PM in The Spout
A Reviewing Trick I Learned A Long Time Ago
I learned this way of reviewing artifacts from Cal Caldwell, a friend of mine from my instructor days. The technique is for doing code reviews, but I'm going to be using it later this week for some design docs. Anybody who recognizes this technique can chime in with what it's called:
-
Every reviewer gets a different "hat," i.e. a POV that they adopt when reviewing, e.g. looking for coding guidelines, looking for readability, looking at a feature from an architecture pov, looking at it from a particular customer pov, etc. Anyone can have feedback on anything, but the idea is that with different folks wearing different hats, you get a greater coverage.
-
Every reviewer brings review comments to the meeting, i.e. you reviewer before hand and only report at the meeting.
-
Every reviewer must start with something nice! Too often, engineers focus on the negative. Saying nice cushions the blow and reinforces the good things so that they don't get cut.
-
Each piece of feedback will be logged (hopefully by the person that provides it) and spoken to the reviewee, but will not be argued with. If a reviewee disagrees, they keep it to themselves, asking only clarification questions to make sure that they understand the feedback. What feedback is applied it up to the reviewee and any follow up arguments happen offline.
That's it. The best code reviews I've every participated in used this technique and I can recommend it highly for that. On Monday, we're going to use it to get through a large number of design docs, so I'll let you know how that goes.
Wednesday, Feb 15, 2006, 10:04 AM in The Spout
Scrum is very focusing
We started using scrum in my group this week and I'm already finding myself pushing aside work that I would normally sign up for in other groups. Scrum gives you to choice of being able to say "I did what I said I was going to do yesterday" or "I didn't." I want to always be able to say the former or have a good reason why not. Is "I was working with this other group" a good reason when the rest of your team is focused 100% on the thing? This is going to play hell with MS culture, but in a good way, imo.
Friday, Feb 10, 2006, 1:03 PM in The Spout
Multi-Touch Interaction Research
Wow. I wonder how many years that existence of the mouse has set us back because it delayed us from using this.
Friday, Feb 10, 2006, 8:58 AM in The Spout
My Favorite Wiki: pinvoke.net
I guess wikipedia is cool, but the wiki that provides a vital service in my life is pinvoke.net, which provides an enormous, user-contributed list of Win32 API mappings for .NET. I find it useful not just because folks are contributing tons of stuff I use, but also because I find it a wonderful place to drop code for my own later use, e.g.
This is the closest thing I've seen to a working code repository that is just as easy to contribute to as it is to use. Highly recommended.
P.S. I think this kind of functionality should be built into the SDK docs. I'll ask 'em.
Friday, Feb 3, 2006, 4:59 PM in The Spout
PM Skill #7: Use That Meeting Time!
It's very easy, as the PM, to not want to waste team time in a meeting, letting folks go when there's still 30 minutes left. In fact, lots of folks will praise you for your short meetings. That's fine if all of the work for that meeting has been done, e.g. everyone's reported their status, all of the open questions have been decided, etc.
However, it's often the case that in these meetings, other issues will come up to be discussed in future meetings to be scheduled at another time. Don't let your concern for your team mates' free time tempt you to let 'em go! It's hard enough to get the folks you need together in a room. Once you've got 'em there, use 'em.
For example, if you've got the team together for weekly status that's scheduled for 60 minutes, it often only takes 30 minutes. In that 30 minutes, you may decide that a subset of the team needs to get together for an hour design discussion on whether to spinning text boxes to your next software project. As a dutiful PM (aka "mom"), you'll often find yourself saying, "Sure -- I'll set that up." Then it's your job to find an hour on everyone's calendar while that issue remains open and the project drags on.
Don't do it! Instead, peel off the folks in the status meeting that need to be in the "hour design discussion" and have the meeting right then and there. You've already scheduled the weekly status for 60 minutes, so you know those folks are free and just dying to get back to reading email in piece in their office -- put 'em to work instead! Who the hell knows how long a design discussion is going to take anyway? It's just as likely to go under an hour as over, so you might be able to wrap up the issue right then and there, skipping the need for another meeting altogether. Believe me, your team mates will thank you for that!
Tuesday, Jan 31, 2006, 5:29 PM in The Spout
Japanese version of Avalon book
I thought someone might be interested in the Japanese version of our WPF book. Personally, I love the cover.
Tuesday, Jan 31, 2006, 2:50 PM in The Spout
Pre-order "Windows Forms 2.0 Programming"
I just noticed that "Windows Forms 2.0 Programming," by Michael Weinhardt and Chris Sells, is available for pre-order. I've had a lot of requests for info on this book, so now folks can watch this space. Mike and I have finished the copy edit rounds, but we still haven't seen the final PDFs, so it's still going to be awhile (hopefully no later than early April).
Tuesday, Jan 31, 2006, 11:00 AM in The Spout
IE7 Beta 2 worth the download
I've been using IE7 for the last week or so and it's definitely worth the download. Just Ctrl+/Ctrl- itself is worth the upgrade, imo...
Wednesday, Jan 25, 2006, 1:00 PM in The Spout
Imperative vs. Declarative
Savas showed me this great example from a book he's reading. Consider this:
F = m * v
Using an imperative interpretation, this is a expression that, when evaluated, multiplies m and v, putting the result into F.
Using a declarative interpretation, this is an equation and is completely equivalent to the following:
m = F / v
The imperative interpretation allows me to execute. The declarative interpretation allows execution as well as addition reasoning.
Sunday, Jan 22, 2006, 10:10 AM in The Spout
Netflix for Books?
I know, I know, "I hate books." Still, books are where most of the content I love is, so I live with 'em. However, it'd be nicer if there were a Netflix for books, like there is for DVDs and games. I think the public library should be become such a thing and I'd happily pay $15/month for mail delivery and return.
Thursday, Jan 19, 2006, 11:48 AM in The Spout
I want a service that "rips" books
Assuming the Sony Reader is cool, I still won't have all the content I want and I certainly don't want to repurchase all of my books. In the same way copyright law enables me to backup my CDs and DVDs, I want to "rip" my books and comics for electronic use. I'd like the same technology that the Google and the Amazon folks are using to digitize existing books (the folks that litter USENIX with copyright materials must have a cool setup, too). My understanding is that, unlike CDs and DVDs, which are easy to read via computer, books are not, so I'll need a service where I can box up my books and send 'em for ripping, resulting in a shiny DVD filled with my words and images, ideally OCR'd enough to allow full text search. In fact, after a while, the book rip houses would have most books on file, so I'd only have to prove that I own a book and they could email me the electronic version, saving us both the shipping charges. In further fact, this is an additional service that Google and/or Amazon could provide, since they're already "ripping" the books they sell...
Wednesday, Jan 18, 2006, 4:22 PM in The Spout
I Hate Books
I hate that indexes suck and that they don't support full text searching across my entire collection.
I hate that I have to guess which ones I'll need or want so that I can carry them with me.
I hate that I need a light to read them, potentially bothering the driver or a sleeping spouse.
I hate moving them, making shelves for them and searching for them on the shelves.
I hate that I can't take notes in them -- not even the ones I own -- without breaking out into a cold sweat (although, to be fair, that's more about my librarian mother than the book itself : ).
I hate that I have to buy a book twice if I want to listen to it instead of read it (and I hate that there's no way to pronounce pictures or code).
I hate that if the local book store doesn't have a book, that I have to wait for somebody to deliver it.
I hate that my local book store doesn't have reviews of the book, whereas my on line book store doesn't let me flip to whatever page I want.
The one thing I don't hate about books is the content. That part triggers my thoughts and my emotions in me that are so strong, I put up with all the things I hate so I can get to it.
Why isn't there an iPod for books (is it because iBook is already taken)? Why isn't all print media, e.g. novels, poems, comic books, news papers, magazines, etc, available in electronic format?
Tuesday, Jan 17, 2006, 9:49 AM in The Spout
PM Skill #6: Be The Team Mom
In an ideal world, a PM would be able to get together with their team, lead the discussion 'til everyone agrees what they're going to do and while they're doing it, hang out on the beach answering the odd question on their smart phone 'til the work is scheduled to be done.
At Microsoft, we don't live in an ideal world.
Instead, we have roving bands of PMs prowling the halls looking for resources, trying to get things done. Because this is an accepted part of MS culture, people actually listen when a PM shows up at their door to pitch their idea and ask them to help. And, so long as it fits into the broad goals they've set up with their boss and their other commitments, and it's more fun then the thing they're supposed to be doing, they often say "yes."
This means that folks on your team often have multiple commitments that they have to decide between. It's like when you get married or close friends, you're going to have more than one family to visit at Christmas time. However, you have to put your blood relatives first, making them your top priority and squeezing in the other families when you can, e.g. Christmas Eve Eve.
As a PM, you have to know what the "blood relationships" are for each of your team members. Are you their second or third family? If so, you have to take "Christmas as celebrated on." However, if they're in your first family, then you take top priority and you should feel free to act like their mom.
Traditionally, it's the mom's job to make sure people are healthy and happy (doing stuff they like), making sure that they're eating right (getting pizza during late night coding sessions) and that they're getting special treats when they deserve them (public announcements praising their work).
Likewise, it's the mom's job to remind them of their chores (their task list), check their report card (make sure their tasks are up to the quality bar) and to guilt them when they forget Mother's Day (keeping up with the schedule).
As the PM, you're the team's memory, the catch-all for crappy tasks nobody else wants to do and the one that makes sure everyone is working well together. You're the glue and the conscience. If the teammates on your team aren't waking up thinking of tasks you want done and going to bed hoping they're making good progress on your tasks, then, according to MS culture, that's your fault.
So, make sure folks are unblocked and happy, but also make sure they're doing what you consider their top priority and that they're doing it right and one time. Trust that they're doing what they should be, but make sure they know what you think they should be doing and that they're doing it right.
The downside is that such a world doesn't scale without PMs at every level, but that's why MS has PMs, Lead PMs, Group PMs and Product Unit Managers, all of them acting as the mom for their families.
Monday, Jan 16, 2006, 4:43 PM in The Spout
A Toast to WPF
Here's a review you don't get very often:
"Your WPF book is excellent. So good that I actually chose to read it instead of watching in flight entertainment from my trip to London in Dec... I liked it so much that I asked for some champaign, and continued to read it non-stop till I reached London from UK. Here’s a photo. Good job!"
I'm glad to here our book goes nicely with a glass of champagne, although maybe Parimal will change his mind when he sobers up or the jet lag wears off. : )
Monday, Jan 16, 2006, 10:49 AM in The Spout
PM Skill #5: Unblock Others First
PMs often come from the ranks of engineers who've been "promoted" (aka taken away from the code to go to meetings). Many fight this trend, reverting to their old close-the-door-and-solve-the-problem habits to solve problems, which, as I've mentioned, doesn't work at all well when you're managing a team.
Even worse, a PM has to do something that's very weird to most people -- they have to help other folks get their work done before they tackle their own work. I call this "unblock others first." This has implications:
- You have to be in constant communication with all the folks on your team via meetings, 1:1s, phone calls, IM, email, etc. However your teammates like to communicate, you have to be ready to receive and respond quickly. The longer you wait, they longer they're blocked and the further out your ship date goes.
- You have to learn to be interrupt driven and good at switching between tasks or you're never going to be able to swap into the tasks you're being asked to help with and then back into your own tasks. This is very counter to engineering work, where you have to be able to keep lots of ideas in your head all at once while you work on a deep technical task and interruptions are the enemy.
- You still have to balance your interrupt-driven PM time with your concentrated technical time, or you're never going to be able to stay technical enough to keep up with your team. This is the one I struggle with the most. How can I be responsive to unblock my teammates while still having uninterrupted time to myself for technical work?
This last question is the fundamental contradiction when you're a product PM and it's one that different PMs balance differently. Some swing a lot toward the technical and risk losing touch with their team and thereby building the wrong thing or missing their dates. Some swing toward the management, losing touch with the technology and losing the respect of their developers. Of the two, swinging too much toward the technology is the biggest danger, but only by a little.
I deal with this by trying to set aside at most a day here or there where I can ignore my team and concentrate on something technical, but I have a very hard time actually doing it. Frankly, I love the constant task switch that goes w/ PMing and I get bored if I go too long without it.
"Hi. My name is Chris and I'm a PM. Can I get a hug?" : )