This year we are running an IT Graduate program here at Net-a-Porter. The four graduates are doing three-month rotations with various teams, getting experience with many aspects of our business. I volunteered to give them a quick introduction to shell programming and regular expressions. Killing two birds with one stone, I have adapted the shell programming part of that session into this blog post — the regular expressions part of the workshop will be the topic of a future post.
One of our programs was leaking memory. Not much, but enough that Tech Ops were not going to allow us to put it into production. Fair enough, I wouldn’t allow it either, if I were on-call.
So I did the obvious: started looking for the leak. This is not as easy as I’d like.
When I started in the Labs team at Net-a-Porter, the job description contained the following desired trait:
Candidate is unafraid to fail, but fails fast
This phrase was new to me at the time and it certainly wasn’t something I could say I was actively doing, but three years later failing fast is not only something I strive to do as a software developer, but something I look to do in aspects of my day-to-day life.
So what does this phrase actually mean? The phrase has two parts; let’s look at each of them.
We have a large automatic test suite here at Net-a-Porter, and that test suite gets run automatically whenever we check code changes in to our source code repository. Of course, a developer will run the suite manually before checking in changes, but it’s nice for the rest of the team to be able to see that a particular change hasn’t broken anything.
Occasionally, the test suite will flag problems that weren’t introduced with the most recent code change. This can get frustrating for the poor developer who gets the blame for breaking something that she didn’t touch. So when we find strange problems like this, we try to fix them; this is how we fixed one this morning.