Christopher Collins is a senior software engineer at Capital One, and one of the keynote speakers for 6 December's Jellyfish meetup in London. He explains how a purpose-built tool has taken the mystery out of code contribuition health.
What is your background?
I am a Senior Software Engineer working mostly in Node.js and React. I have been at Capital One for a couple of years, having worked as an engineer and manager both for Amazon and LOVEFiLM. Before that, I worked as a graphic designer for a record label.
That’s quite a shift going from graphic design to frontend development – what brought about that change?
I was working for Sanctuary Records Group in the era where MP3s and iTunes were beginning to take hold. The music industry was starting a decline and I wanted to try something new. I read up about web development, made some free sites for friends and small businesses to build up my portfolio and got my first coding job off that of the back of that.
Are there many overlaps between your old and new lives?
Yes, more in terms of the design aspects. Working in the front end, you need an eye for design and user experience. How designers work with clients is very similar for software engineers.
It’s about a personal project that became something we’ve used at Capital One. We were working on a big project in 2017 that had many of teams working together. I wanted to see the ‘code contribution health’ so I built a tool that took all the pull request data from every repository and visualised it in a way that would be useful to all those teams. The tool is not about the quality of the code, but how the teams contribute to their own code. For example, how many comments given and received, size and age of pull requests.
Have you taken it further?
I’ve presented the tool to our senior leadership, plus demoed it to many different teams. One team has recently moved to one-week sprints and will be using at the tool to help see the impact of the change.
What will Jellyfish attendees get from your presentation?
The presentation itself will explore how the tool can be used to help teams explore their own data. On top of that, I’ll talk about how I wrote and built the tool without using ‘if’ conditions or any npm modules. I hope everyone there will use it as a chance to look at their data differently.