Five weeks as a Dev (from an Ops perspective)

I started my new job five weeks ago as a Development Operations Engineer at an exciting company based in Melbourne, Australia. It’s been a real eye-opening experience for me in many ways.

Firstly as a company that implements and practices Agile Development combined with Continuous Integration and Continuous Deployment, it was a refreshing change from having worked in a large corporate machine where cogs turn slowly and change happens at a snails pace. On my first day I remember counting the number of code deployments that happened that day in the department I’m working in (17 I think) and being overwhelmed by the scale. At my previously role I was across almost every change going into production and we were lucky to ship more than two changes a day.

But mostly what I wanted to talk about was my experience as a Developer, from the perspective as an Operations guy with limited developer experience. The company I started at has a policy of inducting all Dev and DevOps starters in a team that delivers mostly small improvements rather than big projects with new starters staying on for one to two Sprints.

I’ve been lucky in that I started teaching myself programming while I was in high school. I started with C and can remember my first real program (after hello world) was to generate a list of prime numbers. I would carry around a pen and paper on the tram trying to figure out the algorithm and spent days getting it working, but it was an enjoyable exercise. Why didn’t I become a programmer? I had a good friend who cracked games for cans of Coke in the school yard and spent his lunch time porting a Sonic the Hedgehog 2 level editor to Delphi. He is still the smartest person I know. But burying myself in code and learning it raised the same challenges as learning high level maths in high school, I liked it but I couldn’t sit still long enough to learn the theory to get to the next level. I set myself impossible goals of achieving big things and never completing them, like learning cryptography and writing a distributed version of RainbowCrack.

So I became a system administrator, which I definitly don’t regret. Prior to starting my new job I spent a lot more time writing code, but since I had nobody to tell me what was right or wrong I was painfully aware of my shortcomings. I knew how to write code but not why I should or shouldn’t write it that way, I was doing what I knew but had only skimmed the surface of what it meant to be a programmer.

​

I spent my first three days getting my bearings and setting up a development environment on my laptop. Then I started doing a few minor tasks, pairing with a senior Developer and everything was falling into place nicely.

By the second week I felt confident, like I knew enough to get by and was actually completing small tasks on my own. But in the third week I had a Pull Request (PR) ripped to shreds by several Developers. As I paired with an experienced dev to fix said PR I realised I had not learnt the shortcuts to my IDE (RubyMine) and struggled to complete the simplest tasks. I finished the week feeling dejected and a burdon to my colleagues.

At the beginning of the fourth week as, effectively, a Junior Developer I was ready to move on. I was hired for my skills with automation and Unix, not programming; this was outside of my comfort zone. Unfortunately I got bogged down in tasks for which our team did not have the skills required. I spent two weeks working on two bigger Stories and barely shipped anything. I’ve felt like I was bashing my head against a brick wall many times in my short career, but not like this. I was previously able to power through most of my issues with a a little bit of luck and lot of stubborness. When the going got tough enough I could push the issues I had found back to Developers to diagnose or fix; ultimately I was mostly responsible for proving that an issue existed or where it existed. Fixing it was a bonus I sometimes was able to achieve, but not a requirement.

But looking back, as we do in a Sprint Retro, I found my team members had a similar experience. It was a tough two weeks but we all knuckled down and did the best we could. This allowed me to look back at what I had achieved more positively. I hadn’t shipped much, but I’d learnt a lot and put in the hard yards that someone else would’ve had to do if I wasn’t there.

It would be a cliche to say I gained a better appreciation for Developers, I think I had appreciation for the work they did already. But appreciating the work they do and understanding it are two different things. I’m happy to move on now to more of an Operations role, but I’m really glad I spent the extra two weeks getting to know the ins and outs of the job, to see the highs and the lows. I’ve also gained some invaluable knowledge of development in general, which will help me in my side projects and day to day work.