An Annual Review may be a key point in your career path. Depending on the company for which you work, this may be the only official feedback you receive during the year. Raises and promotions are often dependent on your annual review scores. Some companies emphasize an annual review more than others, but it's a good idea to devote some energy to them as an employee.

The first important thing to know about your annual review is that you should start thinking about it very early in the year - preferably right after your last annual review. Set explicit, measurable goals for yourself over the coming year. Once your goals are established, formulate a plan to achieve those goals. Be as specific as possible. Include skills you want to learn, certifications you want to earn, and roles you want to fill. Review these goals periodically over the following months. Revise them, if necessary and record what you are doing to accomplish them.

Keep your manager or managers aware of what you are doing throughout the year. If you are speaking at a conference, let them know. If you receive an e-mail from a customer, praising your work, forward it to your boss. He should know what you are doing and how you are doing and this tends to create a favourable impression that can only help at review time.

Record all your accomplishments. I keep a spreadsheet with a tab for Projects I've worked on, Candidate I’ve interviewed, Presentations I've given, and other categories of contributions I've made to the company. For you, this record might be a Word document or a text file or a spiral notebook. The point is that you should not rely on anyone else to remember what you did throughout the year. It's tempting to believe that your manager will remember these things, but I can tell you from experience that managers have a lot to keep track of and they will often forget what you accomplished a few months ago. Add to that the non-zero chance that your manager may leave the company or get transferred to another role and you can see why it's important that you take responsibility for remembering all that you  did during the year.

When it comes time for your review, review your accomplishments and compare them to your goals set at the beginning of the year. Give yourself an honest evaluation of your performance during the past 12 months. This accomplishes two things:

1. It will prepare you for what your Annual Review will likely be.
2. It will help you to articulate to your manager how well you did during the past year.

It's important to remind your manager of your accomplishments at this time. As mentioned before, there is a good chance he has forgotten some of them and providing positive data points only makes his job easier.

Finally, almost every annual review process includes some qualitative feedback. Listen carefully to this feedback, even if some of it is negative. Don’t be discouraged if you don’t get the promotion you wanted or if you were evaluated lower than you  expected. But make sure you understand why. Insist on an explanation if you don’t understand a score in a particular area. Look at the negative points as areas that you can improve next year. Use these points to help define your goals for the coming year.

A well-done annual review is an important part of an organization and of an individual's career path. If done correctly, the employee has at least as much involvement in a review as his manager does.

Many companies institute a formal review process each year. It is a lot of work, but it's an important part of developing employees. An Annual Review provides critical feedback to employees. In addition, it provides objective criteria on which to base raises and promotions.

This week, I am responsible for completing an Annual Review for three Sogeti employees. At Sogeti, we call my role "Counselor" and these three employees are known as my "counselees". Of course, I also have a counselor, which makes me a counselee to him.

My task this week is made more difficult by the fact that I don't work regularly with any of my counselees.

But here is what I do to complete this process as fairly and effectively as I can.

Start Early

The annual review process starts at the beginning of the year. Push your counselee to articulate what their goals are for the year. Some of these goals will come from within themselves and some will be a result of feedback during the last annual review process. Goals can change and that’s okay, but it’s tough to achieve anything unless you have some objectives in mind.

Talk to your counselees regularly throughout the year. I schedule a monthly conversation with each of my counselees. It’s on our calendars, so we won’t miss it. Usually, this is a phone call, but I try to meet them for lunch at least a couple times a year. Find out how their project is going. What challenges are they having? What are they doing well? Is there anything they need from you or elsewhere in the company? Have their goals changed since the beginning of the year? If they received a flattering e-mail, ask them to forward it to you.  Give them direct feedback during these meetings. If you cannot answer a question, follow up later with someone who knows the answer. Take notes during these meetings. OneNote is a great tool for this. Often, I end up copying text directly from these notes and pasting it into the Annual Review form at the end of the year. If you are meeting regularly and having open conversations, there should be no surprises at Review time.

Encourage your counselees to keep a record of their accomplishments throughout the year, so that they can more easily articulate them at the end of the year. I always tell my counselees not to rely on me to remember anything they did during the year. There is a good chance I will forget something and there is a non-zero chance that I might not be with the company at the end of the year. At one of my former company's we had a slogan: "You own your career". Employees should understand this and it’s a counselors job to make sure they do.

End-of-Year

If your company publishes guidelines for the annual review, read them thoroughly and base your review on these guidelines. The less subjective your review, the easier it will be and the more fair to all involved.

Seek input from those who know the best. Because I typically do not work with the people I evaluate, I actively seek input from those who are more familiar with a counselee's work. Send e-mails and make calls to get as much input as you can. Typically, I might reach out to

• Customers
• Managers
• Co-workers
• Salespeople

Include specific examples in your evaluation. "Bob did a great job at customer XYZ" is far less meaningful than "Bob rewrote the Shipping screen, so that it now runs 70% faster, saving the customer 2-4 hours per week." On the flip side "Joe needs to improve his communication skills" is less effective than "The customer expressed frustration because he did not know that Joe's project was behind schedule until he failed to meet his deadline. Joe should have communicated the schedule slippage weeks earlier when he became aware of the roadblock."

Be honest. Often, you will find yourself evaluating a friend and it's tempting to let personal feelings sway your evaluation. Friendship should only affect an evaluation if there is a criterion for getting along with others. In all other areas, stay objective. Otherwise, you are not being fair to the other employees. Honest feedback is how an employee improves.

Give an annual review process the time and attention it deserves. Employees deserve this.

Many companies institute a formal review process each year. It is a lot of work, but it's an important part of developing employees. An Annual Review provides critical feedback to employees. In addition, it provides objective criteria on which to base raises and promotions.

This week, I am responsible for completing an Annual Review for three Sogeti employees. At Sogeti, we call my role "Counselor" and these three employees are known as my "counselees". Of course, I also have a counselor, which makes me a counselee to him.

My task this week is made more difficult by the fact that I don't work regularly with any of my counselees.

But here is what I do to complete this process as fairly and effectively as I can.

Start Early

The annual review process starts at the beginning of the year. Push your counselee to articulate what their goals are for the year. Some of these goals will come from within themselves and some will be a result of feedback during the last annual review process. Goals can change and that’s okay, but it’s tough to achieve anything unless you have some objectives in mind.

Talk to your counselees regularly throughout the year. I schedule a monthly conversation with each of my counselees. It’s on our calendars, so we won’t miss it. Usually, this is a phone call, but I try to meet them for lunch at least a couple times a year. Find out how their project is going. What challenges are they having? What are they doing well? Is there anything they need from you or elsewhere in the company? Have their goals changed since the beginning of the year? If they received a flattering e-mail, ask them to forward it to you.  Give them direct feedback during these meetings. If you cannot answer a question, follow up later with someone who knows the answer. Take notes during these meetings. OneNote is a great tool for this. Often, I end up copying text directly from these notes and pasting it into the Annual Review form at the end of the year. If you are meeting regularly and having open conversations, there should be no surprises at Review time.

Encourage your counselees to keep a record of their accomplishments throughout the year, so that they can more easily articulate them at the end of the year. I always tell my counselees not to rely on me to remember anything they did during the year. There is a good chance I will forget something and there is a non-zero chance that I might not be with the company at the end of the year. At one of my former company's we had a slogan: "You own your career". Employees should understand this and it’s a counselors job to make sure they do.

End-of-Year

If your company publishes guidelines for the annual review, read them thoroughly and base your review on these guidelines. The less subjective your review, the easier it will be and the more fair to all involved.

Seek input from those who know the best. Because I typically do not work with the people I evaluate, I actively seek input from those who are more familiar with a counselee's work. Send e-mails and make calls to get as much input as you can. Typically, I might reach out to

• Customers
• Managers
• Co-workers
• Salespeople

