Two years of lessons learned.

It's been a while since I've posted here, I'm not quite ready to jump back into pushing deployment stuff again, I have had other things on my plate (vacation being one of them) and am finding less time to tackle the interesting questions that are coming through.

That said, I do want to keep up the habit of posting, so I'm going to switch gears a bit and talk about something a little more general than VSTO Deployment.  Yesterday marks 2 years working for Microsoft, working in the software industry and working in the testing field.  Here are some of the things I have learned in those two years that I think may interest you:

On Chocolate:

Having a candy dish full of chocolate is a great way to learn a lot of interesting things with very little effort.  I maintain my candy dish religiously and it's turned out to be very fortuitous.  Every time someone comes to "snatch" a piece I can often engage them long enough to learn something interesting from them.  Sometimes it is programming tips and other times it is just basic information about what they're working on. 

Another lesson with this:  don't eat the chocolate yourself, it's just not as good if it's not provided by someone else.

On Testing in General:

When I started working my belief was that a tester's goal was to find bugs.  In some cases this is true, but here at Microsoft, my job is to make the product better.  With this in mind a lot of what I focus on is not so much "finding bugs" but at "understanding" the product (and writing bugs when the understanding reveals deficiencies from what the product does and what we say it does or want it do ).  Part of this understanding is knowing what customers need which is why I am here writing this, hoping that should you be reading you'll drop me feedback on how you're using "my product". 

On Automation:

I believe software testing as an industry and automation in particular are still in an infant stage.  What I have seen internally and what I have heard about what happens outside of Microsoft indicates to me there is still a lot of work to be done and learned in this space.  With that in mind, I believe the goals of Automation are often counter to what automation actually provides.  Automation doesn't find bugs during development but rather forms a sort of rigid documented (in code) expectation of what the product is that is easily evaluated and repeated.   I'm not saying that Automation isn't important (quite the opposite) but rather often its value is not fully understood.

Automation is important especially if you want your product to work outside of the context in which it is initially written.  (We will sometimes find bugs around things like localization/globalization, though automation is only one step.)

The more "customer scenario" focused your automation is, the more likely it is to move forward and be understandable.  It is very easy for me to write automation that checks that the value within a file is the same as the value specified in a text box within the product, but the value of that test is much harder to express and the test is more likely to be broken as the product changes. However, if I tell you my test installs an add-in that was published to a web server, it's clear to see how the test is "relevant" to how the product works and it also is more likely to move forward as the product does.

Automation writers may know more about complex problems than product developers:  Automation often must be product, context and language resilient.   If your product is potentially going to have backwards and forwards version resiliency, you might ask your automation writers if they've tackled the problem before and what they've specifically learned about it.

On Development:

Be intentional.  When you are writing something new:  draw a picture or at least tell someone about your design.   Designing something before writing it will always result in something better then something you simply "piece together".

Use intellisense comments when available.

Use comments to give context and meaning to your code.

Avoid using TODO:,  TODO is a form of procrastination that can often cost you more than simply doing the work initially.  If you absolutely can't implement something at that moment, instead of just a "TODO:",  leave a (large) block comment at the entry point for what needs to be done and throw a not-implemented exception (preferably with something to help indicate what needs to be implemented).

Own your code but expect that you may be hit by a bus tomorrow.  This means that when you check code into source control you expect that someone will be able to pick up where you left off and achieve your same (end) goals.

On working in general:

Be open to other people's interests.  It's a lot easier to get cooperation from someone who you've helped than to ask for help from someone with a promise of future help.

Never eat lunch alone.

Be fearless even in the face of failure:  failing is an opportunity to learn and improve (don't forget to grasp it).

Thanks for reading.

Kris

[edited 5/27/08:  Minor typos and sentence clarification]