3 long days on site and unfinished business
I have been out on site for 3 days and it certainly was 3 long days.
It can be tricky when you are out on a clients site, I tend to feel I have to justify all of my actions. In reality the customers probably really don't care how I do what ever it is I have to do as long as it gets done.
I am always conscious of trying to pass on the knowledge in a
"Give a man a fish, he can feed his family for a day day, teach him how to fish and he can feed his family forever"
Although I try to show the user what I'm doing, it's not just because I am lazy and hope they will be able to do it for themselves next time. This of course can have it's draw backs as well because "with great power comes great responsibility" and the power to create an even trickier bug. I have seen customers really bend the rules of the software we have supplied them but the same users also did a lot of the donkey work in narrowing the bugs down for you as well.
I think it's important not to just show the customer/user what you are doing but why you are doing it, the hardest part of using other peoples software is working out how all the pieces fit together.
Back to the story. I was out on site trying to upgrade their software, well upgrade everything, version of java, version of Tomcat and all the software that we supply. I managed to get into a right pickle. The installation of the software went fine, the configuring of my employers software went horribley, problem after problem. Usually I try and keep to keep a slow methodical systematic approach and tick off what isn't causing the bug as well as things that our. I think in the end I suffered a bit of from computer sickness and couldn't really see the "woods from the tree's" I had been working at it for so long.
I had a lot of errors and the error messages I were getting were real red herrings. In the end I had to roll back to the numerous backups I made. Funnily enough just as I was packing up the solution struck me but I didn't have quite enough time to try out my solution, so first thing tomorrow I have some un finished business to sort out. This problem is certainly person now and I am determined to slaughter the beast. It was an infamous missing jar problem, I had two system - the old working version and the new not working version.
To make things a bit more interesting I was working on a Linux machine. I am pretty rubbish with Linux and all the command line typing. The worst bit is trying to remember the directory structure in my head. This time I found that Linux has got an GUI front end called Konquer. It was well cool, I could see directories, edit files (when I had the right user). I struggled copying and pasting values for some reason and had no idea how to start and stop Tomcat but found that dragging the bat files onto a command line type screen did the trick.
Three days of wearing a shirt and tie has taken it's toll on me, no more neck stranglers for a while.
even though I have spent 3 days on the problem, I am now feeling eager to finish the job, the plan is go into work, try my solution and then get on the phone to tell the customer what to do
It can be tricky when you are out on a clients site, I tend to feel I have to justify all of my actions. In reality the customers probably really don't care how I do what ever it is I have to do as long as it gets done.
I am always conscious of trying to pass on the knowledge in a
"Give a man a fish, he can feed his family for a day day, teach him how to fish and he can feed his family forever"
Although I try to show the user what I'm doing, it's not just because I am lazy and hope they will be able to do it for themselves next time. This of course can have it's draw backs as well because "with great power comes great responsibility" and the power to create an even trickier bug. I have seen customers really bend the rules of the software we have supplied them but the same users also did a lot of the donkey work in narrowing the bugs down for you as well.
I think it's important not to just show the customer/user what you are doing but why you are doing it, the hardest part of using other peoples software is working out how all the pieces fit together.
Back to the story. I was out on site trying to upgrade their software, well upgrade everything, version of java, version of Tomcat and all the software that we supply. I managed to get into a right pickle. The installation of the software went fine, the configuring of my employers software went horribley, problem after problem. Usually I try and keep to keep a slow methodical systematic approach and tick off what isn't causing the bug as well as things that our. I think in the end I suffered a bit of from computer sickness and couldn't really see the "woods from the tree's" I had been working at it for so long.
I had a lot of errors and the error messages I were getting were real red herrings. In the end I had to roll back to the numerous backups I made. Funnily enough just as I was packing up the solution struck me but I didn't have quite enough time to try out my solution, so first thing tomorrow I have some un finished business to sort out. This problem is certainly person now and I am determined to slaughter the beast. It was an infamous missing jar problem, I had two system - the old working version and the new not working version.
To make things a bit more interesting I was working on a Linux machine. I am pretty rubbish with Linux and all the command line typing. The worst bit is trying to remember the directory structure in my head. This time I found that Linux has got an GUI front end called Konquer. It was well cool, I could see directories, edit files (when I had the right user). I struggled copying and pasting values for some reason and had no idea how to start and stop Tomcat but found that dragging the bat files onto a command line type screen did the trick.
Three days of wearing a shirt and tie has taken it's toll on me, no more neck stranglers for a while.
even though I have spent 3 days on the problem, I am now feeling eager to finish the job, the plan is go into work, try my solution and then get on the phone to tell the customer what to do
0 Comments:
Post a Comment
<< Home