Onboarding at R3 and Working on the P2P Preview of Corda

R3 Aug 11 2022 By: Emily Bowe
Comments

0 Comments

Views

1,515 Views

Onboarding at R3 and Working on the P2P Preview of Corda
Emily Bowe
Emily Bowe Software Engineer
Share this post:
Copied

I’m a software engineer here at R3, working on the P2P (peer-to-peer) team. We recently dropped the first preview of the new peer-to-peer communications layer of Corda 5. In this article, I’ll talk about what it’s been like working on this release and my onboarding experience at R3 since I joined last year.

I moved to the P2P team 10 months ago and I love it here. Working on the platform team, on the cutting edge P2P preview, has been so fulfilling. My team is extremely knowledgeable and laser-focused, and definitely inspire me. I love hearing what everyone is working on in our standup (and I stalk our platform Slack channel to see what other teams are working on too!).

Looking

In a typical day, I’ll have standup with our team and a catchup/demo. Most of the day I’m working on my current ticket, and if I’m blocked I’ll check our troubleshooting Slack channels or message my team. One of the features I’ve worked on for the P2P preview is implementing TTL (time-to-live) functionality in the P2P communications layer and enhancing our load generator to be able to make use of it. TTL is used in the P2P layer to set an expiry on messages that have value for a limited time period.

I’ve also enhanced one of our internal event streams, which we call Markers. The P2P layer is responsible for the reliable delivery of messages to peers. In order to guarantee messages are eventually delivered, the P2P layer will replay messages. Markers are used internally for this replay logic, and externally as a general event feed for tracking the status of outbound messages.

Currently I’m working on rotating the session ephemeral keys, for security purposes. Ephemeral keys are used in the P2P layer to encrypt and authenticate messages. I’ll need to use a reasonable frequency for refresh that won’t cause disruption, and add a jitter so all sessions will not refresh at the same time (causing a latency spike). I really like getting a diverse range of tickets to work on. Sometimes a ticket requires more networking knowledge, sometimes I need to test something with Kubernetes, this recent one is more mathematical as it requires calculations.

A Kubernetes deployment of a full Corda cluster
A Kubernetes deployment of a full Corda cluster

We have a large suite of automated tests that are used to catch any regressions as we evolve our software, but occasionally we might also do some manual testing. Corda 5 was designed to be cloud-native and we primarily use Kubernetes to deploy and test our software. Also before our team release updates, we will swarm and do extra testing before anything goes to QA. I used to absolutely dread working with Kubernetes. Setting up a deployment (recent one pictured above) would take a long time and when I ran into problems I wasn’t sure what the error messages were trying to tell me. But now that I’ve had more practice, I feel more confident with it and if I do run into issues I can troubleshoot more easily.

Aside from Kubernetes, we use a lot of other technologies. Some of them include: HTTP/TLS protocols for transmitting data across the Internet between Corda clusters, Netty for HTTP clients/servers, Kafka for messaging between components, OSGi for packaging our applications & running them within an OSGi framework, Kotlin as our language and Gradle as our build tool.

A friend recently asked me about software engineering as they’re interested in switching to it, however they were afraid you’d just be assigned tickets and have to ‘figure it out’, which is only partly true. Yes you do need to play detective and work the problem yourself. Becoming more independent and needing my team less is what I strive towards. That said, I never feel like I’m left on my own if I’m stuck. When that’s the case my team try to teach me how they would find the answer, rather than giving me the answer itself. I described to that person the help I get from my team and how in the other Slack channels you can see different teams helping each other out. I talked about how I really enjoy this way of working and it feels very collaborative. I had really sold them on software engineering by the end, so if this pitch is working on you too…go check out our careers page!

I felt safe, I felt nurtured, and I felt truly gorgeous.

And as to onboarding in R3 and how I got here?
Well a bit of background first: I was always interested in science and my undergraduate degree is in biology. However, when I realised I didn’t want to be a research scientist, I wasn’t sure what else I should do. In the meantime, I worked in HR for a few years. I wanted a career where I would be challenged, where creativity and problem solving would be celebrated. After a while, I found software engineering. Coming from an all-girls school this field had never been mentioned by teachers or my peers, and finding engineering now I felt like I was behind. But it’s never too late, so I decided to go for it. I enrolled in a software engineering degree programme. My job wouldn’t allow me to work part-time so I studied and did projects while working full-time, and used my PTO for study weeks and to take exams.