Include specific examples in your evaluation. "Bob did a great job at customer XYZ" is far less meaningful than "Bob rewrote the Shipping screen, so that it now runs 70% faster, saving the customer 2-4 hours per week." On the flip side "Joe needs to improve his communication skills" is less effective than "The customer expressed frustration because he did not know that Joe's project was behind schedule until he failed to meet his deadline. Joe should have communicated the schedule slippage weeks earlier when he became aware of the roadblock."

Be honest. Often, you will find yourself evaluating a friend and it's tempting to let personal feelings sway your evaluation. Friendship should only affect an evaluation if there is a criterion for getting along with others. In all other areas, stay objective. Otherwise, you are not being fair to the other employees. Honest feedback is how an employee improves.

Give an annual review process the time and attention it deserves. Employees deserve this.

You are swamped. Four weeks to finish this project will barely be enough time. You're working late every night and still don't seem to be making headway. The boss comes over and asks if you have time to do this simple task. What is your response?

There are only two possible responses, right? Yes or No.

Either you tell the boss 'No', you cannot accommodate his request because of the amount of work you have; or you tell him 'Yes' and commit to not seeing your family until after the holidays.

But are those the only two responses?

Consider telling him "Yes, but".

"I'm happy to do this boss, but it will cause the schedule to slip on the other tasks I've been assigned. Is that OK? Can you help me to prioritize so I know which tasks to drop or defer?" Often the boss had no idea his "small" request would have such an effect.

If someone other than the boss comes by, a similar response works.

"I'm happy to do this, but it will impact the delivery schedule of the other items I'm working on. Let me verify that the boss is ok with letting the schedule slip."

In both these cases, the response is close to saying “no”, but the delivery puts the decision back into the hands of the one making the request. It also politely calls attention to the fact that your time is not unlimited – a fact that is easy for others to forget.

There is no guarantee this will be effective (tyrannical bosses do exist), but generally people are reasonable and, if they make unreasonable requests, they don’t realize they are doing it. Sometimes, it’s up to us to provide that perspective.

You can maintain a positive attitude without killing yourself by being honest with those around you.

Episode 234

Ted Neward on PMs and Developers

The Horror, the Horror…

I have been delivering technical presentations for a long time and have experienced many highs and lows. Here are a few of the more difficult challenges I’ve faced while presenting.

Expert in the Audience (Cincinnati, OH, 2000)

I used to do a lot of classroom training and my habit on the first day was to go around the room and ask each student to describe his or her experiences and goals. I once taught an XML class that included a module on a new product called “BizTalk”. I knew almost nothing about BizTalk but it was so new that I assumed no one else would realize the extent of my ignorance.

Imagine my surprise when, during Day 1 introductions, I learned that one of my students was a senior Microsoft consultant, who was currently implementing BizTalk Server for his client.

Thinking quickly, I asked this consultant to deliver the final module to the class. We all learned something from him and I was spared any shame or embarrassment.

No Laptop (Southfield, MI, 2008)

I was asked by a Microsoft Architect Evangelist to deliver a presentation at a Microsoft event. The slides and demos were provided for me, but I did not have access to a laptop, so I asked the evangelist to find me one. Unfortunately, he never did, so I ended up borrowing a laptop from a friend at the last minute. This laptop had two major problems:

1. It was woefully underpowered, so all the demos ran very slowly
2. Someone had installed an unlicensed copy of Windows on the laptop, so an “Illegal Software” warning repeatedly appeared during my presentation.

No one commented on the warnings that popped up, but the audience grew restless with the time it took each demo to run.

Dead Video (Toled0, OH, 2008)

I arrived at a user group in Toledo to discover that no image would display on my screen. User group leader Jason Follas came to my rescue. Using a crossover cable, Jason connected his computer with mine, which allowed me to remote into my laptop and present from his, averting a crisis. Sometimes one has to think outside the box.

Lost in Genesee County (Flint, 2009)

The Flint, MI .NET User Group met at a New Horizons training center. I had the address and a map, but I drove around the area for at least a half hour looking for the building. I had to stop at each building in several adjacent office parks and walk inside to see if it was the correct one. I finally found the group inside a building hidden behind an unlit parking lot. I only discovered this was the correct location because someone happened to be walking out as I was walking in.

I was 45 minutes late and completely rattled and this as one of the worst presentations I ever delivered.

Overcommitted (Southfield, Lansing, 2009)

I try to avoid overcommitting, but it sometimes happens. One memorable time occurred when I was scheduled to deliver a talk at Lansing Day of .NET; and was subsequently asked to fill in the day before for an event in Southfield. Another presenter was called away by a family crisis, so I had little time to prepare for my 4-hour presentation and I had to create nearly all the materials myself.

I was unable to start preparing for the Lansing presentation until the night before, so I ended up staying up most of the night.

Dead Laptop (Lansing, 2009)

My laptop completely died the morning of the 2009 Lansing Day of .NET. I had to borrow one from Michael Eaton. Unfortunately, I did not have a backup of my presentation (I now use DropBox, so I always have a backup), so I had to recreate it. To make matters worse, I was unable to install the necessary software on his laptop, so I had to forego my demos and only display slides.

The Bomb Threat (Lexington, KY, 2010)

It was a crazy idea to drive down to Lexington, KY and back in a single day; but I wanted to be the first speaker at this new user group. The meeting was scheduled in the basement of a public library. After a five-hour drive, I called my host, who informed me that a bomb threat had been called into the library and the police had evacuated the building and the user group attendees were standing on the corner outside the library. The projector and the pizza remained inside. The building did not reopen until the following day and I ended up delivering the presentation (sans projector and demos) at a local restaurant.

So, What’s the Point?

I share these stories for several reasons

1. Preparation is the key to success. The more familiar you are with your material and your demos and your hardware and the location of the event, the less likely things will go wrong. You will also be more aware of what can go wrong and ready to deal with it.
2. It's possible to recover from a mistake. It doesn’t matter if it is your fault or something beyond your control – things will sometimes go wrong. Deal with it and move on with your demo. Don't assume that everything will go well. Have a backup of the completed project or a video or slides showing code. You can still teach concepts even if your demo fails.
3. Know that it's OK to screw up. If you are enthusiastic and knowledgeable about your topic, your audience will be surprisingly forgiving. Don’t dwell on your mistakes: Learn from them.

Episode 230

Alan Stevens on REAL Development

Episode 225

Brent Stineman on Learning

Training is an important part of employee development and most managers recognize this. At the same time, most managers have a budget to which they need to adhere.

Next time you request training, do yourself, your manager, and your company a favor by articulating the reasons for this training. To reduce misunderstanding and ambiguity, state your case in writing. Be explicit about what you are requesting. This may include time away from work, training fees, and travel expenses.

Your statement should answer as many of the following questions as you  can:

• How will this training benefit your ability to complete your current project or an upcoming project? How will this training benefit the company or department?
• How does this training align with your career goals?
• How much will the training cost? How much time will you need to miss from my regular assignments? Do you plan to make up this time? Do you plan to take vacation for the missed time?
• If the training is out of town, is similar training available locally? If so, why is the out-of-town training preferable.
• If your company provides "free" training resources, what does this training provide that is not available in those resources?

Generally, managers are supportive of training for their employees. Help them make the decision easier by clearly stating a case for your training.

Note: This blog post was inspired by a recent conversation with career counselors at the Sogeti Minneapolis office.

Episode 178

Rich Dudley on the Job Interview Process

I’ve spent nearly 20 years working in technology. From my university days studying Computer Engineering; through my years managing a Lan Manager® network and writing FoxPro applications; to my time consulting with companies to help them build scalable applications to solve their business problems. I work with a wide variety of software and hardware tools. I’ve become proficient with some and I’ve developed the ability to quickly get up to speed on most tools.

But am I a technologist? Is the focus of my job to use computers, software and languages? Am I paid because of my expertise in a specific technology? Do customers value my computer skills over my other skills?

