# Saturday, April 18, 2009

I love reading Rands. He has such practical day to day advice for managing projects and people, and then he has some truly inspirational topics. You think you have a tough project? You think you have to invent half the technology you're using on the fly? Working with new unproven tools? Try building the Brooklyn Bridge. I guess it's the engineer in me (chemical, not civil) but I  see bridge building as one of our most persistently amazing technologies. It also makes an amazing metaphor. I hope something I design, build, or project-manage lasts 120+ years, but I rather doubt any of it will.

And while I'm quoting Rands, you just have to read about The Pond. I have had a lot of variation, over the decades, in the amount of time I spend with my staff and the amount of time they spend with each other. I wish his pessimism about the fate of those who work remote all the time was misplaced - but unfortunately, I think he's right. If you work remote all the time, you need to think about how to be in the pond.

Both highly recommended.


Saturday, April 18, 2009 7:25:25 PM (Eastern Daylight Time, UTC-04:00)  #    
# Thursday, April 16, 2009

Well, a lot. Brian Harry has provided a feature list, and a secret decoder ring to help you decide which blogs to read to learn more over the coming months. My personal favourite? "Work item hierarchy & linking". If that means what it sounds like it means I will have a much simpler life when planning a project the way I often do - starting with big things and later breaking them down into small ones. I'll be watching for more details on that.


Thursday, April 16, 2009 7:17:32 PM (Eastern Daylight Time, UTC-04:00)  #    
# Tuesday, April 14, 2009

Do you have a Windows application? Are you curious if it will run well on Windows 7? Would you like to try something a little more technical than "install on Windows 7 and see if it runs?" Then you need the Application Compatibility Toolkit. The latest version, 5.5, is now available. There is documentation for it on TechNet to help you get started.



Tuesday, April 14, 2009 6:28:45 PM (Eastern Daylight Time, UTC-04:00)  #    
# Sunday, April 12, 2009

People believe a lot of strange things in this world. They worry specifically that SharePoint won't perform as well as they need, and that they can write some sort of ASP.NET app with a SQL backend that will somehow outperform it. I really liked this post from Eric Shupps that lists a few of them. Keep in mind these are all myths - that is "not true".

  • SharePoint Lists Have an Upper Limit of Two Thousand Items
  • SharePoint Is Just Too Slow for Common Tasks
  • SharePoint Is Not Suitable For Large Public-Facing Web Sites
  • SharePoint Isn’t A Scalable Enterprise Document Management System
  • SharePoint Pages Take Too Long to Render Over the WAN

Eric goes into quite a bit of detail debunking each of these 5 myths, so if you have a tendency to believe these things, here's a chance to get straightened out on that.


Sunday, April 12, 2009 6:23:57 PM (Eastern Daylight Time, UTC-04:00)  #    
# Friday, April 10, 2009

I think one of the things that really sets good presenters apart from poor ones is what they do when something goes wrong. A poor presenter:

  • needs all their cycles to try to figure out what went wrong, and has none left for looking after their audience
  • is focused on making the demo work and sticking to the original plan
  • is rattled by the experience so that whether the demo works in the end or is abandoned, the rest of the talk is lower quality

A good presenter:

  • has rehearsed the demos many times, so that most "boom!" moments have been seen before and can be fixed quickly
  • doesn't need as much energy to look after the audience, so is more likely to be able to do it
  • is focused on making the talk work
  • has backup (screenshot of the result, an exe that was built earlier) so that something can be rescued
  • can get through the failure quickly and get back to the flow so that the talk as a whole can go well

I linked a while ago to a picture of Steve Teixeira dealing with a blue screen. Now Brad Abrams has highlighted Bill Buxton (who I quoted a few posts ago) dealing (at Mix) with hardware that refused to co-operate. I aspire to do as good a job dealing with demo failure. Brad includes some other "demo failures at Mix" in his post, too. 

A tip that has served me well over the years: have a stock of optimistic "I am not an idiot" sentences to use while you're either giving up on the demo or doing what you need to do to make it work. "Hey, if it was perfect, we'd be shipping it" is good. So is "told you it would be a short demo". Humour keeps the audience with you, and stock lines don't take up much of your brain, so you can be furiously thinking with most of your brain about how to solve your problem (either how to fix the demo, or what to do with the rest of your talk now that you have ten more minutes to fill.)


Friday, April 10, 2009 9:17:49 AM (Eastern Daylight Time, UTC-04:00)  #    
# Wednesday, April 08, 2009

Steve Clayton highlights a neat video that you should probably watch. It's a little corny, but you can't make the world a better place if you're always looking over your shoulder wondering if you're being corny. It's less than two minutes - you can spare that, right?


Wednesday, April 08, 2009 8:58:37 AM (Eastern Daylight Time, UTC-04:00)  #    
# Monday, April 06, 2009

If you do any SharePoint work, you need SharePoint Designer. If you're a developer, you probably got it through an MSDN subscription. But is there someone in your company who doesn't use Visual Studio and other developer tools, just some designer-oriented ones? Now that person can have a copy of SharePoint Designer - it's become a free product. Why? There's a video interview that explains the team's thinking on SharePoint as a platform, and making it simpler to build around it.

Download it here, and enjoy!


Monday, April 06, 2009 8:53:08 AM (Eastern Daylight Time, UTC-04:00)  #    
# Saturday, April 04, 2009

I spend a lot of time at a keyboard and screen. Most of the time, I'm working. I might be writing code or a document, reading something to better myself, reading something because it's my job to review it, watching a video or screencast, triaging bugs in TFS, or of course processing email. Some of these tasks involve a lot of typing, others mainly mousing, and some involve sitting almost completely still with the occasional page-down or mouse click. Other times, I'm having conversations with family or friends, reading something for fun, or playing a game. These tasks also have the same spectrum of frantic-typing and clicking through to mostly passive consumption with the occasional click or keypress. And at still third times I'm doing what we might call family administrative tasks - seeing when the grocery store in a nearby town closes, checking the school web site for holiday dates, ordering something, renewing something, banking or billpaying - or business administrative tasks - including invoicing my clients. You can't tell, by looking at the back of my screen or listening to my typing and mousing, what I'm doing. You can't tell by where I'm sitting either ... I might be using Remote Desktop to access the computer where our book-keeping software is installed, or a server that needs to be configured, or a client machine so that I can reproduce a production problem.

So what? Well it isn't how work has usually been. Hundreds of years ago, if someone was working you could tell by looking at them. They had a hammer in their hand, or a paintbrush, or some other tool. Even a few decades ago, if someone worked at a desk by writing on paper it was easy to see what desk they were at, what papers were strewn around them. Reading the paper looked very different from checking the invoices. And of course, leisure never involved the same tools or locations as work. Now, not so much. Bill Buxton has an interesting article on just this topic. He's at Microsoft Research, and it pleases me to think that folks there are thinking about this. I look forward to a future time when people can get a better idea of what I'm doing and how interruptable I am, not just "you're always on your computer."




Saturday, April 04, 2009 8:45:51 AM (Eastern Standard Time, UTC-05:00)  #