I finished the software degree but the course had taught me C#, and I felt that learning Java would give me more opportunities. So while still working full-time, I taught myself Java in the evenings. Then I bought that big book of interview questions that everyone gets and studied that. I looked at articles, and did sample problems, and watched videos. I went to my first tech conference and changed the science blog that I had started in university into a tech blog. I worked until I felt like the gulf between what college taught me and what an interviewer might ask me seemed less daunting. I started interviewing, and one of those interviews was with R3 for their intern programme.

Let's go

In the R3 recruitment process for interns, there was a take-home code problem and this was then discussed in the interview along with other questions. In the interview I wasn’t nervous. I had told myself I wasn’t going to get it, so just relax and answer their questions. When they called me to say I had been successful, I couldn’t believe it. After wanting to start my new career so much and studying so much, I could finally begin. I handed in my notice with 6 weeks to go before my start date at R3, and used the time to study Kotlin and some of the technologies R3 were using.

I started my internship in a team called Managed Services. Between the intern programme and my new team I was invited to lots of meetings, where a lot of things from technical discussions would go over my head. I didn’t know enough to add to the conversation so I would mostly stay silent, take notes, and work on understanding what was being said. I looked forward to the day I would know enough to be able to problem solve and contribute just like everybody else. I remember wishing there was some sort of manual on ‘what we expect interns to know’ that we could all read from. The amount of times I’d have to say I didn’t know something felt like a lot. I fought the urge to be insecure and experience imposter syndrome only because so many senior people had mentioned during our intern talks about how they had experienced it. That helped me keep it at bay.

One of the most meaningful conversations I had as an intern was with R3’s Head of Engineering. It was impactful to see someone like me in such a senior position and it made me feel hopeful about a future at R3. In our meeting she agreed to be my mentor, and in the subsequent weeks and months she spent countless hours (often after work in her own time) to help and guide me.

You just need some help

In my biology undergraduate and in my previous HR role, women were well represented. My gender wasn’t considered of note in either of those fields. But now that I was an engineer, it felt like a headline. Not every day was easy, but a positive I draw from this situation is that other colleagues rallied around me. When I was struggling, I was able to turn to my assigned R3 Buddy who was invaluable support (and now a close friend!). I have also turned to my mentor, and one of my Dublin colleagues that I’m close to.

Here in the Dublin office, we’re a small (rapidly growing) group that enjoys socialising together. Sometimes it’s pretty casual, just grabbing lunch or a few of us heading out for a coffee. There are lots of different events and team dinners (thank you Events team and Social committee!). Some of the outings we’ve had so far this year have been bouldering, Taste of Dublin, game night, and hiking.

Bouldering with people from the Dublin office
Bouldering with people from the Dublin office

I’ve visited the London office a few times and always look forward to it. Quite a few of us will be heading over soon for our annual CordaCon conference — maybe we’ll see you there! I find it easy to socialise in the London office too, for lunches there’s usually a group heading to the Whitecross Market together (I would never be able to navigate the Barbican shortcut on my own!) and you can always find a group for dinner. I enjoy the London office in particular because most of my team and my mentor are based in London, so it’s really nice to sit together, have meetings and 1:1s in person, and collaborate. Right now I’d say the London office is winning in terms of swankiness, but the Dublin office is getting an upgrade later this year so watch this space…!

Final thoughts?
Was it worth it? Yes! I love being a software engineer more than I had hoped. What’s R3 like? I feel fortunate to be here, especially during the creation of Corda 5. The problems we solve are far more interesting than you would get in most other workplaces. With show & tell, demos, and tech talks happening every once in a while, it’s great to share in what’s created (even if some tech things still elude my understanding). Additionally with Town Halls, Business Unit meetings, surveys, and feedback it’s great to see what’s going on in the wider company and also feel heard. Yes, there have been and will be harder days, but I think what makes R3 stand out is the family I have found here.

Thanks to Dimos Raptis, William Vigor, Amie Grace, and Dr. Kat Baker.

Emily Bowe
Emily Bowe Emily Bowe is a Software Engineer at R3, an enterprise blockchain software firm working with a global ecosystem of more than 350 participants across multiple industries from both the private and public sectors to develop on Corda, its open-source blockchain platform, and Corda Enterprise, a commercial version of Corda for enterprise usage.

Leave a Reply

Subscribe to our newsletter to stay up to date on the latest developer news, tools, and articles.