I used to be part of a big team. Then I got put on a big assignment that lasted over a year. I was on a much smaller sub-team. The new development is over. That project is in maintenance mode. I have been tagged to do general maintenance of that project. My old team leader got wind of that. He assigned me a high priority maintenance task. Unfortunately it dealt with a code base I don't work with on a regular basis.
So I dug in. Traced how the data was getting loaded. I asked the ETL team why there was data missing from a table they populate. The only answer I got was that was what they received. Not too enlightening. The guidance I got was to try to find the data somewhere else. Luckily the analysts had a lead on a source where I could find the data.
With the new source in my hand, the fix should be easy, right? Nope. I got to modify this big system. I decided to just come up with a hypothesis of how I could achieve this. Then I went to research how that could be done. Halfway through, I found out that I was barking up the wrong tree for half of the solution. Okay. Time to regroup.
Once I figured out where I needed to make the changes, I found that I had the wrong version of code to start with. I was working with something that was two years old. I backed up and downloaded all the code from our source code repository. Was able to match up the version of code that was most recently deployed to production. Now I am cooking with gas.
The are a couple good lessons here. Sometimes you got to try something out when you don't know all the answers. Also, by doing some hard work, you can go figure stuff out for yourself without having to bother other busy people. Finally I learned that there is nothing like making changes, running the code, and seeing the results work. Very satisfying.
Reproducing a Race Condition
-
We have a job at work that runs every Wednesday night. All of a sudden, it
aborted the last 2 weeks. This caused some critical data to be late. The
main ...