Today was Wednesday, so I worked at home. It breaks the week up a bit to have a commuting-free day in the middle of the week, and it can be good to be away from the hustle and bustle of the office.
I’m not completely free of the office as my phone is forwarded to my home phone number and of course my email is still there, and today I had a number of phone calls and the usual stream of emails, but somehow the interruptions seem to take less time when there’s nobody else around me to get involved in them.
I wouldn’t want to work at home all the time as I like the interaction with colleagues that I get in the office. Working in a support team, I find that I’m much more aware of what’s going on if I’m mostly in the thick of it; and I also enjoy brainstorming with Dave, who sits at the next desk.
However, for one day a week, it’s nice to be a little more distant from all of that; and today I felt that I got a good day’s work done. I did various bits and pieces this morning and then sat down to complete the code reviews on my task list. They’d been waiting for a couple of days, so I really needed to get to them. One was easy to review and pass, while the other had to go back to the developer for a bit more work, and with a recommendation that maybe the designer needed to take a look, too.
This afternoon I had a call from a colleague who thought that if anyone knew whether there was a data fix in existence for a particular problem, it would be me, and he was right! There was a fix, and he asked me to instal it for him, which I did.
Then I settled down to look at another problem which has been around for a while, but which I hadn’t looked at before. I think I approached it from a slightly different direction from the previous investigator, and I cracked it! Investigating is a difficult skill to teach. Some problems are well defined and you can put together a set of tests to run which will usually track down the cause of the problem, but other problems come with no clear direction to investigate from, and I chose to slant my investigation differently from the previous investigator. Maybe I did it because I knew what the previous investigator had done without arriving at a solution, or maybe I just chose my approach for other reasons which aren’t entirely clear even to me.
Anyway, I found that looking at the history of how the data had already behaved worked for me, where the approach of running the data and observing it hadn’t worked for the last investigator. Maybe I chose my approach simply because I am good at delving around in iSeries journals. My approach gave me the name of the program which was setting on the flag being investigated. It was the program I thought it would be, but it was nice to have confirmation, because then I could concentrate on that program, confident that it probably contained the key to the investigation.
It turned out to be one of those evil two-step processes, where the program ran the first time and set the flag on seemingly randomly, and then on the second time through it reported the error that I was searching for. Then it was just a matter of determining how the flag was set on, and there were only two choices. A quick look through an error report soon told me which choice was the right one, and armed with that information, I was able to arrive at why the flag got set on. Once I knew why, it wasn’t random at all, but there were good sound reasons for the flag being set on just occasionally.
All in all, it was a satisfying day’s work and I was able to tick a number of things off from my task list.
Best of all, when I packed up at the end of the day, I didn’t have a 30+ mile drive along busy roads, but just a short walk across the hallway and I was on my own time!