I know I owe you a blog post1, and today I actually have the time, energy and inclination to write it. It's not often those three factors coincide.
I have already done the Great Reveal about the job I am doing now that I'm no longer at JetBrains.
The question I wanted to answer (if only to remind myself later in life!) is why?
Firstly, why did I leave JetBrains? I loved that job. I loved IntelliJ IDEA. That was by far the longest I've ever worked anywhere. But after seven years, it was time to learn some new stuff. I stayed so long at JetBrains because, even doing the same job for that time, I was constantly learning: I learnt more about how to do this developer advocacy thing; I learnt a LOT more about IntelliJ IDEA, which is by far my favourite piece of software for literally anything (we wrote the book with it, and I'm writing this blog with it); it was a great way to learn much more about Java, and stay up to date with a language which is now moving very fast.
However, there were limited opportunities to learn the bigger tool chain that modern developers are using to develop, test and deploy applications. I stopped being a "real" developer in 2012, so I'm really behind on Cloudy, Containery stuff. Because I worked with Dave Farley at LMAX, I was well ahead of the curve on CI/CD and automated testing ten years ago, but now I want to see what real developers are doing these days, and what challenges they face. I have always loved teaching people about the features of Java and IntelliJ IDEA, but I know they don't fix all your problems.
I did interview with several companies last year (not as many as I had planned to, I'll be honest, but I also had far less time in my so-called "year off" than I ever anticipated). When Gradle was suggested to me via Vincent Mayers, I thought, fine, I'll have a chat, I like the build tool, but honestly, I'm not sure what opportunities there are for me there. Once I got chatting to them, I found out they were hiring for a developer advocate for Gradle Enterprise, rather than the build tool, which actually involves talking about Developer Productivity Engineering. The more I heard about DPE, and the more I thought about what it was, the more I realised this was a perfect fit for what I'm interested in.
I care about developer productivity, not because it's a time or money saver, or because it's more efficient, but because I have worked at a number of jobs where I felt miserable because my job as a "developer" involved doing lots of manual, annoying tasks, or waiting for long tasks to finish, or context-switching because everything I worked on needed me to wait for something at some point in the process. I freaking hate that. It's boring, it's distracting, it's frustrating. A lot of the practices and technologies I'm drawn to (including IntelliJ IDEA) make it more fun to be a developer because they help you focus on the difficult problem-solving, instead of shoving stupid blockers in your face that you need to handle.
When I found out Gradle Enterprise has analysis of flaky tests, I was totally sold. Back in 2008, I was the flaky test detector in LMAX, until the team built a tool (AutoTrish) to do it for us. Flaky tests have been close to my heart ever since.
I had been thinking about moving away from developer advocacy, but this opportunity is perfect for me. It's still the JVM world, with options beyond that; I can expand my knowledge beyond writing and testing code, to building, deploying, monitoring and so on; I can still use my advocacy skills of course, many skills like creating talks and content are transferable, and even if the tool is new, the overall topic of developer productivity is not only familiar, but one I'm passionate about.
Finally, the other really important piece was the people I spoke to at Gradle. Some of them, like Vincent and Hans, I have met before at conferences and know from the community. Some of them, like my new boss Justin Reock, I was surprised not to have met before given we have mutual friends. Speaking to all of these people was an absolute pleasure. I was particularly impressed with how Justin sees advocacy, how the movement of Developer Productivity Engineering is almost more important than the product (Gradle Enterprise) itself. Developer advocacy means many things to different people, and that's absolutely fine. But as a developer advocate, you need to work for/with people who see advocacy the same way you do, who can also expand your horizons and help you to learn and grow.
Next week I'm presenting my Career Advice for Programmers talk once again, and it couldn't come at a better time for me. Not only can I reflect on how managing your career changes the more experienced you become, but it has also reminded me of my own career values: learning and growth. Not only for me, but also helping others to learn and grow. This new job at Gradle gives me exactly that, and I'm looking forward to what 2023 will bring.
1 Yes, my therapist would point out I don't owe anyone anything, and that doing a thing because I "should" is no route to a happy life. But, you know, I really would like to tell you about my new job.
2 The title of this blog post is an in-joke that only three people in the world will get, and one of them probably forgot he invented a song that goes "Gradle Gradle Gradle, with Gradle we're gonna play". But thanks Tim, my husband has sung your silly little song for the last 12 years every time someone says the word "Gradle".
