# Monday, May 25, 2009

Episode 26

Microsoft MVP Chris Woodruff is one half of the team of "Keith and Woody" that host the popular Deep Fried Bytes podcast. In this interview, Chris talks about why they started this podcast and what makes it different.

17 mins, 58 secs

Monday, May 25, 2009 6:22:19 PM (GMT Daylight Time, UTC+01:00)
# Wednesday, May 20, 2009

Episode 25

Mike Hacker is the Practice Director for the Sogeti Michigan Microsoft Practice, which makes him my boss.

In this interview, Mike describes issues around single sign-on.

21 mins, 21 secs

Wednesday, May 20, 2009 12:42:16 PM (GMT Daylight Time, UTC+01:00)
# Tuesday, May 19, 2009


I am scheduled to speak at the following upcoming events

CodeStock 2009

The CodeStock conference will be held in Knoxville, TN on June 27.  I will be presentingon Microsoft Managed Extensibility Framework (MEF).  You can find information on this event and register at http://codestock.org/

West Michigan .Net User Group

I will speak again on MEF at the July 14 meeting of the West Michigan .Net User Group in Grand Rapids.  You can find more information at http://www.wmdotnet.org/


I'll quietly spend all of Wednesday May 20 at the Microsoft office in Southfield so that I can attend a series of events throughout the day.  The details are below:

Time: 9:00-11:45AM
Trends and patterns on the client tier
Applying Microsoft technology on the client tier
Register: http://msevents.microsoft.com/CUI/EventDetail.aspx?culture=en-US&EventID=1032408649
MSDN Unleashed
Time: 1:00-3:00PM
Internet Explorer 8 for Developers
Developing on Microsoft Windows 7
Register: http://msevents.microsoft.com/CUI/EventDetail.aspx?culture=en-US&EventID=1032409548
Technet Unleashed
Time: 3:10-5:00PM
Windows Server 2008 R2 – Optimize Your Time
Windows 7 – Maximize Your Potential
Register: http://msevents.microsoft.com/CUI/EventDetail.aspx?culture=en-US&EventID=1032410548

Southeast Michigan .Net User Group
Time: 3:10-5:00PM
Topic: RIA
More information:


Tuesday, May 19, 2009 6:13:25 PM (GMT Daylight Time, UTC+01:00)
# Monday, May 18, 2009

Episode 24

Mike Wood recently traveled through Michigan giving a presentaion on Parallel LINQ (aka "PLINQ"), which is part of the Task Parallel Library included in .Net 4.0.

During this tour, Mike sat down with me to describe how to use PLINQ how it can improve the performance of your LINQ queries.

11 mins, 56 secs

Monday, May 18, 2009 5:04:54 AM (GMT Daylight Time, UTC+01:00)
# Sunday, May 17, 2009

In this article, I will talk about topics that you should avoid discussing in the workplace.  While it is impossible to ensure that you offend no one, common sense and a little self-control can guide you to avoid saying things that can damage your career.

Generally the highest-risk topics are those that are the most controversial – those that others may find offensive – and that are unrelated to the professional work you are doing.  If you plan to take a controversial stand, it is better to take such a stand on something directly related to your job, because the payoff is much greater. 

This article is not intended to dictate (or even express) a particular moral stand - That may be a subject for another article. Avoiding topics offensive to others is generally in your own best interest because offensive topics can damage your reputation and career.

Even those whose job description includes shocking people, such as comedian Michael Richardson and loudmouth radio host Don Imus, have damaged their careers by making remarks that were viewed as inappropriate by many of their listeners.

When young people first join the workforce, they must deal with many challenges and changes. Among the changes with which young people must deal: a new way to communicate in a professional work environment.  Among college friends, communication is often very relaxed. When chatting with your buddy, you generally don’t need to watch what you say.  But in a professional workplace, miscommunication can be dangerous.  A careless remark can form a bad impression, earn you a reprimand, lose your job or even initiate legal action.

Talking about your personal life at work is fine and can help to build relationships with co-workers.  Family, hobbies, and weekend activities are part of our lives and talking about them help to connect with people.  But be wary of bringing excessive private details of your life to work. 

Three famous personal topics you should avoid at the office are sex, politics and religion.  The reason to avoid these topics is that many people have such strong beliefs on them that they refuse to consider alternative opinions.  They internalize their beliefs on sex, religion and politics to the extent that they perceive an attack on their opinions as an attack on themselves. As a result, conversations often turn into debates, which turn into arguments, which turn into animosity.  It is fine to disagree on any of these topics (people do so all the time), but this discussion should take place after hours, where it is less likely to damage a working relationship.

Off-color jokes definitely fall into the forbidden category and should be avoided at work.  You may think it harmless to tell a racist or sexist joke when surrounded only by white males, but many of us find these things offensive.  A reputation as a narrow-minded bigot is not likely to advance your career. You should avoid any topic that smells of racism, sexism or any type of discrimination.  This can sometimes be difficult.  I’ve worked with managers who would occasionally say something sexist or racist.  This does not’t make it right or acceptable.  The best course is to err on the side of caution and avoid these topics.

