Podcasts I'm Listening to Now

Here's what I'm listening to this month.  If you have any suggestions for things I might like, especially tech/programming podcasts, send them my way.

I listen to these regularly:

Major Nelson - Covers the world of the XBox360.  News, reviews, interviews with insiders.

This Week in Tech - Leo Laporte and a cast of characters talk about the technology news of the day.  Includes guests like Steve Wozniak.  A bit chaotic but you get a good overview of the week's happenings so you can dig in more later.

Security Now - Very informative show about the world of computer security.  Lately they have been doing information series covering networking, crypto, etc.  Also covers practical tips.

The Dice Tower - Best of the board gaming podcasts.  Reviews, news, and top ten lists.  Gives a good overview of what is out there.  Good place to become introduced to new games.  The hosts are good natured and fun to listen to.

Engadget - This is last on my list but I usually get to it.  Everything you need to know to stay atop the fast-paced world of cell phones and gaming systems.

These are not published regularly but I find interesting listening when I run out of regular podcasts:

Nerd TV - Interviews with lots of big names in technology.  The interviews sometimes wander (Bill Joy's sailboat?) but are always interesting.

ITConversations - I've started listening to the programming series there.  It doesn't appear to be getting any new podcasts but the archives are fun.

Naked Conversations - Live

   Yesterday I went to see Robert Scoble and Shel Israel talk on campus.  It was a stop on their book tour.  It was an enjoyable hour.  Their presentation was better than many book tours I've attended.  First, it was on topic.  They discussed what they talked about in their book.  It is amazing how many times an author comes around shilling one book but spends the hour talking about something wholly different.  Second, it wasn't just the book.  Sometimes authors come and read a portion of their book out loud.  Thanks, I'll read the book.  Third, they were very extemporaneous.  They had a roadmap but still interacted with the crowd.  A lot of interesting questions were answered.

   For those who haven't read the book (that includes me right now), the basic thesis seems to be that corporate blogging is displacing traditional PR methods.  You get a more authentic connection with your customers when you keep it real than when you sanitize everything before it is sent out.  Sure, there can be mistakes made without the PR-filter, but that's exactly what makes it so valuable to customers.  As a user, I find that I rarely read about a product on a company's web site any more.  It is trying too hard to get me to buy and not hard enough to educate me.  Instead, I'll go read reviews or look in the forums.  Blogs can fill a similar role.  Bloggers from within a company can be great advocates for their products but still be informative.

   I think Robert and Shel are probably taking things too far.  There is a place for both corporate bloggers and PR.  Having a designated, official mouthpiece can be good.  It gives the ability to answer a question definitively and give people confidence that the answer won't change (soon).  At the same time, it will always be suspect because it is so one-sided.  Corporate blogs, if done right, should be more personal and less partisan.  They help put a human face on a business.  People are still, at the core, emotional creatures.  A human bond is worth more than lots of perfectly crafted press releases.

Blogosphere Gets Taken

There has been a lot of talk in the blogosphere about how it it replacing old media.  The response of old media seems to be that the blogosphere is uncontrolled and therefore inaccurate.  The response back has been that the blogosphere is self-policing.  If someone says something inaccurate, they won't last long.  Today we see a stark example of why the blogosphere is still flawed.  David Richards writes an article claiming that Microsoft is delaying Windows Vista in order to rewrite 60% of the code.  Not only that, but we're going to have the XBox team come save us and start working on Windows.  If you actually read the article, the numbers appear to be pulled out of thin air.  The number 60% shows up in the headline and the opening sentence.  It's not actually ever sourced.

Whether it is memeorandum or slashdot, the blogosphere seems eager to suspend disbelief when it comes to bad news about Microsoft.  Memeorandum links to more than 15 articles, only a handful of which call the number seriously into question.  Think about the scope of the claim.  Windows is reported to be something like 40-50 millions lines of code (I haven't counted them myself).  If that is true, we're going to rewrite 25 million of them?  I think not.

The blogosphere is not as objective as it might think that it is.  Often times the community policing works but there is also a bias and when something plays into that bias, the policing breaks down.  It will be interesting to see if cooler heads prevail here soon.

The Dangers of Test Automation

   One of my favorite TV shows right now is House.  In it a brilliant but antisocial doctor and his staff try to solve medical mysteries.  If you don't watch it, you should.  The writing is great.  Earlier this season, there was an episode where a journalist hits his head and has slurred speech.  The team is trying to diagnose this and having no luck.  Toward the end, House tells them to go do the blood work again and "don't use a computer."  When they look at the blood under a microscope, the cause becomes readily apparent.  There are parasites in the blood.  The patient has malaria.

   Just like the computers examining the blood were not programmed to look for parasites, so too the software that we write to test a program is often not programmed to look for all of the potential failures.  When we write test automation, we are focused on one thing.  If testing a video renderer, the test will make sure that video output is correct.  What if that output causes the UI to be distorted?  What if it causes audio to glitch?  The test wasn't programmed to look for that.

   About a year ago I first visited the concept of test automation.  In that article I gave several reasons why the best testing must be a mix of both manual testing and test automation.  The idea that all tests should be automated continues to pervade the industry.  It is thought that testers are expensive and automation is cheap.  Over the long haul, that may be true.  It is especially true when projects are in sustaining mode that you want primarily automated tests.  However, when developing a new product, relying solely on automated tested can be disastrous.  In addition to the issues I talked about in my last post, there is a danger I didn't discuss.  That is the danger of missing something obvious but unforseen.

   Before diving in, let me get some definitions out of the way.  Manual testing is just that:  manual.  It involves a human being interacting with the program and observing the results.  Test automation is the use of a programming language to drive the program and automatically determine whether the right actions are taking place. 

   In addition to the higher cost and thus higher latency of automated testing, it is also possible that automated testing will just miss things.  Sometimes really obvious things.  Just like the computers in House that missed the parasites, so too will test automation miss things.  Just recently I came across a bug that I'm convinced no amount of automation would ever find.  The issue was this:  while playing a CD, pressing next song caused the volume to maximize.  To a human, this jumped out.  To a computer designed to test CD playback, all would seem normal.  The next song did indeed play.  Even a sophisticated program that knew what each chapter sounds like would probably not notice that the volume was too high.  A programmer would specifically have to go looking for this. 

   There are a near-infinite amount of things that can go wrong in software.  Side effects are common.  Automation cannot catch all of these.  Each one has to be specifically programmed for.  At some point, the returns diminish and the test is set in stone.  Any bugs which lie outside that circle will never be found.  At least, not until the program is shipped and people try to actually use it.

   The moral of this story:  never rely solely on automation.  It is costly to have people look at your product but it is even costlier to miss something.  You have to fix it late in the process--perhaps after you ship--which is really expensive.  You lose credibility which is even more expensive.  Deciding the mix of manual and automated testing is a balancing act.  If you go too far in either direction, you'll fall.

Becoming a Lead, Pt. 4 - We Not I

   Another aspect of becoming a lead/manager that takes some time to wrap one's head around is what your role is now.  You are no longer judged based on your own actions, but rather the collective actions of your team.  With all of the time you will likely spend developing people, attending meetings, reviewing work, etc., your direct contribution to the collective output of the team will be low.  This is more and more true, the greater the number of reports you have.

   The role of a lead is fundamentally different from that of an individual contributor.  A lead is tasked with maximizing the output of his or her work group.  More often than not, this means that the lead takes a back seat when it comes to "real work."  It is more important that you spend your time growing, unblocking, and dealing with bureaucracy than it is that you fix a bug or implement some feature. 

   Writing software takes a lot of concentration.  It takes unbroken time to just sit and work.  As a lead, your day is usually broken up.  It is hard to get that time to concentrate.  When you get it, it often comes at the expense of other things.  You won't have the same opportunities you once had.  Instead, your day will be working with others to solve their problems.  You will be helping people develop themselves.  You will be helping to prioritize the work.  You paying more attention to the project as a whole than to particular features.  This is all good work, but it is very different from your previous life as an individual contributor.

   This becomes really apparent when it comes time for reviews.  At Microsoft we have a review system where we are judged based on the goals we set for ourselves and our ability to achieve those goals.  When you are an individual contributor, your review is easy.  You just list off everything you did during the previous year.  I wrote this.  I tested that.  I drove this iniative.  When you become a lead, your review changes.  When you sit down to write your first review as a lead, you'll notice that your individual accomplishments were not what they once were.  That's okay though, you are no longer responsible for just "I."  You are now responsible for "We."  You are judged by, and it is okay to claim credit for, the work of your team.  We wrote this.  We tested that.  One of my reports drove this iniative.  The first time you write a review like that, it feels like cheating.  After all, you didn't do that work.  Your role has changed.  That work took place because you facilitated it.  You kept people focused and unblocked so they could give 100% of their effort.  Welcome to your new job.

  

HDTV Primer Podcast

Another interesting podcast I've found, this time giving a lot of detail about HDTV.  This comes from Major Nelson who is interviewing someone from Microsoft Studios.  The interview composes the majority of the podcast.  It is quite informative.  This covers the differences between all of the formats (1080p, 1080i, 720p, etc.), what makes HDTV look good (and bad), etc.  If you are trying to understand the world of HDTV, check this one out.

This comes in two different formats:

MP3

WMA

 

Becoming a Lead, Pt. 3 - Delegating

   I've noticed that people new to leadership roles often struggle with the concept of delegating.  Learning to delegate is imperative for a leader.  When you become a lead, you gain responsibility for more than one person can do.  Without delegating, you'll fail to get everything done and likely burn out trying.  Delegating should be easy.  Just tell someone else to do something.  So, why is it that so many people struggle here?

   When one becomes a new leader, he or she is likely to have been an individual contributor in that area prior to the change.  This means that they are an expert.  Many times a new leader is put in charge of less experienced team members.  This sets up an interesting conundrum.  The leader is more capable of doing the individual work than are their reports.  Less experience means less elegant solutions that take more time to implement. 

   If I, as a leader, am able to solve a problem in 2 days that will take someone else 5 days to solve, the tendency is to just solve the problem myself.  In that way, I'll get a better solution, faster.  This is true.  There is a catch though.  It doesn't scale.  If I am responsible for the work of 4 people, I can't work hard enough or fast enough to do it all myself.  I can accomplish any one task faster than my reports but I can't accomplish *all* tasks faster.

   It is important to yield responsibility to those less capable than yourself for two reasons.  The first is that you don't have time to do everything.  In addition to the individual work heaped upon your team, you likely also have managerial tasks to accomplish.  These might include reviews, budgeting, meetings, people development, etc.  There is just not enough time in a day to do all of that and accomplish the work of 4 people.  It is important to realize that 5 days of a report's time might still get done sooner than 2 days of a leads time.

   Second, if you never give responsibility for the hard tasks to the more junior members of your team, they'll never grow.  Why is it that you--the new lead--are able to get the work done so much faster than your reports?  It is because you have more experience.  Giving people responsibility helps them grow.  It may take them 5 days to accomplish the 2-day task this time but next time it will take them 4, then 3.  Eventually they'll be able to do it as well as anyone.

   The key to succeeding in delegation is to give people the opportunity to grow.  This also means giving them the opportunity to fail.  The two are different sides of the same coin.  Growing the skills of your reports will make you successful as a leader.  It will allow the team to take on more ambitious tasks and solve problems in better ways.  A leader doing all the hard work him/herself precludes growth and is thus a prescrition for failure.

Geek Camping Tricks

   This past weekend I went camping with some friends in a cabin near Chehalis, WA.  Unfortunately for us, we didn't fully consider the implications of going camping on this particular weekend.  You see, Friday was the season finale of Battlestar Galactica.  Now, most of us have Media Center or Tivo and could watch it upon our return but that wasn't soon enough.  One of the people present had brought a laptop and had an Edge-capable phone.  We hooked the phone up to the PC and, using Orb, we were able to stream the show.  The video quality wasn't spectacular and there was some buffering involved, but it worked.  We were at a cabin in the middle of nowhere watching a TV show that was recorded on someone's PC 100 miles away.  How cool is that?

Becoming a Lead, Pt. 2 – Learning To Trust

When I became a lead, one of the first real changes I noticed was the necessity of trusting those who worked for me.  When you are no longer doing all of the work directly, you have to report what others tell you.  This is very different from reporting on work you’ve done yourself.  This can feel really strange and can lead to a desire to double check everything.  Resist that temptation.
 
When you are an individual contributor, you *know* the truth of everything you say.  If someone asks you whether a feature works or not, you know the answer.  You are the one who ran the tests.  You have first-hand knowledge of its state.  Similarly, if someone asks you how far along programming for the new widget is, you know.  You are the one doing the programming.  

This all changes when you become a lead.  If your manager asks you the state of a feature, you can only repeat what you were told.  If the person telling you didn’t do things right, you’ll be passing on false information.  This takes some time to come to grips with.  It is a strange thing the first time you have to do this.  Up until now, you’ve always known for certain the truth of your statements.  Now, you do not and really cannot know.

How then should a new lead deal with this?  You have to just trust people.  Until they prove that they are not trustworthy, you need to just believe them.  If they tell you that FeatureX is working, you have to report that.  You don’t have the time to check up on everything, nor should you if you did.  You have someone reporting to you whose job it is to do this work.  You must assume competence.  If you do not, you’ll harm your relationship with that employee and you’ll run yourself ragged.  Whoever hired these people verified that they were competent.  Unless something changed, they still are.  Feel free to spend some time with your employees trying to understand what they are doing and how they are approaching the problems.  Do this to educate yourself, not to question their work.  With time, you will learn the abilities of those reporting to you and become much more comfortable with their reports.

Becoming a Lead, Pt. 1

At Microsoft, there are two classifications of people:  Individual Contributors and Managers/Leads.  Individual contributors are those who spend most of their time doing the work that makes software spring into existence.  These are the programmers, testers, and program managers that create the products.  Managers and Leads are those who spend a large part of their time making sure everyone else has time to do real work.  Leads are usually those who have a few people reporting to them and Managers are those who have leads or other managers reporting to them.  Those of us who are managers pay attention to schedules, product roadmaps, bug trends, people development, and—most importantly—making sure that our people are not blocked.

 

There comes a time in many careers where a person makes the transition from an individual contributor to a lead.  There are some big differences and not all of them are obvious.  This series of posts will cover many of those aspects.  The things I talk about will be specific to the software industry but should be applicable in any occupation.  Before I start, however, let me give some thoughts on the prerequisites for becoming a good lead.

 

Great leaders are grown, not born.  No one comes out of school ready to be a great lead.  It takes a solid foundation before you can effectively lead.  If you try to lead without that foundation, you’ll end up being more Pointy Haired Boss than Great Leader.  To get a solid foundation, spend some time (several years at least) doing whatever it is you expect to be leading people at.  As this blog is about the software industry, spend several years programming or testing (or both) before trying to lead testers or developers.  Once you become a lead, you will have less direct exposure to the technology.  You’ll need a solid background to understand everything those reporting to you are working on.

 

Not everyone is cut out to be a lead.  I’ve seen too many times when a great developer is forced to become a manager.  What results is often the loss of a good programmer and the creation of a bad manager.  I’m very much with the author of First, Break All the Rules.  One of his basic premises is that people have certain talents and if you don’t have the right talent for a particular job, the best you can be is mediocre.  For instance, I’m not artistically inclined.  I could go to art school and get lots of training, but I’m never going to be a great artist.  Likewise, if you are not naturally a leader, you’ll never make a great one.  With the right talent, and the right training, a person can become a great leader.  Without both, they never will. 

 

How do I tell if someone is a natural leader?  I have a thought experiment I like to apply.  If I put together 3 people on a project and tell them what the goal is but don’t assign any of them roles, by the end of the project one of them will be contributing more to the overall direction than the others.  Someone will be the person designating who works on what.  This is not the bossiest person.  Without a talent for leadership, the person will be seen as pushy and their leadership will be rejected.  The good leader will lead without having to claim the mantle of leadership.  Instead, it will be given to him/her by the others on the team.  It may not be verbalized, but there will be one person the others look to for help making decisions.  That’s the natural leader.

 

I once had a report who claimed he wanted to be a leader.  I gave him responsibility for an area and another person to help him do the work.  A few months later, the helper was doing his own thing.  He was being given no direction.  Needless to say, when this person came to me and asked why I didn’t make him a lead, I just had to point to that incident.  When given the chance to lead, he didn’t take on the role.  Leadership is a behavior, it is not a title.  If you think you want to become a manager, do so because you enjoy leading, not because you want the title or the prestige.

Understanding Networking

In my recent foray into podcasting, I ran across a gem.  It is a 4-part series which explains most of the basics of networking in easy-to-understand terms.  The series is part of what is called Security Now from the guys who do This Week In Tech.  It covers the basics of IP, the difference between TCP and UDP, ethernet, DHCP, subnet masks, etc.  Everything you ever wanted to know about networking.  If you haven't had a chance to read a book or take a class on networking, this is a great introduction to the world of networking that is enveloping all of us.  The whole series takes about 3 1/2 hours.

The episodes of note are:

How the Internet Works, Pt. 1

How the Internet Works, Pt. 2

How LANs Work, Pt. 1

Ethernet Security

(If you haven't tried podcasting yet, give it a shot.  It makes for an informative commute.)