The Dev-X Project is a series of features with industry leaders sharing their developer experience insights. In each “episode”, we ask an industry leader 10 interesting questions about DX, collect their responses and insights and share them with you.
In this episode, we’re featuring Brian Rinaldi, Developer Experience Engineer at LaunchDarkly @ LaunchDarkly
About Brian: Brian Rinaldi is a Developer Experience Engineer at LaunchDarkly with over 20 years experience as a developer for the web. Brian is actively involved in the community running developer meetups via CFE.dev and Orlando Devs. He’s the editor of the Jamstacked newsletter and co-author of The Jamstack Book from Manning.
You can follow Brian on Twitter and on LinkedIn.
When did you decide to become a developer?
I loved coding when I was young. I learned my first code on an Apple IIe in middle school and then taught myself Basic in high school, learning some early graphics and animation, back when there were few graphic games on the computer. Then I had a teacher who turned me off to coding at all and I didn’t touch it again until after I graduated college when I bought a computer and taught myself to build web pages, use Flash (pre-ActionScript) and Director (with a language called Lingo). Eventually, a friend told me that if I took a crash course on ColdFusion, he could get me a job. I did and he did.
What are the key ingredients to a really good engineering culture?
I think it all comes down to trust, ethics and communication. In my experience, most issues in engineering aren’t a skill thing or a knowledge thing. There’s enough information out there that most anything can be learned or even simply looked up. The problems are usually around, do I trust management to make the right choices? Do I believe in that we are building is important and worthwhile? Do I trust my teammates to do their part and do they trust me to do mine? Am I empowered to share my perspective or communicate when I see a potential problem or disagree with a decision? Am I able to trust that my team enough even when a decision is made that I may decision agree with?
Unfortunately, those are all tough questions and difficult to discern in an interview process but look for a place that is clear about their culture and makes it a priority.
Let’s say you’re building something from scratch. What does your ideal stack look like?
That’s tough for me since part of my role is often to experiment with new stacks (and see how our product works with them, obviously). Right now I am full-stack JavaScript and my favorite full-stack framework at the moment is Astro. I like Astro philosophically: in the way that it emphasizes sending less JavaScript to the client; in the way that it enables islands of interactivity; in the way that it allows you to use any type of framework component (or no framework at all). But I also like the way Astro works in reality. I enjoy working with it and look forward to opportunities to learn more about it.
Tell us about an epic engineering fail you’ve experienced in your career. What did you learn from it?
I made a couple of big mistakes early on in my career. One time I forgot the where on a SQL update statement and overwrote the database. This was around 1998 and we didn’t have multiple environments and such set up yet, so I overwrote production data for every customer account. We did have regular backups but still lost a few hours of data.
Another time, I accidentally dragged files into the wrong place via FTP (remember FTP? haven’t used it in forever). This sounds trivial but it broke the site and took a while to get back into place.
Since then I’ve been extremely cautious, double and triple checking my work before I push it out and have avoided any big mistakes. It helps that, in my role in DevRel for the past 12 years, I have only infrequently been on a team pushing production apps.
How important is “Developer Experience”? Do you see this as a trend that will evolve into dedicated teams/functions for mainstream tech companies?
Developer experience has seemed to get a bit of a bad rap recently with folks, particularly in the web community, arguing that it has overshadowed user experience for too long. But I do feel like developer experience is important. Developer tooling is a huge industry and ultimately companies will care deeply about how developers interact with their products – how much they enjoy using the product, how easy it is to onboard, how it can reduce some of their pain points and burdens. They have to. That’s their core audience. I don’t really see developer experience and user experience in conflict.
What’s your POV on “platform engineering”? Is this just another buzzword? Or is this a trend that will make a tangible, positive impact on development teams?
Everything is arguably another buzzword in the end. As soon as we label something or give it a name, it becomes a buzzword. Something can be a buzzword and still have real value and real meaning. With platform engineering, I think the term is a bit vague but, conceptually, it fits with my own preferences. I have never been skilled in building out the infrastructure for applications and I love that today that someone with my skillset can use tooling that helps someone like me not worry about infrastructure complexities.
How has the macroeconomic climate impacted your company’s engineering objectives, goals, and strategy?
All startups that I am aware of had to make a rapid shift from growth at any cost to efficiency (often termed as “doing more with less”, which is a phrase I very much dislike). We were not immune.
How are you using AI to impact your developer experience and your team’s overall workflow?
Right now, we’re just experimenting with the ways it might impact our product. Some products it’s immediate usage is obvious, but others much less so and I think we fall in the latter category. However, I can foresee a time when workflow and experiment creation based upon feature flags are aided by AI. AI code tools are also extremely useful for building demo apps, which is a significant aspect of the work across my team, so we’ve been learning how to integrate them into our workflow.
Share some tips to help remote teams collaborate better.
My biggest tip would be to set up recurring time to chat. No agenda. It doesn’t even have to be about work, just an opportunity to get to know each other. The more you get to know the people you work with (which is difficult in remote scenarios), the more you understand them. The more you understand them, the better you’ll communicate. And the better you communicate, the more successful you will be at collaboration.
Do you want to share anything else? Please share anything you think would be of value to the broader developer community:
My one generalized piece of advice would be to learn to follow your passions even when they don’t align with your job. Do your job, of course, but find room for them. Many of the best things in my career came from doing something that went outside the scope of my job but I cared passionately about.
Want to upgrade your developer experience? Get Livecycle and start collaborating in context on top of your PR deploy previews.
Like what you see here? Want to get featured? Check out our DevX Project for other great features and to apply to share your own developer experience wisdom
