This is my second to last week, and things have been strange. I ate lunch with one other person most of the time, as interns have been leaving. It feels like I have regressed to a state where it was like the second week I was here as far as social goes. It is strange. My team is not as present as before due to one being on vacation, and another person in a different time zone. So I can only communicate with one person at a time.
What I did
This week has been a mix of taking a long time wrapping up the two large user stories that I had begun two weeks ago. Other than that, there have issues trickling down through testing. I have been regression testing the code changes I have made, nearly all week. I found two bugs, on in the way that DAQ finds disks, and another mysterious one that came in Friday. This bug put down the array. I’ve filed a bug report, so we will see where that goes.
Working alone isn’t as great as imagined. In school, working alone is simple, quick, and easy. Ideas and code simply flow from brain to keyboard without any intermittent human communication. Also knowing the entirety of the school project being worked on is nice. In the workplace though, working alone isn’t so great. Today it was hard to get feedback, recommendations, or conversation due to many team members being absent. I have totally gone days without communicating to my team, apart from scrums, even when they were here. But this is a sort of comfort that comes with knowing someone with vast experiences and skills is available to talk to.
When using a tool, library, or OS with your code, it is your burden to prove bugs. For example recent a team member believes that the kernel may be at fault for a bug he has been tracking for over a month. He has to log, prove, and present the bug back to the kernel team in order for it to be investigated.
When using protected version control and continuous integration, it is advantageous to separate merges into topics, despite the extra time required. This will improve documentation, and available history of code. Very often I have found a small bug in already merged code that I want to quickly fix. I do not want to create a new branch, file documentation, and get the code approved. Unfortunately it is what I should do, and I go about the process the long way rather than rolling the fix into a current pull request.
I learned a bit more about lambda calculus. I was running a long test, and thought it to be a fun thing to get a handle on. It’s not really related to the job. I have used anonymous functions whilst working here, but that is a derivative from lambda calculus, not a direct example.
Today while working on a user story, I realized the data flow felt wrong. I was doing too many traversals of a map, storage nearly repeat data, and looking up data in strange ways. I had to take a step back to see what I had been over complicating, and missing. Once I had done that it was easier to see a simpler solution that I had overlooked earlier. Minimizing the amount of stored data, and the number of operations is always better to have in a program. Premature optimization may be the root of all evil according to Donald Knuth, but using a poor data structure is a much worse pain to code around later.
This week not much has happened. I washed my car. Played in the Dell EMC soccer league. We made it into playoffs next week, which is exciting. That’s just about it though. For those that are interested, Rise of the Tomb Raider was a good follow up to the Tomb Raider reboot game. Definitely worth the money, especially on sale.