I’m not really much of a goal setter. I don’t make new years resolutions. I don’t have a budget, I don’t track my workouts and I don’t keep a journal. There’s a quote “What gets measured gets managed” and I don’t measure anything at all. In school I didn’t even like using a ruler. My lines were all wonky and my bar charts made people shriek. But they were still lines and they still worked. Perhaps however, going your whole life with wonky lines isn’t the most sensible idea.

So, I’ve decided/been strongly encouraged to set some SMART goals and write them down, so my team can be aware of what I’m looking to achieve and vice-versa. Aite, let’s bang ’em out.

Write Things

I used to do a lot of drawing, and one odd thing about it is: whenever I go back and look at old drawings I can usually recall where I was in my life when I drew it. With software engineering I don’t get that feeling at all - I could open up a Javascript file from 2017 and not only question my sobriety within the commit history, but I’d also not recall why I wrote any of it the way I did.

Part of the reason behind writing/blogging more frequently is to see if I can capture some more of the essence of why I did things the way I did. With regards to CircleCI; why our services do the things they do, why parts of the codebase are the way they are.

Every month I will write about something related either to technology, working within my team, or general CircleCI shenanigans - if I start writing about Dota 2 or Mossack Fonseca then consider this goal a failure. By doing this I hope to create a deeper understanding around the work I am part of, develop my writing and communication skills, and have a trove of information that I can share with other folks asynchronously.

Gettin’ Gud at Circle

While having a mentoring session with Irelands’ own Cian Synnott we discovered that although we knew what continuous integration was, and although we were helping build the CircleCI product - we did not know all the ins and outs of what CircleCI could really do. And so we began the joint noble venture of “Gettin’ Gud at CircleCI”.

As it turns out CircleCI - the product - can do quite a few things, and it’s worth learning all the things it can do considering that I am in some part responsible for what it will do next.

Every 2 weeks Cian and I (and on the occasion that we cannot sync, just me) will go through some aspect of the CircleCI product offering and ideally try it out in some way. By doing this I will increase my knowledge of what’s possible with CircleCI and what our customers can actually do, which will help with my on-call rotations. Also, it’ll make for some good blogging fodder.

Do Dev Ops

So most of the Dev Ops folks I’ve encountered at $previous_company have taken my code and deployed it, kept it reliably deployed, scaled it, solved issues around scaling it and a bunch more unknown stuff too probably. I have a vague gist of what they spent all day doing, but I never got to do much of it myself - thankfully that’s not entirely the case working here.

Teams at CircleCI are responsible not just for the software engineering work but also the site reliability work of the services we own. However, after working here for a few months I have not needed to dip my toes in too deep regarding SRE outside of learning our observability tooling.

I had a quick chit-chat with the brilliant and newly returned Camille Lawrence and found she would also like to scratch this same itch - the Dev Ops itchiness - we are starting with observability tooling (Datadog/Honeycomb). This seems like the best bang for buck to focus on currently given how important it is for our teams efforts, but eventually I’d like to go deeper.

Get involved in all things Dev Ops / SRE whenever the opportunity arises. I realise we don’t simply get Kubernetes or Vamp related tickets added to our backlog, so I think my best bet here is to carve out some time each week to tackle it. I realise this isn’t exactly a SMART goal yet - I need some time to ponder on it, perhaps get some feedback from the team, perhaps something more structured with Camille.

Become an on-caller

Ever since I was a wee boy I’ve always dreamed of being on-call and now I am able to fully realise that dream.

Having never been on-call before, and having declined being on-call at $previous_company when asked as the idea wasn’t appealing even with monetary compensation - I’ve somehow found myself agreeing to be on-call here without monetary compensation. But hey the 20’s are weird, man.

I recently shadowed the one and only Cian Synnott with an issue he faced while on-call and I found it wholly informative, and even a little fun. This shadowing intends to turn me into a regular member of the on-call rotation; show me the ropes and what-not. I’m not on-call yet as I’m rather fresh faced and still kind of onboarding. The onboarding never ends if the learning never ends, right?

Become a regular member of the on-call rotation by the end of the quarter. It will help my team by sharing this beautiful burden, but it will also help expose me to problems in our system and the tooling required to fix them.

Own an Epic

I’ve not owned an Epic before but thanks to this doc I know all about it. Given the choice I am quite interested in owning our tech debt Epic so that I can get some more exposure to exactly how big and spiky our ball and chain is.

Own an Epic. I know Ronald Ekambi needs to give up the our teams’ tech debt Epic before he traitorously jumps ship to the $other_team at the end of the quarter - so I’m penciling that in as the date for now.

Music