Week 12 : Dell EMC

Posted on Aug. 11, 2017

Only two weeks left after this. One of my team members is working remotely from a different country, and another is taking a vacation. So with only James left on my team, it certainly feels like the internship is winding down. The most interesting part of this week was the new code that I got to play with. I used preprocessor defines, mutexes, and more parts of the boost library. All of it was a good learning experience and taught me a bit about computer science too. At least I will now consider how threads interact with the same objects.

What I did

For 3 days of this week, my Dev VM was down, so I was unable to work on the codebase for most of the week. I still pushed out my user story and put it up for code review. Most of the week was investigating the management objects that team has been using to keep track of the data and properties of various components of the storage array.


Object oriented programming is most useful in a team environment where there are multiple programmers. When creating an object, all methods and data members should be related to the object’s name. In object oriented programming done by the books, objects are pretty isolated, and should only be passed data, and return it through public methods. This isn’t always the case in practice, but is a fair assumption.

Looking at an objects’ methods allow an API of sorts within the program. Typically the function names are descriptive, and related to getting, or setting information in the object. Most of the time the functions will only modify the data of the object and nothing more. When looking at a standalone function, the name may not be as clear as an object’s method. Looking at the parameters is a good way to gauge what is being modified, but isn’t always the case. I may have to deep dive the code of a standalone function, rather than glancing over an object’s code to get a sense of what it does.

Object orientation can be ambiguous, and a good design should be agreed upon by the team. There are infinite ways to write an object, and some implementations are better than others. Collaborating to ensure consistency, and minimal redundancy is essential when working on big objects or key interfaces together. Establishing this principal and following it will reduce overlapping code.

Thread safety is a pain, but it is sometimes necessary. I had heard of multithreading before, but have not used it, which is a big distinction. For this job, I’ve had to work with multiple threads and many objects that need to be thread safe. So I have learned about mutexs, locks, and guards.

Somethings are simply out of my hands. The test I have been recently working on is very slow, and runs into performance issues from making many calls to a storage array. There is not much I can do when the array forces these calls to be serialized, and non-overlapping. I have had to let it go, and accept the performance deficit, because I cannot change the way the storage array works.

Large corporations have many resources. Today at lunch I took a long walk around the entire complex. There were basketball courts, volleyball nets, and a parking garage that I had not seen before. It is excellent to see so many employee resources here.


This is the week of the 7th International DotA 2 tournament. For those that do not know, DotA 2 is a video game where a 5 player team faces another 5 player team in a strategy game that normally last about 45 minutes. This tournament has a 24 million dollar prize pool, meaning the first place prize is 10 million dollars. It is an exciting tournament, and one of my favorite weeks of the year.

Return to Blog Home