This was the first time I attended Microsoft Academic Days and I delivered 2 presentations there. In the first I described some of the ideas behind the Microsoft Solutions Framework version 4. I focused more on "mental" aspects of MSF, technical aspects of process support by Team Foundation Server were covered by other speakers. The next day I gave a presentation about Microsoft Robotics Studio. Both presentations are in Russian. Introduction to Microsoft Robotics Studio Presentation (PPT)

MSF Revisited Presentation (PPT)

Somehow (and I would even say magically) when I open Seth's Godin blog the very first post appears to be very relevant what I'm thinking about at the moment. That day it was When you are ready to stand up to speak. And I was thinking about people who have active position and what it means to have an active position.

I came to conclusion that active position is about commitment to your goal and manifests itself by behavior biased towards the goal. This means that you do not wait for John or Peter to come and give you what you want instead you go and take it. And when you stand up to speak you do that because this will get you close to the goal and not because you just need to fill your time with something (or waste your time to be precise).

This really has much in common with the 4th Core Commitment:

Speak always and only when I believe it will improve the general results/effort ratio.

Speaking is not only about the speaker but also about the listeners. When you will be about to stand up and speak next time think if there is at least someone who is about to sit down and listen to you and how your speech will benefit them.

Nowadays (and even many years before) we often hear that this or that technology which promises to allow building fantastic user experiences came out, that new version of this or that application with dramatically improved UI came out and nearly everybody promises more features under "intuitive" user interface.

Recently I happened to witness how users interact with two uncommon types of systems: medical device to test and measure how electric impulses go through tissues and air tickets selling terminal in local tourism agency. I was literally amazed how similar these two systems were from UI standpoint.

Was their interface intuitive? No, not nearly! Medical system had so many different items on the screen with labels I could not even parse let alone understand what they mean. It even did not have a keyboard in usual sense - only about 20 or so buttons. Air tickets terminal stared at the clerk with black screen waiting for him to type in some commands. Definitely not the kind of intuitiveness you would expect from XXI century software, more smells like 1980s. But we've got much beyond that with toolbars, tooltips and context help, aren't we?

Was their interface fancy? No, not really! 80x25 text screen of tickets system and mostly B&W interface of medical system are far from modern standards for UIs with bells and whistles. I guess, younger generation of computer geeks would not even say that tickets terminal has UI - user has to type in mysterious sequences of symbols to make something happen.

Was their interface effective? Oh, yes! With both of the systems users were able to complete required operations with just a few key strokes not wasting the time on moving a mouse, going through menus and so on. If you are able to serve 20 people who want to buy tickets per hour instead of 18 that makes difference. If you are able to diagnose 7 patients per hour instead of 6 it is even more important.

Do you know what I want to say here? Think of how many minutes your software will save for its users multiply that by frequency of use and feel satisfied only when you save your users 3-digit number of minutes per month.

If you haven't read Founders at Work, you definitely should. Reading this I've enjoyed every page. Probably this book is more about "experience sharing" than any other book. This book has 33 co-authors each sharing his insight into key components of success. I just could not resist posting these words of wisdom of Steve Wozniak:

Livingston: What is the key to excellence for an engineer?

Wozniak: You have to be very diligent. You have to check every little detail. You have to be so careful that you haven't left something out. You have to think harder and deeper than you normally would. It's hard with today's large, huge programs

By the way the whole interview with Steve is publicly available. Take your time reading it.

Going out for a walk with my 3-months old daughter I took my iPod loaded with older and recent episodes of Advanced Selling Podcast. And again I enjoyed all the episodes just I did last time when I had Advanced Selling Podcast "listening session". Continuing my walk I tried to understand what are Bill Caskey and Bryan Neale saying that touches me. And I understood that we are sharing the same belief that a person in order to be truly successful in whatever position she is in has to have constructive attitude. Here "attitude" means system of values which is not only declared but also followed and "constructive" means that it is geared towards making this world better at least for somebody.

Like writing is not about writer, but about reader; selling is not about seller - it is about buyer; engineering is not about engineer - it is about user. It is possible that such kind of attitude does not give immediate dividends, but it will pay off in the long run for sure. So I would suggest checking out Advanced Selling Podcast (you can subscribe with iTunes) not only to become better at sales, but also to find out how this new way of thinking can be of service for your work.