I never describe my professional self as an “expert” in anything. Instead, I emphasize experience, my learning abilities, and my problem-solving skills. Occasionally, a salesperson will tout my deep, technical knowledge on a topic, but I caution them against this, because it is not my greatest strength. My greatest strengths are the abilities to understand problems, to learn almost anything, to apply knowledge appropriately to a problem, and to share with others what I have learned.

I would argue that I am not a technologist – at least not primarily. As a consultant, my primary purpose is to add value to the customer. I do this by solving business problems. Some of the tools I use to solve those problems are types of computer hardware and software. But those are not the most important tools. The most important tools I use are communication skills and reasoning ability. It may be that the solution to my customer’s problem involves very little technical changes or even none at all. If it does involve software (which is usually the case), my application of that software is far more important than the bits within it.

I’ve seen a number of consultants who are focused on their technology of choice that they don’t seek a solution outside that area. If all you know is BizTalk or SharePoint or Lotus Notes, it’s very tempting to define business problems in terms that can be associated with your favorite tool. The popular expression to define this attitude is: “If all you have is a hammer, everything looks like a nail.”

For me, the solution is the important thing. Maybe it’s an advantage that I never immersed myself in a single technology. Maybe this keeps my mind more open to alternative solutions. If I need expertise in with a particular tool, I can either learn it or find someone who knows it well.

Does this mean that there is no value in deep technical knowledge of a topic? Of course not! There is great value in learning technology. The more we know, the more we can apply that knowledge to business problems. But it is the application of the knowledge that adds the most value – not the knowledge itself.

This mind-set becomes even more important when you consider the how international the software business has become. You may be a very good C# programmer. But, if you live in America, there is likely to be a very good C# programmer in India who is willing to do the same work for much less. And if you live in India, there is probably a very good C# programmer in China who is willing to work for much less. And if you live in China, keep your eyes open, because other parts of the world are developing these skills and they are anxious to penetrate this market and are able to charge even lower rates. It’s no longer possible to compete only on price (and still make a decent living) and it’s not enough to compete only on technical skill. The ability to solve complex business problems and apply the right technology can be the differentiator that allows you to compete in a global market.

Keep this in mind as you look for solutions to problems presented by your customer or employer. Focus on adding value to the business, rather than on applying a particular set of skills.

But in the end, I think I serve my customers better because I think of myself as a problem-solver rather than as a technologist.

Episode 156

Jon Galloway and Jesse Liberty on Remote Pairing

Episode 154

'Going Independent' panel discussion

Below are slides from the Data Visualization talk I delivered at the Kalamazoo X conference today

As someone who once passed a bunch of tests (>40) to earn a bunch of Microsoft certifications(>20), I'm sometimes asked about the value of these certifications. Are they worth the time, cost and effort they take? What are the benefits? Who benefits most?

The real cost of certifications
More than the cost to sit the exam (typically $150) is the cost of studying for the exam. I used to spend weeks - at least a couple hours each day - studying for each exam. This cost tends to far outweigh the exam fee.

What do certifications prove?
A certification demonstrates a minimal level of competence in a given technology. They don't flag the holder as an expert; but, assuming you didn't cheat, they require knowledge of the subject matter in order to pass.

Everybody learns differently
I hope all of us can agree that it is not possible to succeed as a software developer, network engineer or database administrator without learning new skills every year. Each of us learns in a different way. I think most people learn a technology best when they have something to apply it to. This application serves as motivation to learn and retain knowledge. If your job doesn't provide that application, you need to create it yourself. This might be a personal or open source project or it might be a certification exam. Either way, if it helps you to learn a new skill by focusing on a tangible goal, that is a good thing.

When are certifications most valuable?
Certification is no substitute for experience, but it can help to supplement experience. This is especially true early in your career when practical experience is lacking. For those new to information technology or software development, it can be difficult to build up the experience necessary to impress a potential employer. A certification can help make up for a lack of experience, because you have demonstrated the ability to complete a goal and enough knowledge to pass an exam.

Some places require certification. Why?
Microsoft partners with companies in different ways. In some of these partnership arrangements, the partner company must have a certain percentage of their employees certified in Microsoft technology. Although far from perfect, it's a very simple way for Microsoft to vet their partners.

So is it worth it?
From a personal standpoint, I don't at all regret achieving the certifications that I did. I took most of the exams early in my career and they gained me some credibility. As recent as two years ago, potential employers asked me about my certification and were impressed when I provided it. I have learned a lot studying for these exams and that knowledge has helped my career. I doubt that I'll be taking many more exams. My free time is limited and I prefer to use more efficient ways to learn, focusing on building applications or preparing and delivering presentations.

My advice is to consider certifications early in your career to improve your skills and improve your credibility; then spend your time elsewhere as you solidify your credibility.

Episode 82

Yesterday, I attended the second Kalamazoo X conference. This year's event featured a great list of speakers, presenting many thought-provoking topics. Ideas came at me so fast, it was tough to keep up. Here are some highlights of the presentations I saw.

"Treating the community like a pile of crap makes it stronger" by Brian Prince

The title of this talk comes from Brian's experience growing up in rural Maine and shoveling manure in the summer months. Manure works better as a fertilizer if you periodically mix it, moving the bottom to the top. The same can be said for user group leadership.
If you are a community leader, plan for a peaceful transition. Identify others who can take over and groom them to do so. Take some time off from the lead role in order to re-energize before coming back.

"Agile+UX: The Great Convergence of User Centered Design and Iterative Development" by John Hwang

John is a web designer and his company is applying agile methodologies to its project. He discussed the challenges of using Agile to manage User Centered Design (UCD) AND User Experience (UX).  The big challenge is that Agile is geared toward making developers more efficient, yet designers are a key part of any web development project. John avoids responding to amy Request for Proposal (RFP) because an RFP forceS you to estimate many tasks that you don't yet know and that are almost certain to change. He emphasized that development and design should be done in parallel and that the feedback loops and iterations of agile should apply to both. Developers and designers should work cooperatively, rather than in conflict.

"How to Work Effectively with a Designer/ How to Work Effectively with a Developer" by Jeff McWherter and Amelia Marschall

Jeff is a developer and Amelia is a designer and the two recently went into business together. They have worked together in the past and they related some of the challenges and lessons learned from their previous collaborations.

"Communication is the key" was a message they reiterated several times during this talk: Ensure that your partner knows what you are doing; verify that it is consistent with what they are doing and that the technology supports it. Developers and designers should strive to learn about the tools and skills of the others. It will help them figure out what they can accomplish.

Mock-ups are a key means for designers to convey information. Jeff said that he often writes business rules in the margins of Amelia's mock-up drawings.

"Does Your Code Tell a Story?" by Alan Stevens

Alan told us we should not bury the lead, so I will tell you his main point now: Beauty is the ultimate defense against complexity.

Alan took the advice of successful novelists and applied their principles to the art of writing code. "The code in our industry is crap", he asserted; then he explained how to make it better: Take chances; write shitty code in your first draft; refactor it several times; and make it clear, simple and obvious before releasing it.

"Unwritten Rules of Resumes" by Jeff Blankenburg

Jeff's major point was that your resume should stand out and distinguish you from other candidates. He advised ncluding a strong first paragraph in a personal letter, accompanied by a self-addressed, stamped return post card with your resume. This will help to establish you in the minds of the hiring personnel. Establish a strong professional network and avoid the temptation to burn bridges when you leave a company.

"Have you hugged your brand today?" by Clovis Bordeaux

Per Clovis, building a brand begins with a mission statement. A critical part of building your brand is getting every employee involved and on the same page, regarding the message you are sending about your company. 

Kalamazoo X home page

Photos

The last couple years, I have significantly increased my use of social media.

I don't believe that online social media is a replacement for face-to-face human contact or for a phone call. But it is a good way to stay connected with others between personal visits.

My primary social media sites are LinkedIn, Twitter, Facebook and Flickr. I use each of these channels for a different purpose and to communicate with a different audience: My resume is on LinkedIn; I chat with IT professionals daily on Twitter; I re-connect with old friends on Facebook; and I use Flickr to share photos.

