Moving into Quality Engineering

I'm excited to announce that I will be moving from Software Engineering to Quality Engineering at Capital One! There's a great opportunity that has just opened up, and I feel I'm ready to try out something a bit different.

I'll be looking to remain working on the Identity Service for the meantime in order to help deliver PSD2, but afterwards I will be looking to move to a new part of the business, so I can experience new experiences and different challenges.

It was a difficult choice, as I don't feel I'm quite ready to leave the Identity Service and have a lot more I want to give, but I know I need to gain greater understanding of the core business and how it works, as well as have some greater personal and professional development. That being said, I'll remain within the team as a QE for the next 3-6 months while we're finishing delivery on PSD2, with a split between the SE and QE roles. After that, I'm hoping to still be able to provide input and share thoughts, although I know I will need to let it go at some point!

Quality Engineering itself has always been something I've been interested in - I applied for both a SE and QE role at Capital One, and my manager and I had decided I would start as a SE but at some point could move within the team to the other role. The team has always been very much test-driven, and I owe a lot of my good practices to the high standards of the team. We're also very fluid between the two roles, where we don't really have any particular "dev tasks" and "QE tasks" but instead share the workload and experience of the codebase where necessary. This has meant that over time I've had opportunities to work a little on the "QE side" of our development process, but have wanted to explore it a little further. I'm especially looking forward to seeing more of the "system testing" of large integration pieces, opposed to the component level testing I've been exposed to as part of being a dev on the team.

I'm also looking to share some of the practices I've pushed a lot in Software Engineering such as code reuse and standardisation, as well as my deep understanding of the AWS and Chef infrastructure internally. I'm hoping to bring more of that knowledge into the QE department, as well as share practices back into the SE department, too.

Creating Chef Training Courses with Packt Publishing

Update: As detailed in Revert "Some knowledge-sharing news" I will no longer be writing these courses.

About six weeks ago, I received an email from one of the folks over at Packt Publishing, reaching out to me about interest in me creating a couple of courses with them. This is a really exciting chance for me to share my Chef knowledge with others in an easily digestible way.

I've now signed contracts for both courses and am happy to share that I'll be creating:

• Hands On Infrastructure Automation with Chef 14, a practical journey through learning Chef with test-driven development in a example-first fashion
• Learning Chef 14, a beginner's learning path which shares more background information for those getting started with Configuration Management and/or Chef

Both courses will share practices that can be found in older Chef versions but will contain some of the cutting-edge tooling and practices for the latest version of Chef.

I'm currently a couple of weeks into the Hands On course, which should be landing some time in Q4 after which I'll start work on Learning Chef 14 which should be released for Q1.

Speaking at OggCamp

I'm really happy to announce I'll be speaking at OggCamp in August about Infrastructure as Cake - Testing Your Configuration Management in the Kitchen, with Sprinkles and Love.

This is the first time I'll be attending OggCamp, which if I remember correctly, I'd heard about from the folks on Late Night Linux. It sounds like it's gonna be a great event, and I'm looking to having a great focus on the digital rights and Free/Open Source Software, which often is a talk or two at a conference, not the main theme.

Speaking at DevOpsDays London

I've also been selected to talk at DevOpsDays London about overengineering my personal website, a talk I've not yet had the chance to do. It's called an "ignite" talk, which means I'll have 5 minutes to speak over auto-incrementing slides, so I'll need to have a fair bit of practice required in order to hit the timings right. It's not a talk style I've done before, nor this talk itself, so I'll be very interested to see how it goes.

I'm really looking forward to finally draw out an infrastructure diagram just to see on paper how crazy it is - although for those of you who are interested, you can see a list of some of the technologies in use on the talk page.