In a recent Moderne office hours session, we had the privilege to talk to Shannon Pamperl, a principal cloud architect at Shelter Insurance, where he has worked for over eleven years. On top of his duties there, Shannon is also one of the longest-standing and most prolific contributors to OpenRewrite, particularly in the development of Groovy and Gradle recipes. Furthermore, if you’re part of the OpenRewrite community Slack, you’ve likely seen him kindly answering a variety of questions.
In the office hours session, Shannon shared valuable insights about a variety of topics such as how to get started with recipe development, what his biggest challenges have been, and what things companies can do to help engineers succeed.
I’ll cover some key highlights from the discussion in this post.
Getting started with contributing to OpenRewrite
Office Hours (OH): If someone wanted to start contributing to OpenRewrite, how should they go about it? Do you have any tips?
Shannon Pamperl (SP): “I think the best way to get started is coming at it with a problem, because then you have a context to solve towards. From there, the OpenRewrite Slack is a great place to ask questions. The rewrite test harness is great to get started for doing the transformation itself to come up with a minimum example of hey here is what it should look like before and here is what it needs to look like after. And then from there it’s really starting to write the recipe guts itself.”
> We’d also strongly recommend checking out the OpenRewrite documentation as we continuously update it with new recipes, guides, or answers to common questions we see. If there’s anything missing there that you’d like to see, please don’t hesitate to let us know.
Understanding the OpenRewrite data model
OH: What are some of the challenges you encountered when learning to use and author with OpenRewrite?
SP: “The biggest one really is getting a grasp on the data model itself. As technologists, the way we organize data is kind of the first boundary of how we then work with that data. Whether it’s the ‘J’ LST type representing Java languages and the higher level compiler types—the compilation unit, the class definition, etc. Those are kind of the foundational parts of how you can then rapidly traverse that densely connected graph. Once you have a handle on that data model, it’s then using a typical visitor pattern.”
> We’ve put in a lot of work to improve this experience so that it’s not as difficult to wrap your head around. If you want to learn more about Lossless Semantic Tree (LST) types, check out our Java LST examples doc where we provide visualizations and break each LST type down. If you want to learn more about visitors, check out our documentation on visitors that also includes some videos we've made on the topic.
Best way to improve OpenRewrite
OH: If we could wave a magic wand and make OpenRewrite better or more capable in some way,how would you have us wave that wand?
SP: “The one that comes to mind is more parsers. There are a lot of parsers today that deal with different languages—but even as a financial services organization there are still languages out there that we have that don’t have parsers yet. Sometimes you have to do text replacements and it works but…”
OH: But if text replacements were good enough, we wouldn’t have OpenRewrite at all because we’d all be satisfied with our regexes. 😆 So we are obviously working on C# right now, what other languages are on your list? You’ve got the typical Python and JavaScript…?
SP: “TSX is kind of the one that jumps to mind—both for react code where it’s kind of an intermixed TypeScript and HTML language.”
Favorite tip for authoring OpenRewrite recipes
OH: You are an expert recipe author. You’ve probably tried just about every recipe authoring pattern that exists. Do you have a favorite tip or trick or technique that you find yourself going back to? Something that you know from experience that other recipes authors might not know that they’d benefit from?
SP: “The one thing that I lean on, personally… comes from the Unix idea of ‘do one thing and do it well.’ With recipes, if you focus in on ‘I want this recipe to do this exact thing,’ you can then take multiple recipes and compose them together—or their visitors—and compose them together to get higher and higher ordered compositional elements. And that’s I think where that functional composition really starts to shine, especially as you get into declarative recipes and things like that.”
> This is great advice for not just recipe development, but development or problems in general. Breaking issues up into small, key components can help you progress and solve problems that otherwise may feel impossible.
Feature flag challenges
OH: You’ve made several contributions to rewrite-launchdarkly. Can you tell us a bit about the challenges with using feature flags that have motivated you to make contributions in that area?
SP: “Ya, I think there are kind of two parts there. A lot of organizations using feature flags can help ‘dark launch’ or gate off pieces of functionality until you’re ready for them. So there’s advantages there, but at the same time [you have] the same problems that you run into as a financial services industry trying to keep up with the open source industry. Like open source communities are running a mile a minute, keeping up as an enterprise organization is hard just even from a dependencies standpoint—even with automation.
But then you layer in types moving from one package to another, the APIs changing slightly or subtly, all for good reasons and with good justification behind them but... Find and replace only scales so far. And that’s where I think recipe development really comes in. For LaunchDarkly in particular, finding out where all are we using feature flags that we’ve long since forgotten about. And then, furthermore, using the remove boolean variation to then just like go get rid of it. It’s dead anyway, make it gone.”
> Want to learn more about feature flags, some of the key challenges with them, and how Moderne can help address those? Check out our blog post on streamlining feature flags.
How to nurture engineers
OH: We’ve met quite a few engineers at Shelter, including yourself, that are extremely good at [development]—that have real technical depth in a variety of fields. Is there something that Shelter does right to help nurture great engineering talent?
SP: “This is going to sound a little funny because usually when a company says this it starts to send off red flags—but, when I joined Shelter… I was told really early on that y’know Shelter is a family. At first, as normal technologists, we kind of take that as a ‘wait a second…’ that usually doesn’t mean what an organization says it means. But, what I’ve found is that Shelter really stands by that. And what I mean is that, like your own personal siblings, they’ll jump in and help you when you’re having a problem.
"As an individual you can go fast, but as a group or a team you can go far."
"They really push you to be your best self, do your very best—and when you don’t know an answer, it’s okay to say I don’t know. And then we’ll work together to find that answer or find you someone that does know that answer. And really work to level-up a person as an individual."
Join the OpenRewrite community efforts
Our session with Shannon Pamperl was both enlightening and inspiring. We greatly appreciate his dedication to improving the OpenRewrite community and hope his contributions inspire others to get involved in open-source software. Shannon’s commitment to fostering collaboration sets a powerful example. Watch the full community office hours here:
If you have any questions about what was discussed or want to engage further with us, please don’t hesitate to join the OpenRewrite community Slack.