I joined LinkedIn a couple years ago in order to connect with professionals with whom I had worked. I input my resume and built up a network of current and former co-workers. At the time I was building this virtual network, I didn't realize how useful it would be. A few months after joining LinkedIn, I found myself out of work and needing to network. I reached out to my connections and asked people to log in and write their opinions of the quality of my work. The response was overwhelming. Over 30 people wrote recommendations within a few days of my request. Several times, a potential employer mentioned these online praises during a job interview. I ended up finding a job quickly, via networking.

I use Twitter to communicate with like-minded souls in the tech community. As a software developer, I'm drawn to people who share my passion for learning and for technology. Many of the developers I know are also on Twitter. As a general rule, I tend to follow only those people that I've met in person or that I think I might meet soon. I see many of them at conferences a couple times; but our conversations on Twitter help to keep the relationships going between in-person visits.

I'm a pretty passive user of Facebook. I see my kids using the chat feature and I often see long, threaded conversations on the walls of others. About the only thing I do actively and regularly is advertise new blog posts, announce new episode of Technology and Friends, and show off photos I've taken. Despite being passive, I have reconnected with quite a few friends from my past. Many classmates from my high school days sent me friend requests and now I am using Facebook as a communication medium for our upcoming 30-year reunion. Facebook also provides a good way to get a message out to a lot of people in a hurry. Last year, my sister passed away and I was able to widely communicate her funeral arrangements by posting the details on Facebook. A number of people came to pay their respects after reading my Facebook message.

Flickr provides a social media mechanism: You can connect with other users, comment on photos and share ideas; but I don't use its built-in features. Instead I post photos on Flickr and link to them from Twitter or Facebook. Taking photos at a conference or other event and sharing them online is a great way to stay connected with the community. Recently, I have begun to cross-post my photos on SmugMug because this makes it easier for others to buy prints of my photos.

The sites you choose to connect with others online are not nearly as important as the messages are delivering and the connections you are making.

I have removed the word "easy" from my business vocabulary. I've come to resent the overuse of this word.

What I do is not easy: If it were easy, anyone could do it.

Customers sometimes refer to a task as "easy" in order to drive down the price; Managers sometimes refer to part of your job as "easy" in order to lower expectations of high performance reviews (a dangerous strategy).

This mindset is generally an offshoot of the belief that the time spent coding is equivalent to the time spent typing. It isn't.  Understanding requirements, planning, designing, clarifying, testing, configuring, troubleshooting, communicating, error handling, logging, deploying, and validating assumptions go into nearly every software task I complete.

I cannot count the number of times I was told "The code is already written. You only need to copy it." In nearly every case, this was a gross misrepresentation of the complexity of the task assigned.

A task can be measured on a scale from Complex to Straightforward. Every task has unknowns that add risk and can make it more difficult than our original estimates.

Developers sometimes fall into this trap, telling customers that something is easy. Many of us overestimate our skill and minimize the risks inherent in every task. I caution against doing this because it creates unrealistic expectations and makes it nearly impossible to exceed those expectations.

When describing a task that isn't complex, I refer to it as "straightforward"; Or I give an estimate of how long I realistically think the task will take.

The only time the word "easy" might be justified in describing a task is after that task is 100% complete. In the past, all uncertainties are eliminated and risk reduces to 0.

Replace the word easy with "straightforward" when dealing with software developers (or any professionals) and your relationship with them will improve.

I have been recording and producing the online TV show Technology and Friends for over a year. After over 70 episodes, I have found things that work well for me. This series is a detailed account of how I put together each episode.

Part 1: Preparation

Part 2: The Interview

Part 3: Equipment

Part 4: Post-Production

Part 5: Sharing with the world

In the last article, I explained how to edit a video and export it to a single MPG file. In this article, I will discuss how I share this video with the world.

Export

After I finish editing the video in Adobe Premiere Elements, I export it to a single MPG file. This is done by selecting the "Share" tab in the top right section of the editor. On the Share tab, I use the following settings: Personal Computer |MPG | NTSC DVD Standard. I enter a file name and select a directory and click the [Save] button to create a single MPG file containing my complete show.

Once I have a single MPG file, I can easily share it with others.

Upload

I upload the exported WMA file to a video-sharing site. I use Viddler because it is free and provides reasonably high-quality playback.

Viddler provides the ability to upload a file directly from their web site. I add metadata, such as a name and a description to each video.

Share

I link these videos from both DavidGiard.com and TechnologyAndFriends.com.

Viddler provides a button ("Embed This") that generates the HTML necessary to embed a video into a web page. I copy this HTML and paste it into a post on my two sites. Above the embedded video, I add some text to describe the video and any relevant links, such as the guest’s blog. I release both posts on the same day.

After releasing a new episode, I promote it via Twitter. I also send an e-mail to my guest, telling him or her that the interview is now available. Often my guest will link to the show from a blog or tweet, driving more traffic. If we are discussing someone else in the video, I often will e-mail that person or organization. After interviewing Jamie Wright about 37 Signals last year, I e-mailed 37 Signals to tell them about it. They linked to the video, which drove over 10,000 viewers to watch it.

My goal is to release at least one video every week, so I usually have a backlog of videos recorded, produced and ready to release.

Final Thoughts

On average, it takes me approximately 2 hours to produce a 20-30 minute show. This is in addition to the hour or so it takes to set up, prepare and record a show. So far, I’ve done this almost 80 times.

I use the following to record an interview

• My video camera
• Tripod
• Wireless microphone and base

Camera

I record with a Canon GL-2 video camera, which is a “Pro-Am” camera, meaning a camera that is higher quality than most cameras marketed at amateurs, but lower cost than cameras for professionals. This camera has served me for years. Luckily video cameras do not become obsolete nearly as quickly as other technologies (I’m thinking of you, 2005 Digital Camera). You can probably get by with a much cheaper camera than mine, especially if you are producing your show for the web. But I already owned this one when I decided to start recording my show, so it is the logical choice for me.

Tripod

Since I work alone, I need to affix the camera on a tripod. I use a Vanguard New Tourist 5 telescoping tripod. It’s strong, lightweight and collapses to fit easily into a backpack. Prior to the interview, I verify that the subject and I are both in frame and that we fill the frame. I am able to swivel the viewer on my camera, allowing me to see the LCD image, even when the camera is pointing at me.

Microphone

The GL-2 includes a built-in microphone, but the sound quality was not acceptable, so I purchased a wireless microphone. This microphone sits between me and my guest, and a receiving unit plugs into the camera. This setup provides much higher sound quality. I also purchased a steel to hold the microphone upright. I’m currently looking to upgrade to a better quality microphone than the Radio Shack brand I currently use. For this show, a wireless microphone is not necessary because we tend to remain stationary during the interview.

In the last article, I talked about how I prepare to record an episode of Technology and Friends. In this article, I'll discuss the interview itself.

Framing the scene

I nearly always work alone on this show, which means I don't have a cameraman. So it's up to me to properly frame the shot. I affix the camera to a tripod and ask my guest to sit or stand in front of the camera. Then I frame my guest in the digital viewfinder (an LED screen that shows an image of what the camera will capture when recording). On most television talk shows, the  host sits on the right. However I prefer to sit on the left. The reason is that my digital viewfinder swivels, so I can see it even when the camera is facing me and the viewfinder is more visible to me if I sit on the left. My goal is to frame each shot so that it includes me and my guest or guests, but very little beyond that. The shot looks best if we are close together, almost touching.

Without an assistant, I am forced to start recording, then walk into the camera view and check the frame. Sometimes I need to walk back behind the camera to adjust the framing. Of course, I cut out all this walking in and out during post-production.

The conversation

The Interview itself is generally the most enjoyable part of the show.

In my show, I want the guest to do most of the talking, so I ask a lot of open-ended questions. Rather than: Is this technology easy to use, I'll ask "What are the advantages of this technology"? Ideally, I'll ask a 15-second question and the guest will talk for 3 minutes. I try not to interrupt him* unless I feel they need to clarify something. If they introduce an unfamiliar term or acronym, I'll ask them to define it.