Negativity is something else to avoid.  Every office experiences negative events and sometimes those events are caused by management.  The problem is that sometimes talk of these negative events overshadow the positive contributions made by management and others.  An employee with a negative attitude is far less likely to be productive and far less desirable to work with.  Even worse, negativity is contagious – It can spread quickly to others in the office, dragging down morale and destroying productivity among the entire office.  We don’t all need to be cheerleaders for management, but we do need to keep events in perspective and not allow negativity to damage a good working environment. 

Another conversation area I recommend avoiding is gossip.  At some time, nearly all offices fall victim to the spread of gossip.  It is common for people to talk about the personal lives and shortcomings of others.  But unchecked gossip is a poison.  It can damage the reputation of the target of the gossip. But it can also damage the reputation of those spreading the gossip.  Even if you did not start the rumor, you may be perceived as a problem if you help to perpetuate that rumor.  It’s best to remove yourself from these conversations.  If gossip concerns someone’s work, you may need to address it by finding out the truth.  Talking about someone behind their back almost never does any good.

At some point in your career, you are likely to find yourself working with someone who violates the above guidelines and you will need to be prepared to handle these situations.  As stated above, the point of this article is *not* to pass judgment on people for their thoughts and words or to make any morality judgments whatsoever.  My point is that speaking in an insensitive way can be harmful to your career.  If you are a redneck, narrow-minded racist and you like to tell jokes about minorities and sex (did I say that out loud?), I’m not here to tell you that you are wrong (at least not in this forum).  But I am here to tell you that this is an attitude that can get you in a lot of trouble at work.  In most organizations, it is to your own benefit to avoid inappropriate conversations.  In fact, you can harm your career just by participating in or listening to these conversations.  If you allow yourself to continue as part of an inappropriate conversation, others may perceive that you approve of a speaker’s views, whether or not you explicitly say so.

If you find yourself in an inappropriate conversation, my advice is to confront the speaker directly.  Most people will stop immediately when you tell them that you find what they say offensive.  This may be because they are embarrassed or they may wish to avoid confrontation, but my experience is that few people will try to publicly defend offensive behavior. In the long run, it’s usually more effective to confront an offender prior to escalating a situation by bringing it to the attention of management.

I recognize that some of you reading this are not comfortable with direct confrontation. It can take a lot of courage to do this.  But for your own benefit, I recommend that – at a minimum – you remove yourself from these situations so that no one assumes you are a part of or tacitly agreeing with these thoughts.

In this article, I listed some guidelines of topics to avoid in workplace communication.  There are no simple, dogmatic rules about topics that are appropriate for work, but the guidelines above should help you determine your own rules of what you will discuss and what topics will harm your career.

Sunday, May 17, 2009 4:59:18 PM (GMT Daylight Time, UTC+01:00)
# Friday, May 15, 2009

Episode 23

Michael Letterle is a developer for Preemptive Solutions, a company that makes the .Net obfuscation product Dotfuscator.  I was familiar with Dotfuscator, but I was unaware of most of their other products.  In this interview, Michael describes the different software created by Preemptive.

8 mins

Friday, May 15, 2009 12:54:39 PM (GMT Daylight Time, UTC+01:00)

Today I gave a presentation (again) on the Microsoft Managed Extensibility framework.  Below are the slides and demos used for this presentation.

ProjetListDemo A simple demo showing the syntax for MEF imports and exports 

DemoAccounting shows how to dynamically add modules to an application at runtime, without recompiling.

Friday, May 15, 2009 3:26:06 AM (GMT Daylight Time, UTC+01:00)
# Wednesday, May 13, 2009

Episode 22

For the past six years, Jamie Wright has been building applications using Rocky Lhotka's CSLA framework.  In this interview, Jamie explains the framework and why he is such a fan.

10 mins, 23 secs

Wednesday, May 13, 2009 1:02:51 PM (GMT Daylight Time, UTC+01:00)
# Monday, May 11, 2009

Episode 21

Microsoft Developer Evangelist Jeff Blankenburg coordinated the Stir Trek conference in Columbus, OH to present highlights of the recent Mix09 conference.   In the middle of the day, he took a few minutes to discuss what he was doing.

5 mins, 4 secs

Monday, May 11, 2009 10:57:10 AM (GMT Daylight Time, UTC+01:00)
# Sunday, May 10, 2009


Juan is a software developer working for a consulting company.  He is smart, conscientious and hard-working. One day, Juan showed up at his customer, was given a task and set off to his cubicle to complete it.  After working diligently for a week, Juan completed the task, checked in his code and asked for a new task.  A few days later, a tester opened a defect against Juan's task.  It turns out that Juan had misunderstood the assignment.  He had coded to the task as he understood it rather than as the task writer understood it.  Juan received clarification, completed everything correctly in a few days, and resumed his work.  No big deal, thought Juan.  In fact, the actual assignment was simpler than he had originally anticipated so he implemented it correctly in less than a week.

