What did you do before Diffblue?
I studied Discrete Maths (a cross between maths and computer science) at Warwick University. I then worked in the video games industry as a gameplay programmer. I worked at two companies, in the first instance releasing a game called Strike Suit Zero, then with one other person attempting to make a sailing adventure game.
I joined Diffblue in October 2016 after seeing an advert on Stack Overflow. Being able to automatically generate unit tests sounded almost too good to be true, so I was excited to work on it.
I had tried writing unit tests myself and that was hard enough, so I thought it would have been even harder for a computer to do and it intrigued me. It seemed like an unsolvable problem which I was interested in solving.
I was hired as a QA/developer, and a year later we did a big reorganization and I ended up as a team lead. I’ve seen Diffblue grow from being about 8 of us in the corner of a shared office, to the 70+ people we have now in our own awesome office.
Could you tell us a bit about your role at Diffblue?
I’m a team lead of one of the C++ teams that works on the test generation engine used by Diffblue Cover. This role involves, in almost equal parts, programming, working with the product owner to prioritize what we work on, and most importantly, helping my team members grow as developers and QA engineers.
Being a team lead is an entirely new experience to me but one that I really enjoy. Diffblue provided me with support both through my line manager and with external training. That said, I’m still learning every day.
The technical work is currently focused around making the generated tests look like a human wrote them. This is an interesting problem to tackle, and very rewarding when you see tests that previously looked “generated” and then start to look like a regular test.
What do you think makes Diffblue unique?
The thing that stands out for me at Diffblue is the accountability at all levels. Junior developers are given room to take on high-impact and challenging projects, with chances to experiment and opportunities to fail quickly and learn from it. I think this open atmosphere is part of why we have such a great office. The people who are working in it every day were consulted as the office designs were drawn up, so we have the things we need: white boards on every wall, an open lunch area where we can all eat together and little individual working pods for people who need some quiet working time.
I’m also proud to work for a company that provides opportunities to people who are less readily represented in the tech industry, through things like paid internships, apprenticeship schemes and welcoming people from different educational and technical backgrounds.
What’s the most challenging part of developing effective tools and products?
I think it boils down to the fact that it’s hard to know what the solution looks like until you find it. Being technical is not the trick (anyone could become a technical person); the trick is identifying the technical problem that needs to be solved and working out which things are going to actually improve the software that we make. Take Deliveroo: at first it doesn’t seem like there are any technical barriers to restaurants setting up their own delivery network, but it’s been hugely successful because it solved a problem people didn’t realize existed and was designed well.