I will ask follow-up questions, based on what the guest says on camera.

Sometimes, he mentions something that sparks my interest and I'll ask for more detail.

Sometimes, I'll feel his explanation is too vague and I'll ask for clarification or an example.

Sometimes, he'll make an unsupported assertion and I'll ask him to defend that assertion.

Sometimes, I'll volunteer a relevant story from my own experience.

After a long explanation by the guest, I'll often try to summarize what they said and ask if I have understood it correctly.

Generally, I want the guest to sound relaxed and I want the tone to be conversational. As much as possible, I try to set him at ease. If either of us makes a mistake, I say “Edit Point” and let him know we can cut out that part later.

Sometimes, we may elect to re-record an entire sequence if someone misspoke or was unclear.

Although the show doesn't have a set length, I try to keep the interview less than 30 minutes because I want it to be concise. If I feel it may go longer, I will usually edit it for length or split it into two shows.

At the end of each interview, I give my guest a chance to promote himself by mentioning a blog or other online presence.

I wrap up the show by thanking the viewer and saying goodbye to the audience. Of course, I also ask each guest to speak a sentence using the words "Technology" and "Friends" as this has become a trademark of the show.

* For simplicity, I will use the masculine pronoun when describing a generic guest. I have had many female guests and plan to have more in the future.

If you are reading this blog, you probably know, I have been recording and producing the mildly popular online TV show Technology and Friends for over a year. I have recorded and released over 75 episodes and I plan to release a lot more in the future.

Recently, a number of people have asked me what goes into producing an online show.

There are four aspects to the show that I'll cover in this series: preparation, interview, equipment, and post-production. In this article, I'll cover preparing for the show

Finding a Guest

Everything starts with the interview and the interview starts with a good interviewee and a good topic.

I attend quite a few conferences and user groups, so I get to hear a lot of good speakers presenting technical material. I will often pick a guest because I have recently heard him or her deliver a good technical presentation and I want to record those thoughts for others to hear. I look for people who are knowledgeable and passionate about a topic and who can communicate well.

A conference is a good place to find guests because

1. Conferences tend to attract a lot of smart people to a single location
2. Speakers at a conference come prepared to talk in detail about a topic
3. Most people cannot attend every session of every conference, so this gives a wider audience to the speaker
4. I can sit in the session ahead of time and educate myself on a topic prior to speaking about it on camera.

A user group is also a good place to find a guest. Many of my interviews were recorded immediately after a speaker delivered a presentation at a user group. The challenge here is that user groups tend to end late at night and you must ask the host facility to stay open an extra half hour while you record.

I have also recorded interviews with co-workers that I know are knowledgeable on a topic. In most work environments, it’s possible to reserve a small conference room in which to record.

After I identify a good speaker, I approach him* and ask if he is willing to speak on camera for a half hour or so.

I nearly always give my guest the flexibility to schedule the time of the interview. People are busy and I recognize that they are doing me a favor by taking the time to record with me.

Selecting a Topic

I like to keep my show short and focused, so the guest and I need to agree on a topic. There are really only 3 criteria for a good topic.
1. The guest must be knowledgeable about the topic. Our goal is to share information with the viewers.
2. The guest must have some passion for this topic. Passionate speakers make for much better shows.
3. The topic must be of interest to my audience. Typically anything in the technology field meets these criteria, especially if it is new technology.

I try to avoid repeating topics, but I will cover the same subject twice if the second guest can add a new perspective.

If we are at a conference or user group, I often suggest that we talk about a topic on which they are presenting. This works well because the presenter has spent time preparing a presentation and knows the material really well. However, he may want to discuss something different. For example, a presenter may be researching and writing a book on a different topic and want to speak about that. As long as I feel the topic will be of interest to my audience, I'm happy to let my guest select it.

Location

As often as possible, I try to find a quiet place to record interviews. This should be a room with a door I can close and shut out external noise. Ideally, this room should be small and should have covered walls. Large rooms with bare walls echo much more. 

Unfortunately, this isn't always possible, so I try to find as isolated a place as I can.

