Three times a year, employees from around Braze take two days away from their normal duties to participate in Hack Days. These events—a long-running Braze practice that reflects how the company creates space for dreaming up and implementing new ideas—provide a chance to encourage innovative thinking, highlight pet interests, and even optimize the Braze platform in ways big and small.

To recognize the work that goes into each Hack Day, Building Braze will be profiling participants with particularly memorable projects or experiences. This week, we’re talking to Derek Schultz, Manager, Product Engineering*.

The Joy of Coding For 12 Hours

I think I’ve participated in every Hack Day since I joined Braze in 2019. Most of the time, I’ve ended up demoing the product I’ve come up with to the rest of the company. I’ve found that I usually work alone on Hack Day projects, even though I’m collaborative in my day-to-day work; I love working with other engineers, but there's something about doing work really fast, just for fun. It’s nice to not have any of the overhead of communication and just be able to code for 12 hours straight.

Ideas Can Come From Anywhere

My ideas for Hack Day projects have come from a mix of places. Sometimes, there will be things that bug me in my daily work life and I note them down as they happen in a plain-text document on my computer. When a Hack Day comes up, I look through that list to see if there’s anything I’d like to implement.

Other times, the ideas come from something someone says, like one of my recent projects about adding feedback annotations to email campaigns. That idea came from something that the Product Manager on my team said while we had lunch. I like to ask PMs if there's anything that's driving them crazy and that could be a quick fix—those projects are sort of my sweet spot.

Simplifying a Highly Complex Feature Request

This time around, the idea came from Braze Bonfire, our customer community. A customer was asking if it was possible to copy a campaign from one app group to another. That post started an entire thread of other Braze users saying, “No, and I wish I could do this.” One person came up with a crazy workaround using undocumented API endpoints that was totally unsupported by Braze. People wanted this to work so badly they basically dug into the Braze front-end source code and found ways to hack it in.

Naturally, this seemed like the perfect idea for Hack Day! Cross-app group cloning was actually on our internal Productboard already, and was one of the most requested features of all time. I was like, “Okay, I have to give it a shot.”

The problem is that while a feature like cross-app group cloning may seem very simple on the surface—just copy a campaign from one app group to another, right?—but it’s actually extremely technically complex because of all of the associations that exist between a campaign and other parts of the Braze system. For example, a campaign’s different audience segments have permissions that are tied to specific teams and can leverage specific custom events. Ultimately, a lot of elements of a given campaign are going to be somewhat app group–specific, creating complications when you try to package it up and move a copy of that campaign to a different app group.

Since I knew it was going to be hard to copy all of this context over, my idea for my Hack Day project was that we should just copy over what was easy to move, leave the rest, and then communicate the limitations of the feature to the user. So when you go to copy the app group, a modal pops up with a comprehensive list of everything that is and isn’t copied over—for example, segments or team permissions can’t be copied. Even if the user had to make adjustments after the campaign was copied, we’d still be providing some convenience by allowing them to move the core of the campaign and then letting them to build it from there.

The process of coding this project was mostly done using brute force logic—literally going through the campaign and saying copy this, do not copy this, etc. It wasn’t like I needed to write some complicated algorithm; it was just a matter of implementing rules that would allow the MVP version of the campaign to be copied and moved. In practice, that meant that we were copying the main content of a given campaign, which is where a lot of the value was. If this were an email campaign, for instance, the actual content of the email would be copied over, which I think is the meat of it.

Making the Most of Hack Day

To get the most out of Hack Day, having an engaging demo is the most important thing, at least for me. Keeping the demo short is really important. If it can be interactive, that's a bonus. For a previous Hack Day project, I added a link in the chat to have people participate in the feature. People added comments in real time, so that was fun.

Also, try to clear the work days and move any meetings so you can focus 100% on your project. Context switching is my enemy on Hack Days. You just want to focus for an entire day—that’s why people are able to complete features in such a short amount of time. A lot of corners are cut in the spirit of hack, but having two days of focus is really great.

Interested in getting involved in our hack days? Braze is hiring for a variety of roles across our Engineering, Product Management, and User Experience teams. Check out our careers page to learn more about our open roles and our culture.

*All content in the blog post is of a general nature and for example only. It does not refer to any specific problems, features, or products that Braze intends to make available to customers, either now, or in the future. Nothing in the article should be considered as advice, nor does any information on the post constitute a partial, nor complete roadmap of future technologic features or function of the Braze platform.