Apr 042015

In the summer of 2013 I had a fantastic internship in Houston, Texas with an oil and gas company called Total. During graduate school my research group would have consortium meetings, where all of our sponsors would send representatives to learn about our research and how it could impact the way they do seismic imaging. After I gave a talk at one of these meetings, I was approached by a research geophysicist who would eventually become my mentor for my internship. I immediately brought this to the attention of my supervisor who thought it would be a great experience for me.

When I arrived in Houston I began working on taking a Matlab library and rewriting it in Fortran. It was certainly challenging, but I felt like I was constantly progressing. This was an extremely good feeling, as I would struggle with math problems for weeks on end and get no where. Each week I would finish a different unit of my project and at the end I felt quite accomplished. Both myself and my mentor were happy with what I had accomplished with my time at Total. I took this renewed energy back to Vancouver and finished my thesis!

However, knowing what I know now, there are plenty of things that I would do differently in terms of development I did during my internship:

  1. Commit code more often than not. I remember there was this one particular Friday where I started making changes to some code and saved it locally, but then Eclipse crashed and I couldn’t “undo” my changes back to something that I knew worked. I ended up checking out the last revision because something wouldn’t compile anymore and I couldn’t figure out why.
  2. Write more unit and integration tests! I did do system tests to make sure the output I got from MATLAB was the same that I got in Fortran. I knew very little about testing at that time and I wouldn’t have even known what to look for in terms of a Fortran unit testing framework.
  3. Use better design patterns. I ended up having to duplicate code to make everything work for complex variables. Had I used either better abstraction/design or even templates in C++, this could have been avoided.

I don’t “struggle” with the above 3 anymore, but rather they are something I constantly try to think about while I develop. If I’m on my own branch I even feel comfortable committing code that doesn’t compile or where tests fail, I can always go backwards in history if I need to but if I lose code then it’s gone forever. What I do struggle with is knowing the appropriate designs and sometimes the appropriate way to mock parts of a system that I can’t control. But that comes with practice 🙂