Software Quality Engineer
I am currently working as a Software Quality Engineer 2 at Capital One, working in the Customer Domain Services team as part of the Platform Services group.
We have recently launched a new Online Account System that our customers see to self-serve when visiting our site, which has been part of a year-long effort to insource the platform. Our current focus is building the Identity and Access Management Service using an off-the-shelf solution which requires a large amount of configuration. For this, we’ve started using Chef to manage this configuration, as well as creating Java additions to the identity solution in order to extend it for custom functionality.
I’ve found this an incredibly exciting time, being able to take my experience with performing more of a “build it, support it model”, which is encouraged by the DevOps culture that Capital One practices internally. This gives us, the developers, the understanding of how to get our project from local development through to production, as well as setting up CI/CD pipelines as well as gated promotions for artefacts via Jenkins. This experience has been really useful, and has exposed me to tools such as Chef, which I am now personally utilising for my own infrastructure needs, and am championing both internally and out. Additionally, I’ve been able to work in my first Agile software development team, and have been able to experience Test Driven Development and Sprints in a real world situation.
My move into Quality Engineering is a great opportunity to learn some more about the testing side of the roles, despite being in a cross-functional teams where the two roles are blurred, and will hopefully give me the chance to work around more of the core business to give me experience of how Capital One truly works.
In August 2016 graduated from the University of Nottingham with a First in Computer Science. I spent a year placement at Intel between my second and third year, where I worked in the Developer Relation Division, working on a large UK Android tablet project, and playing with Intel Realsense.
For my final year dissertation, I worked on ‘Evaluating Application Sandbox Systems on Linux’, which aims to provide permissions for Linux packages, focussing on protection of privacy.
I have always enjoyed teaching people; from GCSE my Computing teachers often told me that I should pursue a career in teaching, as I have always taken pleasure in the ability to help others. This has continued into my second year at University, where I applied to the Guru scheme, which was a team of hand-selected students to provide mentoring for first-year students, and aiding them with academic issues where required.
In addition, I co-organised the first Hacksoc Introduction to Programming sessions, which took students with no prior programming knowledge and brought them to the level of learning how to develop Android apps. After returning from my year at Intel, I decided that this was not the best course of action; the knowledge needed was vast, and required too much work to teach the fundamentals of programming through Java, and then leading into Android programming, all within one term. Instead, I decided that we would teach programming through Python, as a beginner-friendly language, with the final goal of learning Flask, the microwebframework. Over the autumn term in 2015, I found this to be an extremely effective course of action, and have had great feedback on the sessions.
If you have to repeat a task more than twice, you need to automate it
One of the best things about being a programmer is that I have the ability to automate the repetitive tasks that I’d rather not continually do. Whether this is rerunning my tests as soon as a source file has changed, or filling out a form that little bit quicker, I’ll automate it. By automating these small tasks, it means I get to spend more time on the important things, like actually building cool things.
Working quite a lot on the command line, I have had experience writing Bash one-liners, and automating a lot of tasks via Bash (or Python) scripts.
However, I have recently been working with Chef and Ansible for configuration management. My experience with Chef at Capital One has given me the experience to start using it for my own infrastructure configuration.
I regularly participate in hackathons, where I love spending the weekend learning something new and building something awesome. I don’t always have a finished project to show for it, but I really enjoy the learning process itself.
I have found recently that I have been taking more of a teaching role, teaming up with less experienced hackers, and helping them with learning something new, than building something myself. On the whole, this provides me with a way to test my own knowledge, and to also give back to the community.
Since my second year of university, I have enjoyed participating in ACM-style programming competitions. These have been useful not just for the ability to expand my problem solving skills, but also for the chance to learn C++ in much more depth, exposing me to the ins and outs of the C++ Standard Library.
I’ve recently started using a TDD approach to automate testing of problems, which allows me to run my tests on each file save. The rapid method in which I am able to increment my solution allows me to more quickly tackle the problem, and lets me focus on implementing solutions instead of being bogged down by working out the best method of testing.
For the past few years, I have been developing my skills as a sysadmin, by hosting a web server that provides websites for a few clients that I developed websites for.
My server skills were built upon further when I was working at Intel, and was tasked with setting up an internal server in which to host files, and run Android builds on.
As part of my work, I have also been working with Continuous Integration and Continuous Deployment tools, such as setting up the HackNotts site with Travis-CI which deployed to Amazon S3, or Capistrano as a deploy tool for the Nottingham Women in Tech conference site.
Arch Linux User
I run Arch Linux installations on my desktop and laptop. They run a minimal system, preferring a Tiling WM called BSPWM over a fully blown environment such as Gnome, as it allows me to maintain a keyboard-driven setup which greatly increases my productivity.
I choose to use Arch Linux over other distributions because Arch gives me the choice with how I want to run my machine; by default Arch has a very limited base Operating System, which provides the ability for users to control how their system is set up. I enjoy developing and optimising my workflow, and as such, I like having a system in which I can limit the number of moving parts and ensure I have the minimal working environment required.
I also love ricing my Arch Linux installs. I constantly try to improve my setup; my installs are evolutionary, not static, and adapt to my changing usage model.
I enjoy playing games as a passtime, where I usually join a number of my friends to play together.