As we enter December and 2022 draws to a close, so does a significant chapter in my working career—later this month I’ll be leaving Confluent and onto pastures new.
It’s nearly six years since I wrote a 'moving on' blog entry, and as well as sharing what I’ll be working on next (and why), I also want to reflect on how much I’ve benefited from my time at Confluent and particularly the people with whom I worked.
Looking Backwards 🔗
I’m leaving Confluent with nothing but positive vibes about the company—and quite a feeling of sadness. Confluent was where I officially became a Developer Advocate, and was also my first start-up experience.
In March 2017, I joined Confluent’s Business Development team as a Partner Technology Evangelist. In October of that year, I spoke at Oracle OpenWorld (as it was called then), and a random colleague 😉 who was also there suggested I go and watch some talks at the co-hosted JavaOne conference on a track called "DevRel". DevRel, you say? WTF is that?
Turns out this was a turning point for my career. I learnt in talks from Steve Pousty and Baruch Sadogursky that DevRel was a profession in itself, not just a sideline to try and cram in alongside a day job as I’d been doing for the previous seven years.
Fast forward a few months to April 2018, and I’d convinced Tim Berglund (for it was he, the random colleague who pointed me to the DevRel track at JavaOne) to take me on as a Developer Advocate in his DevX team at Confluent. Here I cut my teeth as a Developer Advocate learning my trade from Tim and colleagues Viktor and Ricardo. I learnt all about building authentic communities from the wonderful Ale Murray, and about DevRel, communities, stream processing, and everything else from Gwen Shapira.
But it’s not always just airmiles and smiles. As well as the practical side of the profession—crafting slides, delivering talks, writing blogs, hacking code, and shitposting—I also learnt a lot about the human side of being a Developer Advocate. I wrote about this for two reasons: for those in the profession and perhaps wondering if they’re alone in finding it hard, as well as those looking in from the outside and thinking about pursuing it as a career. These blogs are perhaps the ones of which I’m the proudest. They don’t get tons of traffic, they didn’t go viral, they certainly didn’t make it to HackerNews. But they evidently resonated with many people judging by the number of folk who have told me that they enjoyed them:
In a similar vein but a bit more practical, here are a few about being a Developer Advocate in general:
(there are a bunch more DevRel posts on this blog, including now this one which gets a bit recursive 😉)
Looking Forwards 🔗
In January I’m going to be joining LakeFS as a Principal DevEx Engineer, working on a great team led by Adi Polak.
Why LakeFS? 🔗
Back in 2016 in my previous role I spent a lot of time researching how to get Oracle’s BI tool to integrate with source control, and I’m looking forward to taking a similarly rigorous approach to the thing that’s at the heart of everything we work with today: data. The data engineering space is a fast-moving one, with new releases arriving all the time to help us process data faster, bigger, smarter. But one of the things that I’ve seen that needs to be added to this is a serious consideration of how we, as data engineers, should adopt and embrace the kind of practices that software engineers would be simply embarrassed not to use. Things like version control and CI/CD to build truly resilient and repeatable deployments.
LakeFS is an open-source tool that provides "git for data". Just as you would branch code to go and try something out instead of writing directly to production, you can do the same with your data. LakeFS uses copy-on-write so that the mountain (or molehill) of data you’ve got doesn’t get duplicated each time you need a new version of it. This is just scratching the surface of what LakeFS can do, and I’m excited to start on a new adventure learning it inside and out—and working with people in the data engineering community to understand how it can work best for them too. I had a bit of a look at it previously and can’t wait to really get my teeth into it 😁.
Parting Thoughts: Community, FTW 🔗
Developer Advocacy is not just shitposting and memes speaking at conferences and writing blogs. It’s also engaging with the community, helping developers, and more. Bringing this all together for me in late 2019 was the opportunity to join the Kafka Summit program committee, followed by becoming the chair of the program committee two years later.
Being on the program committee brings together lots of facets of life as a Developer Advocate. You get to work with the community, with other speakers, you get to influence how a conference is delivered, and pair all of that with a close understanding of trends and interests in the community and beyond.
One of the most rewarding and most important aspects of my time at Confluent has been working with the Community. Whether at conferences, meetups, or online, I’ve made good friends, I’ve learnt lots - and hopefully shared a fair bit of knowledge back too. What I really like about a community is that it’s not got hard edges; communities overlap and come together in different guises. That is to say, I may not be working at Confluent but I will still be keeping in close touch with the Apache Kafka community, and hope to see some of y’all over in the broader data engineering and particularly the LakeFS community too 😄.