Over the next 6 months, Juan did a lot of very good work for the customer.  Any minor mistakes he made were very small compared to all he accomplished.

When Juan rolled off the project, he received an evaluation from his manager.  To his surprise, she asserted that Juan had trouble following directions.  She had never told Juan this was a problem, but the evaluation listed several minor incidents to support this point. After working hard and receiving only positive feedback for six months, Juan expected a better evaluation. 


Ammal is a software developer working for a consulting company.  He is smart, conscientious and hard-working. One day, Ammal showed up at his customer and was given a task.  Before beginning this task, he verified that he understood it by articulating his understanding to the person who wrote the task.  Before writing a line of code, he was able to reconcile all discrepancies between his assignment and his understanding of said assignment.    He then set off to his cubicle to complete the task.  After a couple days of writing code, he had a better understanding of the system and the environment in which he worked, so he was able to identify some ambiguities in the task description.  He formed assumptions around these ambiguities, but he immediately sought a decision-maker to validate his assumptions.

When Ammal began coding, he understood his task and was able to complete it the first time.

After about a week, he checked in his code and asked for a new task.  A tester tested and passed his checked-in code.

Over the next 6 months, Juan did a lot of very good work for the customer.  Any minor mistakes he made were very small compared to all he accomplished.

When Ammal rolled off the project, he received an evaluation from his manager.  His manager raved about Ammal’s performance.  She specifically called out some of his accomplishments and made no mention of any minor issues.

What went wrong for Juan?

Ammal and Juan performed almost identically, yet their evaluations were considerably different. So where did Juan go wrong? 

In this example, a few things worked against Juan.

A bad early impression marred the manager’s opinion of Juan.  The manager didn't stop to ask why the miscommunication took place (Generally, both parties are to blame for a miscommunication).  She only noticed that Juan spent over two weeks on a task that should have taken one.  Once this opinion formed, it was difficult to change and everything the manager saw afterward was colored by her early perception.

Get feedback early and often

Ammal avoided this early bad impression by initiating communication early.  By being proactive, Ammal not only avoided the initial rework, he also established a communication channel, making it easier to get feedback sooner. 

This frequent feedback loop that Ammal encouraged helped him to correct misunderstandings before they cost him time and effort. 

Frequent feedback loops are a very popular strategy in software development.  Many agile methodologies suggest scheduling software delivery in sprints of 1-2 weeks in order to increase the frequency at which developers will receive feedback from business users.

But this increased feedback cycle can also pay dividends outside of software delivery.  On the projects I work, I strive to get feedback from my manager or managers as early and as often as possible.

Within days of starting on any project, I always try to schedule a one-on-one appointment with my new manager.  We met alone for anywhere from 15-60 minutes to discuss the manager’s expectations of my role.  I may have already received information about my role but I want to get that information from the person who is going to evaluate me.

I may have been hired to write code, but does the manager expect more from me?  Am I expected to mentor junior developers on the team?  Would it be helpful to write documentation on the features I implement?  Is unit testing important in this environment? Should I look for ways to improve the process in the department?   Are there particular areas of the application in which they needed more help?  I want to find out the kind of things that they value so that I can focus my energies there. 

I use this initial meeting to describe my experience, strengths and interests and to suggest ways that I might add value.  I always emphasize that I am here to add as much value as I can, but that I am looking to the manager to tell me where I can most effectively do that.

I take many notes during this meeting and use them to guide my activities for the rest of the project.

Different managers have different ideas about how their employees should work.   Some believe in controlling everything themselves and some believe in empowering users.  Usually a manager’s style becomes obvious during this early meeting.

The initial meeting helps to establish goals; but this is not sufficient.  We need to act on those goals – keep them nearby; tape them to your monitor or tack them above your desk. 

Send frequent updates to your manager and let him know what you are working on and how that relates to the goals the two of you set together. 

Send him a weekly status report.  Don’t ask if he wants or needs a status report – just send him one.  Every week.  No exceptions.  Even if you are on vacation, send him a status report, letting him know what is pending.

If possible, encourage your team (and your manager) to hold a daily standup meeting.  This meeting should be less than 15 minutes long (Forcing everyone to stand up discourages long meetings) In a standup meeting, each team member gives a quick status of what he did yesterday, what he intends to do today, and any impediments standing in his way.

These status reports and status meetings help you to stay on track; they help you to communicate your agenda and goals to your manager; they allow your manager a chance to give you frequent feedback; and they give you a chance to brag about your recent accomplishments, so they are fresh in the mind of the manager.

The punch line

On his next project, Juan adopted the strategy of getting feedback early and often from his manager and others.  As a result, his work quality improved a little but the perception of his work quality improved substantially.  This time around, Juan’s performance review was as good as Ammal’s.  Which is where we get the old expression: “If you’ve seen Juan, you’ve seen Ammal.”

Sunday, May 10, 2009 11:54:26 PM (GMT Daylight Time, UTC+01:00)