Of course, the room must have available power for my camera and microphone. (My camera will run on batteries but I don't like to risk this)

Prepping the guest

Prior to the interview, I discuss with my guest what we will talk about. I nearly always write down an outline of the conversation. Depending on the situation, I have a couple approaches.

• I may sit in on their presentation and take notes. Then, I can ask open questions and guide the guest through an abbreviated version of the presentation.
• It may be a topic that I am already familiar with. In this case, I outline what I think are key points and I review these with the guest. They are free to add or modify my outline.
• It may be a topic with which I am not familiar. In this case, I rely on the guest to create an outline. Generally, I ask them the key points they want to cover and I write them down in outline form.  I also spend a little extra time learning about the topic in advance, so I can understand it well enough to ask follow-up questions or spark an intelligent dialogue. I find these conversations are enjoyable but much harder.

I also try to chat with my guest for a few minutes before the camera rolls in order to help him relax and establish a rapport. In more than one case, I had just met the guest prior to the interview.

In the next article, I'll discuss the interview itself.

* For simplicity, I will use the masculine pronoun when describing a generic guest. I have had many female guests and plan to have more in the future.

Episode 76

In this interview, DevExpress evangelist Gary Short discusses technical debt and its effects on a software project.

Episode 73

In this interview, Corey Haines talks about software craftsmanship, what it means to him and his plan to improve the quality of coding in our industry.

Episode 66

In this interview, Mary and Tom Poppendieck define competency, describe the importance of leadership and define the factors that make up these qualities.

2009 was a difficult year for me in many ways. My sister Denise was less than three years older than me when she passed away in July. Her death left a wound that is still healing. Worse than her death was the revelation afterward that she had been betrayed by someone close to her - someone we all trusted. We are still fighting this battle and it continues to elevate stress in my family.

But I also experienced many positives events in 2009.

The support of friends and family has been instrumental in getting me through these difficult times. If you are in this group, then I thank you. The tragedy shared by my family has brought us closer together in many ways.

My two sons continue to grow (physically and emotionally) and they continue to impress me with each new stage of their life. Timmy is now in high school and is showing more leadership qualities than I expected. Not long ago, he organized an independent basketball team completely on his own. They competed in a large league and he even convinced his brother to coach the team. His team performed well, despite playing in a league with kids mostly 1-2 years older. Timmy is working hard to balance school work with football and basketball. Nick is in his first year at Michigan State University. The time away from home is maturing him and each time I see him, I see more of a man and less of a boy. I remember a similar transformation in me during my first year at MSU. I particularly admire the fact that he is setting high goals for himself.

I have been dating a woman for quite a while. She didn't grow up in the US and her background is very different from mine, which presents some challenges; however, she is exceptionally kind and she is the most giving person I have ever met and I'm grateful she remains part of my life.

I did a fair amount of volunteer work this year, but most of it was not altruistic. I volunteer at a local non-profit music club in exchange for free admission to the concerts; I volunteer at the local public access TV station as a way to learn more about television production. The most good I did through volunteering was with the three Give Camps in which I was involved this year. I'm looking forward to participating more next year.

The biggest personal goal I did not hit this year was to lose 25 pounds. Resolving my sister's estate, being a single father, and other commitments kept me in the car so much that I had little time to exercise. Still this needs to be on the list next year.

One of my professional goals for this year was to be more involved in the software development community. In particular, I wanted to do more public speaking.  In 2009, I spoke at 5 conferences, 4 user groups, 3 internal Sogeti talks and 2 special events (ArcReady and NPlus1 summit). I expect this trend to continue as I have 5 presentations scheduled for January 2009.

I also became more involved in the Great Lakes Area .Net User Group this year. As Vice President, I took on the role of speaker coordinator and was able to line up some excellent presentations for the group.

In January I began production of my TV show "Technology and Friends" (although the show did not have a title for the first few episodes). During 2009, I published 63 episodes online. Recently this show has also begun airing on Channel 17 of my local cable system. Recording and producing was a great experience. It gives me the opportunity to talk with a lot of smart people and I have learned a lot about software, communication and video production.

I began my blog two years ago, but I devoted more energy to it in 2009. This article is the 155the entry for the year - an average of almost 13 per month. I don't know if I'll keep up that pace in 2010.

Despite the poor economy in Michigan, I managed to stay employed all year. During 2009, I worked for a significant time for three customers. At the end of each engagement, each customer had wonderful things to say about my work.

As the Microsoft Application Development lead in Michigan for Sogeti, I focused primarily on technical training for our consultants and on building a sense of community. I organized a series of "Grok Talks"  designed to exchange information. Some talks were delivered by Sogeti consultants (giving them valuable presentation experience) and some by experts in the industry. This was a big success and we plan to continue it next year, even though I will not continue in the same lead role.

As I write this, I realize that 2009 had more positives than negatives. The loss of my sister and subsequent discoveries still made it a difficult year, but I was able to accomplish a lot, thanks to some hard work and the support of family and friends.

I am looking forward to a happy and productive 2010. I have big plans, some of which I plan to share soon on this site.

Happy New Year and may God bless you all. 

Episode 63

In this conversation, independent consultant Michael Eaton describes the challenges developers face estimating software projects. He then describes approaches to these challenges, based on his experience.

I count many software developers among my friends and colleagues. Many of them tell of writing code in high school or earlier; of hacking during junior high school; or of knowing their career path at an early age.

My programming career began much later in life. Because I grew up with no inkling what I wanted to become, I majored in biochemistry as an undergrad and I studied finance in graduate school. During my eight years of matriculation, I kept busy working as a laborer for a construction company, coaching a high school wrestling team, selling financial securities, interning for a commodity trading advisor and painting. After four years attending grad school at night and working two jobs, I took my MBA and went to work doing accounting and financial analysis for a printer manufacturer. I spent almost four years at this job and it rarely changed. I learned almost nothing after the first year and found myself mightily bored.

At the time, it seemed like misfortune, but I was laid off from this job when the economy turned south and my employer sold off a large subsidiary. Months of job searching during the recession of the early 1990s left me feeling discouraged about my prospects. So I took this as an opportunity to change careers. I had taken a couple programming classes before and I had done well and enjoyed them, so I enrolled at the local university to study Computer Engineering. Sometimes the curriculum was difficult. For example, every other student in my Calculus 4 class had taken the prerequisite class the semester before.  I had taken it nine years earlier.

After two semesters of straight A’s, I was prepared to pursue a degree in Computer Engineering until the phone rang between semesters. It was an old friend of the family calling. He owned a small company in Cincinnati, had heard I knew something about computers and was looking for someone to help him with his computers. I had never been to Cincinnati before, but the offer was good and he was willing to pay for my training so I accepted and moved. Six months later, my house in Michigan sold and my family joined me.

I was a novice at that time and I knew it. I worked my tail off to learn everything I could about networking and programming and computers in general. On most days, I was the first to arrive and the last to leave work. I would get up early and drive in on Saturday to work a few hours before my family woke up. I worked at that company for five years. For most of that time, I was the entire IT department. I managed a LanManager network that I converted to a Windows NT network; I ran a call center of data input operators;  I was the company’s primary computer help desk; I evaluated and bought personal computers and servers and printers; and I wrote all the company’s custom software.

Of these tasks, writing software appealed to me most. In programming, I had the ability to learn technical skills, to practice logical thinking, and to exercise my creativity. It gave me the opportunity to exercise all parts of my brain. I decided I wanted to focus most of my energy on programming.

At that time, my language of choice was FoxPro, which gave me a chance to build Windows user interfaces and to learn about relational databases. I learned about language constructs and programming algorithms and naming conventions and frameworks. I would stay up late into the night reading programming books and technical journals. I enjoyed learning about programming far more than I enjoyed accounting or finance.

When Visual FoxPro was released, I redoubled my efforts, trying to grasp the concepts of object oriented programming and deciding when to use inheritance.

After five years, I got the opportunity to join a local consulting company, where I could focus on software development and training. I would rotate between teaching classes and building business solutions. This was another great learning experience: Teaching made me a better programmer and programming made me a better teacher.

This consulting company was known for its FoxPro expertise but we did a fair amount of Visual Basic programming and I was able to learn my second language. When Microsoft released ASP and Visual InterDev, I learned that and began teaching a class in web development. I taught that class more than any other.  I learned about XML in 2000 and began applying it anywhere I could, like a hammer looking for a nail.

Unfortunately, the company I worked for made some poor business decisions and people began to leave – first the customers, then the consultants. I followed a friend to G.A. Sullivan (aka GAS), a medium-sized consulting company in Cincinnati. I was attracted to GAS because of all the talented developers they had on board already.  Where my old employer seemed to be drifting from day-to-day, the new group had plans. They managed projects with efficiency, they had in-house experts in numerous areas; and they were well-respected by their customers and by other development shops. Not only did I learn a great deal of technology (I was at GAS when I did my first .Net project) but I first began to do public technology presentations at that time. I spoke in front of customers and at the local VB user group (later reborn as CINUG).

To this day, I have not worked with a group as talented and tight as the folks at GA Sullivan. Most of us have moved on, but I remain close friends with a number of my former colleagues from those days.

After a couple years, GAS was purchased by Avanade, a large multi-national consulting company started as a joint venture between Accenture and Microsoft. With such enormous parents, Avanade was able to go after much larger customers. During my years there, I traveled a lot but I was able to work on a number of large enterprise applications, which helped me in understanding scalability, security and how to navigate the bureaucracy of a large corporate environment.

I had my first exposure to Rules Engines, Workflow Foundation, Unit Testing, and Continuous Integration on various projects for Avanade. I spent over a year focused almost exclusively on BizTalk Server, diving deep into Microsoft integration technologies.

I wrote very little code my last year at Avanade as I led a team designing an e-commerce integration project. Instead I got experience writing design specifications and developing project plans for a waterfall project.

In 2007, I left Avanade because I wanted to spend more time with my family. I took a job with Quick Solutions Inc. (QSI) because I was impressed with the smart developers I met there and I admired their passion working and speaking in the community. I got back into coding working on an ASP.Net portal project. I also had a chance to learn from some smart people about Agile development methodologies, Team Foundation Server and the database tools of Visual Studio. Being closer to home allowed me to spend time with the developer community.  For the first time in years, I began actively speaking at conferences and user groups and participating in user groups. In 2008, following a change in ownership, QSI decided to get rid of all their consultants outside of Columbus, OH. 

A year of being active in the local community made it easier to find a new job and I joined Sogeti, my current employer. While here, I’ve worked in a variety of industries and even did my first SharePoint project. I’ve kept active in the development community, in part as a way of expanding my own knowledge of technologies.

I’ve had a number of stops over the past 15 years and I’ve learned something new everywhere I’ve been. Looking back, losing my job as an accountant was a good thing for career and my life.  

When I work on a project and I hear advice from others, I’m reminded of all the advice I heard the year my first son was born.  Often one recommendation would directly contradict another. They couldn't all be right, could they? In the end, I decided there are multiple correct ways to raise a child so I followed my own instincts each time I had to make a decision. 

Software design and development are full of decisions – some big and some small. We argue passionately over these decisions. We agonize over them, sometimes even after we make them.  Here are just a few examples

• Web forms or MVC?
• ASP.Net or Silverlight?
• ADO.Net or ORM?
• Web Services or Remoting?
• Visual Basic or C#?
• .Net or Java?
• Comments evil or comments good?

But are these decisions worth agonizing over? In many cases, they are not.

In my professional life, I have argued vigorously many times for architectural points I believed were correct. Some choices were small and some were large. Sometimes I won and sometimes I lost these arguments. But I accepted those decisions because I recognize that there are multiple right answers to almost every question.  In almost every lost argument, the decision we settled on was good enough to get the job done.

I recognized that the important thing was to commit to a plan of action and move forward with it as a team.

Occasionally I’ve seen colleagues pout over a decision they did not buy into and use that decision as an excuse for failure. This is a self-fulfilling prophecy. A divided team is unlikely to succeed regardless how they design their project.

I am not trying to justify bad decisions. Some mistakes can be fatal and are inexcusable. These should be escalated up the command chain. But the vast majority of software project decisions are not life-threatening – even if they go against our thinking. We may grumble that our path is not optimal, but a decision that moves the project forward is acceptable.

There is very little dogma in software development. Your view works for you but it may not be best for the team or the project. And even if it is best, that doesn’t mean other views will not solve the same problem. Here are some guidelines that I use.

• Time-box your decisions.  Commit to a decision by a certain date.
• Don’t feel the need to explore every alternative. Generally speaking, time will not permit this.
• Pick a good solution that meets your needs. Don’t be swayed by those who insist it is not the absolute best. It’s better to move forward with a workable solution than to delay a project indefinitely in search of the best solution.
• Debate openly and honestly. Be respectful but recognize the pros and cons of each alternative.
• Don’t make it personal. Just because someone disagrees with you doesn’t mean he is attacking your intelligence or integrity.
• Keep an open mind. Consider that there may be an alternative solution with advantages you have not considered.
• What worked on another project might not be appropriate for this project. Always consider decisions in the context of your current needs.

The overarching theme of this list is you should find a solution that works for your problem and move on, without wasting excessive time doing so.

And for the record, my newborn son is not 18 years old and had turned out better than I ever hoped.

Lynnne Truss is a stickler - a stickler for proper punctuation. 

I don't know if she wanders the streets with a marker to add missing apostrophes - such as on posters for the movie Two Weeks Notice; or with white stickers to conceal extraneous punctuation - such as in a store signs that read "Boat Motor's", but I know that she is tempted to do so. I know that it pains her to see such misuse of common punctuation in public places. She agonizes each time she sees "its" and "it's" misused.

She put together "Eats, Shoots & Leaves" - a small volume designed to clarify the proper usage of punctuation in the English language and to pursuade us that it is important. 

Like Ms. Truss, I agree on the importance of punctuation, particularly in public or professional communication; but I don't always know the correct rules, so her advice is useful.

The book devotes a full chapter to the use and abuse of the apostrophe; another to the comma; a third to the dash; and so on. For each punctuation mark in question, Ms. Truss lists the proper usages of that punctuation and some common, and annoying, violations of those rules.  For example, her book lists 17 distinct uses for the comma.

It’s a difficult task because punctuation rules are sometimes vague and open to interpretation; and because the rules are often broken by respected writers; and because the rules change in a living language like English. 

But Truss does her best to clarify the vagaries and to evangelize the static, unambiguous rules. It's important because the meaning of a sentence can change dramatically, depending on the punctuation: "Extra-marital sex" does not mean the same as "Extra marital sex";

The poor punctuation of "Eats, Shoots & leaves" (the title; not the book) misrepresents the characteristics of a panda. An extraneous comma suggests that a panda employs firearms after its meal and before its exit. Correctly punctuated ("Eats shoots and leaves"), the phrase describes a panda's favorite meal.

Most of Ms. Truss's advice does not sound like a textbook. Regarding comma usage, for example, she dictates the rule: "Don't use commas like a stupid person". What she means is that one should step back and read a sentence to verify that the punctuation conveys the correct meaning. 
For example, the sentence
"Leonora walked on her head, a little higher than usual."
is grammatically correct, but probably not what the author intended.

Despite her passion for the topic, her style is light and engaging. I laughed out loud several times while reading this short volume. She parenthetically refers to Gertrude Stein as a "strange woman" (presumably because she disagrees with nearly every opinion Ms. Stein holds on punctuation); and she once described a long, over-punctuated sentence as exhaustedly slipping into a comma.

I really enjoyed this book and will keep it on my bookshelf beside Strunk and White's excellent The Elements of Style because it is concise, accessible and extremely useful.

Episode 39

In this interview, Jamie Wright, president of BrilliantFantastic Consulting describes how he has applied the Getting Real software development process from 37 Signals to his own consulting practices.

12 mins, 39 secs

Contribupendence Day is the brainchild of Microsoft Developer Evangelist Jeff Blankenburg.  He came up with the idea a year ago and this is the second year in which I have participated.

Jeff pointed out that most of us sometimes get to work with outstanding people (true for me) and that we often don't take the time to recognize the contributions of those people (also true for me). To correct this, he deemed July 3 "Contribupendence Day" - a day in which we can contribute to the independence from mediocrity of outstanding colleagues.  

Jeff suggested that we do this by choosing a few excellent past or present co-workers and writing a recommendation on a networking site. I chose four former co-workers and wrote a recommendation for each on LinkedIn. I won't list their names here, but you are welcome to view my LinkedIn profile and see what I wrote.

I don't expect anything in return but I didn't expect anything last year and I ended up reaping benefits anyway.  I wrote a number of recommendations last July in response to Jeff's call. A couple months later, I found myself out of work and looking for a job. One strategy in my job search was to request LinkedIn recommendations from former co-workers. I believe that I received better responses from these requests because I had so freely given recommendations earlier in the year. I was touched and delighted by the outpourings of those willing to write nice things about me in a public forum. During my job search, several interviewers told me they read my LinkedIn profile and were impressed with the quantity and quality of the recommendations I received.

So take a few minutes today to speak honestly about those who have impressed you. You never know when or how the favor will be returned.

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.

Juan

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

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.”

I expected that the Kalamazoo X conference would be a success but I was surprised by how successful it was.

Everything started with Michael Eaton.  He turned the concept - a conference consisting primarily of talks on soft skills - into reality.  Assisted by a staff of volunteers, Michael secured the venue, promoted the event, signed up the sponsors and recruited the speakers.  The speaker list was impressive - most traveled from Ohio and most have a solid reputation in the development community. 

I was grateful that Mike asked me to speak at this conference and I was excited to do it.

A couple weeks ago, Mike suggested that we switch from a multi-track to a single-track event.  This meant that all sessions would be held in the same room and that no two speakers would talk at the same time.  In order to accommodate this format, all sessions had to be cut from one hour to 25 minutes.  This was difficult for those who had already prepared an hour-long talk.  However, nearly all were able to make the adjustment.  (At least one speaker decided to back out after the format change was announced).  For me, this was less of an issue because I had never given my talk before and had barely begun preparing it. 

The format worked really well.  Speakers were forced to cut the fat from their slides and each talk was concise and to the point.  This also gave me the opportunity to watch every session, since I never had to choose between two excellent speakers.

One thing that added to the event was Mike's skills as a Master of Ceremonies.  He introduced each speaker by telling a personal story about him or her.  It was clear he was familiar with all the speakers and had put some preparation into these introductions.

My talk - Effective Communication with your Customer or Manager - was very well received.  Several people approached me afterward and told me how much they enjoyed it.  I'm working on a series of articles on this topic and hope to have them out in the next few weeks.

The most telling thing about the success of the conference was that there were attendance was higher at the end of the day than at the beginning.  Whatever small attrition occurred during the day was more than offset by others showing up.

I'm looking forward to next year.

See more photos here

I enjoy attending technical conferences and I try to make it to as many as I can.  I like talking to and learning from bright people in the developer community and picking up the latest technologies.  Developer conferences are a great way to get this information and there is no shortage of such conferences.

The Kalamazoo X conference is different.  Although the target audience is software developers, the content will focus on soft skills.  Topics such as Leadership and Social Network dominate the agenda.  The conference features four tracks: Soft Skills; Architecture, Design and Process; User Experience; and Career Development.  However each session will be short enough that an attendee will be able to see 100% of the content.

I'll be there to share ideas on effective communication with your customer or manager, a topic I've given a lot of thought to in recent years.

The conference is scheduled this Saturday April 25 at the Kalamazoo Valley Community College Center for New Media in downtown Kalamazoo, MI.  You can register and get more information at http://kalamazoox.org/

I hope to see you there.

Episode 1

I spoke with Telerik Developer Evangelist John Kellar at CodeMash about how to effectively interview tech people on camera and about the DevLink conference.

View John's video interviews at EdgeOfDev.com

This Tuesday, November 25, I will speak at the ArcReady event at the Microsoft office in Southfield, MI.  My topic is Organizational Dynamics.

Microsoft Architect Evangelist Brian Prince will also be there, delivering a presentation on Mastering the Soft Skills. 

I'd love for you to attend.  The event runs from 9:00 - 11:45 AM.  It's free but you must register in advance.

You can read details of the event and regsister for it here. 

Ten years ago, I showed up for my first meeting with my first customer while working at my first consulting job.  The customer was a dressmaker in suburban Philadelphia and I flew out to meet the IT Manager.

Everything went wrong. 
-The receptionist at my office erroneously told the customer that I would arrive first thing in the morning, even though my flight was scheduled to land after noon. 
-The customer was already disappointed by the quality of work delivered to date and had transferred at least part of his blame to me.  "This is your last chance", he told me during our first meeting, even though it was also my first chance. 
-The project was in a horrible state.  It was already past due and over budget when it was assigned to me.  The existing code as an undocumented mess of spaghetti logic, riddled with bugs.  Further it contained no logging or even graceful error handling.  When the program encountered an error, it simply crashed.

After a few months flying across country and working long hours, I was able to get the project quality to a level that was acceptable to the customer. 

But at that first meeting, I was completely confused and thoroughly intimidated.  I was there to help the customer but our relationship felt adversarial from the start.  I did not manage that first meeting well at all.

Since that time, I have had hundreds of first meetings with customers and I have gradually become better at managing that first encounter.

Given my disastrous first day on site, this article serves to give you the benefit of my ten years of trials and errors.  I like to believe that I learn from my mistakes and now you can also learn from my mistakes.

So here are my rules for a consultant’s first meeting with a new customer.
Rule 1: Listen
Rule 2: Don't solve the problem too soon
Rule 3: Set expectations
Rule 4: Do your homework
Rule 5: Other rules

Rule 1: Listen

This is the first rule because it is by far the most important.  You want your customer to describe his pain points for you and you want to have an understanding of those pain points and why they are causing problems.

Most of the time, a consultant is brought in because the customer wants to change something.  Find out what is driving his desire for change. 

Sometimes the customer has a detailed map of where he wants to go; sometimes he has no clue; sometimes he can see part of the solution; and sometimes he thinks he knows the solution but is on the wrong track.  Listen to what he has to say before deciding into which group your customer falls. 

Try not to interrupt, but ask relevant questions to clarify anything you don't understand.  Customers sometimes use jargon that they understand but you do not.  Ask for definitions when these terms come up.

Take good notes.

When the customer finishes, echo back your understanding of what you heard.  You can do this immediately or in a follow-up e-mail shortly afterward.

Rule 2: Don't solve the problem too soon

This point is related to the last one. Consultants and technical people tend to be problem solvers.  If we hear a problem and think we know the answer we want to shout out that answer to show off how smart we are.  (Okay, maybe you don’t; but I find myself fighting this urge all the time.  I’m a show-off and I’ve met many like me in the consulting industry, so I’ll stereotype here.) 
Most customers (another stereotype coming now) hate this.  If you tell them what they need before they describe their problem, you come across as arrogant, sloppy and uncaring. 
Your first idea may be correct but you should verify this before shooting off your mouth.  Of course, there is always the chance that the customer may know more about his own business and his own problems than you do.

It’s okay to ask questions, such as “Have you thought about this?” or “Have you ever tried this?” but be careful.  Don’t come across as suggesting that you know the answers before he even asks the question.  You are likely to lose credibility before you start.

Rule 3: Set expectations

I am a firm believer that every meeting should have an agenda.  For the first customer-facing meeting, you need two agendas:
1) What will be discussed at this meeting?
2) What will be the responsibilities and expectations of each person during the project?

