Versatile programmers

I work as a programmer for a small consultingware ISV. Since we're small, everyone has to be flexible and take on roles outside their primary area from time to time.

Programmers tend to be higher up the skills chain than some others in an ISV. As a result we have the ability to be reassigned to a number of non-programming roles at the same skill level or lower. These tasks could include in no particular order

QA testing
creating product documentation
creating online help files
sales engineering
professional services
producing training materials
delivering live training sessions
level 1 and 2 tech support
consulting
providing a reassuring presence on a customer site
creating content to demonstrate at trade shows
attending trade shows


In general there is little to no transferrance the other way into the core programming team. This is because it is generally difficult to impossible to quickly reposition someone up the skills chain instead of down it. For example it would not be realistic to try to cold reassign a tech writer or level 1 tech support rep from their usual role into the programming group for a couple of weeks to help the product team meet an end of month deadline. They don't have the required skills and experience to function effectively as programmers. So the standing programming team can only lose resources, and never gains them.

In larger companies, it should be possible to properly separate the programmers from the other roles. The other teams are big enough to be properly staffed and are expected to fill in their own shortfalls using their own means. In a smaller company we have to be more flexible and cannot just isolate the programmers from having to occasionally do non-programming tasks. Especially in consultingware, which is about smaller numbers of big sales, we have to be responsive to sales opportunities. When you're close to a big sale you do what you have to to make that sale. The success of the products and the company depends on it. Sometimes the distinction between the core product and a customization can be somewhat blurry. If the programmers can help make the difference in a short term big opportunity then that's worth doing.

In general it's not economical to reassign programmers to other roles since programmers tend to cost more than the roles they are taking on. So assigning a programmer who averages a loaded $100K a year to do tech writing or level 1 tech support than can be adequately staffed at a loaded $50K a year isn't cost effective in the long term.

There is a hidden cost to reassigning programmers. The cost is that the programmers cannot advance the core products when they are doing other tasks. At Microsoft there is a really good saying among the programmers: "If you're not writing code then what are you doing?" That really focuses the mind on what the programmers are there for. What's more important that a programmer should be doing than creating source code. Every day a programmer spends not writing code is a loss for the products he would otherwise be advancing. This cost is not immediately apparent, and may seem negligible in the short term. However over time it can be extremely costly if the core product becomes uncompetitive in the marketplace.

So the programmers immediate manager, product management and the company in general must be educated to understand the potential costs of reassigning programmers. In general requests for programmer reassignment should be carefully reviewed and challenged, and rejected if a compelling business case cannot be made for it.

In a dysfunctional environment, the programming team would be like a buffet table where any other group can help themselves at any time to a warm body or two to cover over a local shortfall. If you have a small programming team to begin with and you've got one person doing phone/email tech support, another one out of town at a trade show, another on another continent holding hands on a customer site, another helping set up a sales demo, two others over helping out with a QA cycle, and someone else conducting training sessions then you basically have nobody working on the actual products which will then be at risk of becoming uncompetitive. That's an extreme example but you have to be vigilant to keep the programmers writing code.

A use for Internet Explorer (XML viewer)

Normally I have little use for Internet Explorer, except at annoying sites that only work with IE. I switched to Firefox years ago and have never regretted it. Hello tabs!

However a smart guy at work showed me a handy thing that IE is actually useful for. IE does a pretty good job of rendering raw XML. It shows it in a nicely formatted, color coded way where you can open and close the branches to narrow focus to a specific area.

This is useful for me because I deal with SOAP a lot at work on the server side. Clients visiting the internal web service tend to be shaky and get themselves into a bad state, and do strange things that cause problems. We necessarily log all of the SOAP/XML that we send and receive. When a problem occurs it is very useful to see the exact SOAP content that was sent or received on the wire.

Now viewing SOAP content can be a pain. On our side we use Tomcat and Xerces. While this is robust and reliable, it also generates the XML all on one line. This is fine for a computer to process but hard for a human to read. Previously I had to copy and paste from the log file into a text editor and insert line breaks manually to see the actual valid XML/SOAP we sent that the client was having problems with.

Using IE, there's a much faster, easier and better way.

Create a document on your desktop called t.xml.
Make sure your settings have IE as the default application for .xml files.
Right click on t.xml and open using a text editor.
Replace the existing t.xml content with the XML copied from the log file.
Save t.xml and close.

Then just double click t.xml on your desktop and it comes up nicely formatted in IE with all the attributes and namespaces and everything right there. This is very handy and a real time saver.