Getting started with Aeron is hard.
There, I said it. It took a lot for me to admit. My job as a developer advocate has been learning new technology and using it. I’m good at that. And now I have Claude to help me, and a whole team of people, and the documentation and code samples. And yet… I still struggled. I worked with the guy who created it. I worked with him when I wrote the blog posts for the Disrupter, Aeron’s precursor. And I still don’t know what I’m doing.
Which I guess is why they hired me: Aeron is a specialist tool, written by very clever people to be used by people much cleverer than I am. Folks have even taken the time over the years to write documentation and sample apps (and then scatter them all over the place, sigh). One of my jobs is to not only consolidate the documentation and samples, but also to make it a bit easier for developers like me to get started (you know, people who are merely very good instead of unusually excellent).
So yes. It is hard to get started.
Yes, I did ask Claude to write me a sample app. Actually, I asked it to write two, the first one was far too ambitious. It’s a multiplayer game - I was really excited about this idea last Friday afternoon, but by late Monday, after I’d started sketching out the project structure, I realised I didn’t even know how to wire up a basic skeleton app, let alone a complex multi-node, multi-client distributed game. So then I asked Claude to create a skeleton app, which it did. It created a simple echo app, I believe it used some of the existing sample apps as inspiration. It worked! But I hated the code, it was super procedural and mostly ran in two main methods. So then I spent two days, in between meetings, understanding what each piece did, refactoring things so stuff was more modular, and making sure it still worked. I’d like to share the link to the repo to show you all this, but I’m reluctant to put the code Out There where The Robots can read it when I’m fairly certain it’s not the kind of code I want The Robots reproducing for Aeron users. Perhaps I should publish it for now then remove it when I have better code.
After 2-3 days, when I had some code I could understand better, it occurred to me I was still no clearer on Best Practices for creating applications that use Aeron Cluster (it’s specifically Cluster I wanted to use, not just transport). So I thought I’d better read the documentation. Yes, I know. I did it all backwards - get the AI to generate code and then try to understand the problem. Pretty sure this is Standard Operating Procedure these days, so I’m not unhappy with this approach - I’ve basically just had the same experience almost any other developer will have when they try to get started.
So now I’m working through our actual Cluster tutorial (well, one of them - as I was finding the links for this blog post, I discovered a different Cluster tutorial, sigh), and trying to pare it down to the absolute minimum so I can understand what’s infrastructure code, where the business logic goes, and where it makes sense to put the division between those two things. For this, I created a new IntelliJ IDEA project, used IntelliJ to create the skeleton files, the Gradle build file (yes, I am still using Gradle), and used TDD to start driving the business logic first (there is practically nothing, because the idea is to keep it as lean as possible, but I do need to be able to deal with inputs and outputs and not just use System.out to pretend I have an app that’s doing something). Doing this, several things jumped out at me:
- I haven’t really written code for 3 years, even longer if you consider real working application code instead of demo code. But those skills do not leave you once you’ve locked them in
- I know I’m super-biased, but IntelliJ is still faster and, of course, more predictable at creating certain types of code. Claude created about 3 different types of Gradle build files, with no clear reason why it picked the approaches it did. Intellij created the type of build file I wanted with the latest JUnit dependencies without me having to worry about that. The project structure was what I expected (Claude got that right too, but who knows what it will do next time) and I had total control over the modules I created and what I called them. Perhaps it’s because it’s the pattern I’m used to following, but creating a project with Intellij forced me to consider certain choices at just the time I needed to - which modules do I want, what are they called? What’s the package structure? How do I separate infrastructure from business logic? Yes, I could do that with Claude, but it was kinda over helpful and just created everything, instead of forcing me to think about what I actually wanted.
- Having said that, using Claude to get a working app that I could play with immediately was really gratifying, and helpful. In fact, without having done that first, I probably wouldn’t have had as much of an idea of the type of modules, names and design choices when I started my own project. So Claude’s first pass was useful, but as soon as I needed to understand something at a deeper level, it really needed me to build it from scratch. I actually hate that I just wrote those words, because I have scoffed at developers who write their own “whatever” tool instead of just using someone else’s tool or making the most of what they already have. But if your job is to maintain something, you really do need deep knowledge on how it hangs together and how it fits in to your ecosystem. Merely reading what Claude had produced and moving bits around did not give me the same understanding as reading what Aeron Clusster is supposed to do, following the simple tutorial and trying to build a bare minimum functioning system from scratch.
- I’m using a real hybrid of coding approaches. I’m using Claude Code from the terminal when I want to generate big chunks of things, or do big refactorings. I’m using Claude Code from the mac app when I’m trying to query my Aeron wiki knowledge base because I find the output easier to read than the terminal. I’m use Claude chat from the app when I want to ask questions more general questions. I’m using IntelliJ IDEA’s AI assistant (either with a Claude agent or with its own chat back end) when I want context-sensitive code explanations. I used this a lot for error messages (particularly Gradle errors) and for explaining specific snippets of code from the original Claude-generated application. I like having the AI in the IDE, and I like how easy it is to query specific snippets in context.
My use case of getting started with Aeron is also slightly different from the simple case of a “normal” developer trying to get up and running. I’m also testing the documentation itself, as I’m responsible for updating and maintaining it. When Claude gave me its first output, I had no idea if that was:
- Basically copying sample code we have publicly available
- Using a blend of samples, docs, and Aeron knowledge to synthesize something custom-fit for my use case (I have a personal knowledge base of all things Aeron that I’ve accumulated in the last two weeks working here, and I was using that as Claude’s jumping off point for this project)
- A decent guess based on what it knows about software design in general and the github code for Aeron.
Given that, I needed to go back to our documentation and samples to see what we’re actually telling people. I will eventually need to decide if that’s what we should be telling people. I know all of our stuff is technically correct, and it works. I just don’t know if it’s the most effective way to teach people, if it helps to create the right mental models to work with Aeron, and if it’s a good separation between the infrastructure code and the developer’s business domain code.
Regardless of all of that, I had so much fun!! I haven’t written this much code in YEARS, even if half the code was just refactoring Claude’s code and re-writing Claude comments. It was wonderful to know I still know how to code. It was gratifying to be able to use new Java features that have been sat somewhere in the back of my mind for the last few years and not been able to apply. It was joyous to put my noise-cancelling headphones on and Just Code.
I felt guilty at the end of Monday because I’d been coding and not Doing Product Manager Things. Then I had a meeting about a new API we were thinking about developing and even open sourcing, and it was suggested that perhaps I might like to apply it to an Aeron cluster sample app, and I was like “I’m writing one of those!!!”. It is my job to stay close to the code. It is my job to deeply, technically understand the framework. It is not a side-quest from “real management”.
I love this job. It’s like coming home.