Many projects fail because those involved don’t know what they are expected to deliver.  Assumptions can be fatal to any project because it is unclear who should be working on what.

Although each project is different, here are a few common questions worth clarifying
-Does the customer want a prototype or a production-ready application? 
-What is your role?
-Is the design complete?  
-Are you expected to lead or participate in the design? 
-Does the customer want you to mentor some of their team members?
-Are there any dependencies you need to be aware of?  What is the contingency plan if a dependency is not met?

You don’t need to answer all these questions at this first meeting but you should talk about them early in the project.  And you should leave the first meeting with an idea of the scope of the project and your role on it.

Rule 4: Do your homework

Before arriving at your first meeting, you should make an effort to find out what you can about the customer and his problem. 

Many times, a salesperson or project manager will have already spoken with the customer.  Talk to these people and get their take on what the customer wants.  Don’t accept that the salesperson has provided 100% of the information.  Several times, I have heard a customer describe a completely different problem than the one described to me by the customer.  (See Rule 1 for how to prevent this miscommunication).

Use the World Wide Web to learn at least the core business of the customer’s company. 

A little preparedness creates a good first impression and provides some context for your opening conversation. 

Rule 5: Everything else

Here are a few more bits of advice I’ve picked up over the years.
-Be on time.  Verify the scheduled time and plan to get there early if possible.
-Dress a little better than the customer.  This advice is often given for job interviews and I think it applies here as well.
-Avoid jargon and acronyms unless you are certain that the customer is familiar with the terms you use.  Your goal is to communicate and jargon often gets in the way of that goal.
-Don't take it personally.  I've had customers blame me for the mistakes of other consultants (some of whom worked for other companies), for the quality of Microsoft software, and for the health of their business.  In nearly every case, they are blowing off steam.  You should make every effort to keep the conversation on topic and the topic is: "What are your problems and how can I help you to solve them?".

