Mary Grygleski is a Java technologist and software engineer. She works on technical community outreach as a Senior Developer Advocate at IBM. Mary works with hands-on code to architectural overviews. She focuses on the Java ecosystem, especially Liberty, Microprofile and Reactive, as well as Enterprise Java. She is also knowledgeable about hybrid cloud Java deployments using Kubernetes and Red Hat OpenShift. She transitioned from Unix and C to Java and Open Source in the new millennium, and has worked for different software vendor companies as well as several major IT shops in the corporate world.
Table of Contents
- How has Kubernetes changed Java DevRel?
- How is Java developer relations unique?
- How does Open Source impact developer relations?
- How did you get started in DevRel?
- What motivates your interest in community?
- Who is doing developer relations well?
Q: You've worked a lot with Java. How has Java developer relations changed with the introduction of hybrid cloud and Kubernetes?
Kubernetes is good stuff! Working with cloud native and cloud technology has expanded my horizons. To give you some background, I used to work with what used to be called J2EE, then JEE, and now the rebranded name of Jakarta EE, and I spent a ton of time in that ecosystem, working with Java Swing, EJB, servlets, and so on. Looking at cloud native and Kubernetes, I see similarities between Red Hat OpenShift, Linux command-line clients, and containers. Interacting with Kubernetes resembles interacting with an operating system. Kubernetes is like an OS on steroids -- a simple implementation contains many instances! It’s an abstraction: you can create virtual machines that run in parallel processes on the same hardware. Docker is another novel technology that has changed the way we deploy software.
This has changed not only how we build applications; it has social impact too. There used to be people on J2EE teams who focused on release management. These teams had a number of detailed processes involving tons of people working on different types of builds for different environments - dev, QA, prod, pre-prod, etc. Such processes wasted a lot of time: for example, reproducing bugs in different environments was difficult because those bugs were produced in different ways. When Docker came out, you would just pull the image and plug it into any environment, which changed the way how these things were being done. At the same time, as the process improved, people lost their jobs -- you didn’t need a huge team to execute release pipeline tasks. From the point of view of a mechanical pipeline of efficiency, the whole containerization and devOps movement has made the delivery much more effective.
At the same time, using Kubernetes in production is not yet plug-and-play. You can't yet roll out of bed and build a Kubernetes cluster without any experience. Some level of intricate setup is still needed, and that requires knowledge, skill and experience.
I did a joint talk with another speaker from Ukraine and built an example of using reactive sockets for building pipelines, pumping in machine learning data from a multi-player Pac Man game and using RSocket to do that. I spent a lot of time understanding machine learning concepts too, picking a reinforcement approach with case-based reasoning, even though AI/ML isn’t my focus area. I also demoed some code using genetic algorithms.
I’m interested in concurrent distributed systems and event driven architectures. At the same time, I don’t restrict myself to one specific paradigm; it’s all about solving problems with concurrent distributed systems.
Q: How is Java DevRel different from developer relations for other languages or audiences?
Java has definitely carried with it a higher overhead as a web frontend language than other more popular web-based languages like JS or Python. In fact, I recall Java being described as an old-fashioned Cadillac, versus JS or Python like driving a more modern and efficient car. But the strength of Java lies in its backend, its platform independence, and its enterprise capabilities.
Now, with the newer releases and faster release cadence, Java has become a lot more efficient, but there is still some “Java way of doing things” that involves a type of ceremony. (Of course if you’re using Spring Boot, then it’s a bit different …) In Java, you don’t need to follow an opinionated way of doing things, which is also the “beauty” of Java, yet, because of that, it can be harder too especially for anyone not as familiar with Java and not having any “framework” to guide her/him to start.
In terms of developer advocacy, I’ll go out and do presentations, and with a Java audience, if you talk about some conceptual idea that applies to all languages or frameworks, for example, Microsoft has a reactive framework called Orleans, the conversation in my presentation applies to that as well as all other reactive frameworks.
When I give a presentation I pay close attention to the language and how the language gets deployed, and there are expectations about how you’ll do things and how you’ll deploy the application; if you get this right, the audience will understand what you’re doing without a lot of cognitive dissonance. Java DevRel is a little more difficult to understand in the beginning, but once you get over the hump, it’s not so bad.
I remember when I first learned Python using the Flask API at a hackathon, I built it out in three hours; they’re set up to be easier to get hands-on experience without a lot of environment setup. The benefit with Java is that you get more control over what you want to build, which Enterprises love.
Q: How does Free/Open Source software impact developer advocacy efforts, especially in the Java ecosystem?
I think open source has become so prevalent these days, it’s almost like a standard of all environments. It’s becoming a natural way of doing things, especially with Java and the Apache software foundation and the Eclipse foundation, both of which have a strong Java focus. Open source software became a natural part of the ecosystem.
When I first started working with Java, we would use Apache Common library to do things, and we’d always use open source projects like Tomcat. Because these are so easy for any person to setup and configure, it became an obvious goto for advocacy.
The Java Community Process is the open way of encouraging the community to contribute to its specification. That’s how I view it: a very natural part of the community and how Java works hand in hand with Open Source.
Q: How did you get started with developer relations?
I only started doing formal developer relations at IBM in 2018. Before that, I spent two and a half years volunteering with the Chicago JUG, which actually went back to 2013/2014, when I wanted to get more involved with the technical community. The best way to do that is to join a user group, right? I chose Java because I’d been using it since 2000.
Volunteering for the JUG is almost a precursor to being an advocate. You’re trying to advocate for the community, and you’re also choosing speakers who come in to talk about technology and new things. I was attracted by that, and we may call that a calling? Prior to that, I went to a conference in Chicago, No Fluff Just Stuff, and saw several well-known Java speakers present their talks, such as Pratik (Patel) and the one-and-only-one amazing Venkat (Subramaniam). But it never occured to me that I would do advocacy at that point. I was excited simply because I was being exposed to new ideas and concepts which I wouldn’t have been exposed to in the office at work. There were so many new things coming up in technology with frameworks and toolkits that I was missing. I remember thinking, “It would be nice if I became a speaker one day!”. After joining the JUG, I became a user group junkie. I started attending different groups and becoming more involved with the community. CJUG eventually asked me to help as an organizer, and I was then nominated as a meetup director as of 2016. As a result of that, I got to meet more people from the community as well as a lot of great speakers, and I started speaking myself. I was never one for public speaking — that was the scariest thing in my life! However, CJUG has encouraged members to give five minute lightning talks. I remember my first presentation took two weeks to put together! Once I got over that initial fear, I started relaxing and was able to present to other meetup groups, such as women in tech. I was able to get the job in developer advocacy through my speaking experiences at meetups and conferences — that’s how I became an advocate!
Q: What keeps you going? What motivates you to wake up every morning and make the world a better place?
I have an abiding love of technology. I love emerging technologies, and I love to stay on top of the latest trends while also getting my hands “dirty”. Software engineering creates so much opportunity to leverage creativity. While I love working with people and mentoring, I don’t feel that I want to move away from engineering into management.
I love my developer advocacy work: doing presentations, creating content and sharing information. Before starting this job I felt I was in a shell and I wouldn’t be able to break out and do public speaking. At conferences, I would sit in the back and not interact. After years in the community, I’ve found that community engagement was a suppressed aspect of my personality that has blossomed! Now that I have found my passion, I am committed to helping other people engage in their communities and make technological communities open and productive spaces.
Q: Who in DevRel is doing things that you want to call out?
- Trisha Gee and Mala Gupta of JetBrains
- Matt Raible of Okta
- Alina Yurenko of Oracle
- Josh Long and Mark Heckler of VMware
- My colleagues at Red Hat: Steve Poole , Burr Sutter and Edson Yanaga
- Many more :)
Thank you Mary Grygleski for sharing your thoughts on Java developer relations with us.
Top comments (0)