Recently I was researching a topic of building strong and healthy teams. To me this notion consists of two main factors:

• Team performs. That is you can rely on it to get best possible result.
• People on the team are happy. That means that feeling yourself part of the team is better than the opposite.

Characteristics of a Good Team elaborate on that to give more detailed view on what comprises a good team.

Here are also some links to resources with descriptions of different team building activities and games:

• Team Building Activities, Initiative Games, & Problem Solving Exercises
• Team Building Resources
• Team Building Games
• More Team Building Activities, Initiative Games, & Problem Solving Exercises

While I believe that team has to be in certain mental state to benefit from explicit team building activity and your day-to-day attitude towards the team and fostering right values means more, abovementioned team activities may prove useful one day.

It happened so that India was the first country to really realize benefits and impact of globalization of IT. They made their name and money on the wave of outsourcing. For many years now we say "outsourcing" and think "India". Often you can see this and that outsourcing locations compared with India, like this comparing Belarus with India. Everybody wants to be better than India. While many ideas presented mentioned make sense, some do not seem to be well elaborated.

Some items in comparison are not actually about advantages but about risk. And, you know, risks do not always materialize. For instance, time-zone difference allowing large working time overlap with US is an advantage of Belarus. But this does not necessarily mean than working with Belarus you will not have any communication problems or will have them less than with Indian vendor. Time-zone difference is not that important given that your outsourcing partner delivers value. And as I said before although some outsourcing locations are better than others the most important thing still is choice of partner and his ability to be a valuable contributor to your success.

Again, you outsource to certain company not to country. Make sure you partner can realize advantages of his geographical location and can properly manage risks associated with that.

Alex Polonski in Outsourcing Quiz: Cheap Vs. Good considers the "cost" aspect of outsourcing. He asks:

Why should I pay $1000 for this bit of software if I can find somebody that will develop the same for as much as $200?

While the logic of this questions is pretty legitimate, there is another side. Each product (or service) costs as much as customer is willing to pay. And that price of selling is not necessarily connected to cost of production. Price at which you can sell your product is determined by value it gives to customer. Water in a desert is worth much more than the same water near mountain spring.

If for your product it is not that important how much you pay for engineering, then probably you should not be doing that product as it fails to deliver value to its users. Isn't it?

If you were looking for good high-level info on .NET 3.0 check out following whitepapers from Microsoft:

• Introducing .NET Framework 3.0
• Introducing Microsoft Windows Workflow Foundation
• Introducing Indigo (aka Windows Communication Foundation)
• Introducing Windows Presentation Foundation
• Introducing Windows CardSpace

These whitepapers give important information for connecting business and technology with respect to .NET 3.0.

Today I was listening to an older episode of Advanced Selling Podcast which was Income Inequality--How You Can Be At The Top End of the Income Scale. One of the most important messages of this episode was the idea that in order to be successful (i.e. get more income) you need to acquire some important knowledge and skills.

Although Bill Caskey and Bryan Neale produced this list of most important skills to develop with sales person in mind, I believe that it is quite applicable to software engineering as well:

• Communication skills. Verbal and writing. No-brainer. You must be a good communicator to be successful in any area, period. Most of software projects are done in teams and teams always depend on communication to perform efficiently.
• Problem finding and solving. As an engineer you deal with problems solving every day, but what distinguishes great engineers is an ability to look deeper and spot problems. Not sure if you can learn this anywhere.
• Sales and marketing. This one is a bit tricky. Many engineers believe that they are never going to need this. But they are involved in selling more often than they might think. They sell ideas and designs to their colleagues, designs and recommendations to their managers and so on. And again success depends on how well they do that.
• Financial side of business. Unless you are a novice junior developer (and even sometimes if you are) you make decisions that influence your project and you need to understand possible financial underpinnings of those decisions. This is especially applicable to development leads and managers.
• Planning. You build plans to make sure you have an idea how to make something happen. This again is applicable to any area you may work in.

If you are looking new inputs for self-development be sure to check out Advanced Selling Podcast.