Conclusion

The above list of advice is certainly not exhaustive but my experience has shown these to be the most important points when meeting a customer for the first time. 

Every year, I become a bit more accepting of my own ignorance. 

I decided a long time ago that I wanted a career in which I could continue to learn and to expand my knowledge.   Software development affords me that opportunity because it is such a large field and because it changes so rapidly. 

It is conceivable (though extremely unlikely) I could learn everything there is to know about software development and find myself completely caught up with learning for one day.  If that miracle were to occur however, I would go to bed that night and awaken to discover that things had been invented while I slept.  And I would once again be ignorant about some things.

But that day will never come.  There is an infinite amount of knowledge to be acquired and a finite amount of time in which to learn it.  The ratio of what I know to what I don't know is likely to remain small.

Yesterday, I had lunch with a guy who knows a great deal about Windows Presentation Framework (WPF).  Since I am extremely ignorant about WPF, it was a good opportunity to learn some new things.  But WPF contains so much that we could probably have lunch every day for months and I would still only scratch the surface of this framework. 

I want to know everything but I realize and accept that I cannot.  So what's the answer? 

The answer is in learning how to find the answers.  "I don't know" is an acceptable answer to any question, but "I can't do it" is not.  As new challenges and problems arise, we need to be able to figure them out - to find the answer.  Usually our experiences only get us so far.  We need help finding answers. 

Certainly the World Wide Web helps.  Many times, when faced with a problem, I've discovered an article or blog post written by a developer who faced and conquered a similar problem.  Search engines such as Google allow us to find these solutions more quickly. 

Books and magazines help as well.  They provide knowledge based on the experiences of the authors.  So do Classes and conferences.

I've found one of the best ways to improve my knowledge base is to build a network of smart people on whom I can call for tough questions.  I try to reciprocate as much as I can, but luckily software developers tend to be very generous with their ideas.

So the conclusion I've come to after all this introspection is that what we know is not nearly as important as what we are capable of finding out. 

And that's encouraging for a guy like me who will never know it all.