Jan 032016

Well there it goes, my first year of blogging. It was certainly a bit on and off earlier in the year, I wasn’t entirely sure what I was getting into or what I was going to talk about. All I knew is that I wanted to have a public place to share my thoughts and interesting pieces of literature or code.

I didn’t really start to kick it into gear until I listened to a Ruby Rogues Podcast about marketing yourself as a software developer. I had never really thought about marketing myself to be honest, it’s something I think most scientists cringe about. “Leave it to the business majors.”, is what I’m sure most of my university colleagues would say. It’s an interesting discussion if you have an hour to burn:


The Ruby Rogue crew bring up a very interesting point throughout the discussion on if we choose “not to play the game”. The act of not participating is an action in itself. Though it was never my goal when I started posting, it’s been one portion of motivation to contribute more often rather than let it be something that collects dust.

In any case, for anyone who managed to find their way on here and found something useful. Woohoo! To cap it off, here is a graph of my server traffic over the last year.




So really only HTTP traffic. My webserver generated this image so I couldn’t remove the useless data. Anyway, I’m optimistic for a continued upward trend!

Nov 252015

If you are passionate about your work, your day to day duties in your job can be incredibly pleasant. I personally love being able to code daily, whether it be writing new features, bug fixing, or refactoring. However, all of those tasks become stressful when under pressure. If you’re not in a management role, then you likely have very little control on how projects are managed and how estimates are given. If your team doesn’t have a consistent metric for measuring complexity of feature requests or bug fixes, estimates can be hard if not impossible to give. There is only so many factors we can control, but part of being a professional is identifying those factors. Here is a couple that have become important to me when coding under pressure.

1. Knowing your limits

It’s easy to make mistakes when sleep deprived and mentally exhausted. Working long hours day after day can ultimately be counter productive. Make sure you find a balance or you will burn out. I’ve always found it difficult to “turn off” when a problem hasn’t been solved. Though many times it’s when I stop thinking about a problem that it magically becomes clear what needs to be done.

2. Time management

When faced with a list of things that need to be done, proper allocation of your time is important. For example, performance optimization. In general, I’m speaking of code that sits outside of the realm of high performance computing. Would you rather have something that works slowly and gives you the right answer, or works faster but gives you the wrong answer? Don’t get bogged down trying to optimise if you don’t have time. Note that optimise later doesn’t mean write clean code later, you should always strive to write clean code even if it’s not an efficient implementation.

3. Personal velocity

Part of writing software is estimating how long it will take you. Even if your team doesn’t use velocities, you can still gather data from tracking system and version control software to calculate your own personal velocity. Brian Tarbox and Heather Mardis wrote a thoughtful post about this, “Retrospective Velocity, When Will This Project Be Done?“. If your lead comes to you with a project and a deadline, you should have a quantitative way of estimating how long it will take you and inform them whether or not it is possible and find a compromise in the latter scenario.

Start small, pick something you have control of in your development environment and try to improve it. Whether it be finding a better way to juggle work and life or finding a balance between design and implementation.

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 🙂

Dec 312014


As I’m sure you are aware of by this time, my name is Brock Hargreaves. I’m currently employed as a software test engineer and have been jumping in and out of many different libraries and technologies. I’m exposed daily to Python, C++, Ruby, XML, and more recently QT.

I hope to share many of the “aha” moments I’ve had in these various technologies where the solutions are a bit quirky and review various podcasts and literature. I’ll track my progress, failures, triumphs and experiences I have in software development and attempt to provide something useful in the process!

Some posts may be technical in nature, please don’t hesitate to ask questions! I also love constructive criticism. If you think there is a better way to do something or think I’m insane for approaching a problem in a certain way then by all means let me know! I constantly ask for code reviews from my colleagues, I’m eager to know if they would approach it differently and how I might be able to improve my code.

Happy reading!