News on the job front

Today, I took my first support call. I'd been doing support on and off for the past month, but I'd really just been handed tasks..."create this", "add this", or "look here and find out why this program is doing this". However, the person I'm taking over for was out sick today, so I got to take my first call early this morning.

It's all part of the master plan my boss has set up. When I was hired, I was brought on to update a system that serves to keep the Department of Education up to date on what's going in with a certain department in each school(note the lack of specificity...I'm trying to be able to blog about work without giving too much information out). Previously they sent a file once a day to the DOE, but now the DOE is updating their system to allow real time transmission using XML. So, now each time a student's record is saved, an xml transmission is made. That's why I'm there.

I'm taking the old system and adding the functionality to allow for real-time updates. I'll be finished modifying the program to the new standard the DOE has set up, and will begin working with the XML stuff early next week I assume.

It's a complicated situation, being a programmer that also provides customer support. You're expected to keep up with ongoing projects, all the while answering phone calls and fixing bugs that may pop up, or even just answering non-technical questions about how to use your program. I guess that's the downside... a big one. The programmers aren't free to take on large projects as part of the product, or fully advance the product with new features. They're being slown (is that even really a word?) down by a constant barrage of phone calls.

However, I think that for the company that utilizes their programmers this way, the product will be a more "user-needs accurate" program. The users are in direct contact with the company who develops the software, so issues in usability, possible enhancements and a few other areas are improved. This is all in addition to the fact that a user who calls in knows they're going to speak to the person who actually wrote (or has an understanding of the code of) the program in question. Those are good things for the product.

I hope to be in the position to make a decision like this for my own company one day. I'm looking for some good software opportunities down the line... and anything I can tackle now too.