This week started off with me being assigned to the data team to help them with their problems. As I sat with them and started to learn the technologies they used to do their jobs, I began to understand that a major component of data retrieval and parsing is handled by threads, as they increase the efficiency of the code, and make the operations much faster. This led me to spend some time on my own, learning how threads function. Chip picked up on this, and offered to teach all of us how threading and concurrency work in java. He showed us this really interesting sorting algorithm called SleepSort (look it up, it’s hilarious), and used it to teach us how threads work.

After all the other interns had gone to work on their individual projects, Chip sat down with me, and we decided to go through some old code that StockCharts was using, and find ways to refactor it by possible using threading, but with the main goal of making the code more readable and efficient. We found a particularly interesting bit of code that already used threading, and decided to look into it and try and make it more efficient. Expecting to not have to work on it for too much time, we sat down, ready to refactor.

The code, we learned, wasn’t something that could be cleaned up in a few minutes. Chip and I sat there for hours, trying to clean up the code and make it more readable and efficient. There were many parts of the code that weren’t very important, and could be done better. There were also parts of the code that were completely unnecessary. One such part of the code was a synchronized method, which didn’t seem to have any practical purpose at all except for keeping better logs. Synchronized methods force threads to only be able to execute the method one at a time, and the next thread is only able to access it once the first thread is completely done with it. This is to prevent concurrency issues. Now this function. while helpful, also highly cuts down on the benefits that would be received by using threads, as this would nullify the performance benefits that came with the threads, especially if it was used for something non-essential.

We found a few such methods, that were synchronized even though they had no reason to be. We spent the whole afternoon cleaning up the code, and when we were done, it was supremely exciting to see the difference we had made in readability, extensibility, and efficiency.

This tale has a realistic (which is to say, sad) end – we couldn’t get the code to run for a while, as we had to fix all the other classes and packages that were dependent on this bit of code so that they were able to run it properly. The code eventually ended up working, and it was a happy day for all of us – well, those of us who worked on it, at least. The other people didn’t seem to share our level of enthusiasm about this.