Hello Amplitude Community! We’re going to get started with this AMA featuring @Justin Fiedler and @charcharlielie is 30 min. See you then! 

Hello, I’m Jeremie! I’ll be posting your questions! My background is in scaling digital customer experiences and building brand communities across industries. I currently manage the Amplitude Community!  I am originally from France. My hobbies are travel, writing, and volunteerism. I’m still relatively new to the analytics and marketing space and can’t wait to make my work more data-driven with your help!

Hi, I’m Charlie (he/him), and I’m a frontend engineer at Netlify on the Growth team. I’m relatively new to data-driven product development, mostly because my previous organizations didn’t prioritize user experience as much as the people at Netlify do. I’m currently based in Boulder, Colorado, because it’s pretty much the place to be for rock climbing, hiking, and cycling in the US.

Thanks for having me!

Hi, I am Justin from the developer experience team at Amplitude. I have been building the Ampli CLI and code generated Ampli SDKs to help with data governance for the last few years. My goal is to make developers’ experience with analytics as easy and painless as possible. I live in San Diego and enjoy beaches, waves and IPAs.

Welcome! 

Starting on a more personal note @Charlie Groll Q1: What does your day-to-day look like as a Frontend Engineer at Netlify?

On average, my days are split between heads-down, project work and meetings (planning, SCRUM, social). My start and end times are generally flexible, and any meetings I miss are recorded and/or have notes I can review and add to asynchronously, so my work/life balance is pretty strong. I work on the Netlify web app (https://app.netlify.com) on the Growth team, which broadly means running experiments of all sizes to increase user engagement, retention, and show more users the value they can get from converting into paid customers.

We ship changes to the app dozens of times per day, which is made possible and easy with a combination of Netlify’s Deploy Previews, an amalgam of different static analysis (e.g. linting, TypeScript, Amplitude) and testing (end-to-end and visual regression) tools, and a queuing system for auto-merging Pull Requests. Shipping so often is… refreshing and invigorating. Personally, it makes me feel effective and engaged in a way that facilitates a feeling of accomplishment most days, not feeling guilty for working the hours that work for me, and alleviates the Sunday Scaries.

Awesome, that sounds like a great work environment! Deploy previews sound really powerful. I will look into those for my next project.

Q2: How do you use Amplitude? And why do you use Amplitude vs other solutions?

The main features I use from Amplitude are the event static typing (via TypeScript) and the data analysis/charts.

Static typing for our events is clutch because it’s easy to delegate event creation to our Data, Product, or really any other team that has a vested interest in our experiment/tracking data and giving me time to focus on actual implementation. It’s a mix of who’s creating the data plan, but on my end I just need to pull down the ampli branch and am given strongly-typed APIs for emitting events. No muss, no fuss, and it fits in with our existing TypeScript workflows.

Creating charts is a great way for me, as a developer, to sanity check that events and their associated payloads are flowing through correctly. This is easy to manually check, too, because there is an option, when creating a new chart, to select events using a few things such as your current IP address. I don’t need to paddle out in into our data lake using tools and query languages I’m not using day to day to find some test data and confirm things are working as expected

Q3: How do you use the generated SDK (strongly typed events) to make your life easier?

There’s virtually no friction during development when approval on a data plan from our Product or Data team directly results in code that your type checker will check against. Before Amplitude (we were actually also customers of Iteratively before the acquisition), we had to triple check that we weren’t misspelling event names and that absolutely every part of the payload is what our data team would be expecting. Those days are thankfully long gone.

Great to hear the SDKs are helping to simplify the process. Do you tend to use the generated event methods like `ampli.myEvent()` or the strongly typed event classes `ampli.track(new MyEvent())` more?

We use ampli.myEvent(payload) exclusively, and love the explicit types we get inline for the payload. TIL about the class type!

Q4: What use cases have you seen success with?

I think every case where we add new data points has proven successful in one way or another, because we always get more information about our users and how they interact with our application. Finding out that changing a button color affects interaction positively? Great! Negatively? Also great! The important part, in my view, is being able to run experiments quickly and relatively seamlessly is the important part; any new information we gain can be applied to ask more questions and keep iterating.

The power of product insights is amazing. This is what drives me to make it easy to collect accurate analytics and quickly fuel innovation!

Q5: How do you use dashboards?

As of now, we pipe events from another 3rd party data/event tool into Amplitude in order to take advantage of Amplitude’s charting abilities. Creating and sharing a chart doesn’t require knowing extra query languages… I get to work within the knowledge domain I’m familiar with to monitor and share the progress of experiments that we’re running. It’s incredibly empowering to do that myself instead of relying on our data team to run some ✨magic queries✨ on our data lake.

Q6: What resources are essential for developers?

I might be a tad biased, but a CI/CD pipeline, such as Netlify’s, with a strong developer experience and “just works” factor is absolutely essential to unlocking productivity. I was there for the days of FTPing files to your web server and manually deploying .jar and .war files to an Apache or Oracle™, so I know that pain. 

Again, biased, but our Deploy Previews also make collaboration with Product and Design (and anyone, really) a breeze. I no longer get the excuse of “it works on my machine” because I, my reviewer, and anyone else at Netlify can get a link directly to a live version of our application with the changes from any pull request and leave feedback directly, screenshots and all

Oh! And you can’t forget feature flagging. We use LaunchDarkly for feature flagging, which allows you to keep gated code in production and then roll it out on your own timeline. I will not miss the days of long-running feature branches that are never, ever up to date.

Agreed that a good CI/CD is invaluable. Having dealt with frustrating pipelines in the past Netlify sounds like a dream. Deploy previews would really help to share work in progress.

Q7: How do you work towards data democratization in your role?

I see myself as a canary in the coal mine for our data strategy. Silos and walled gardens, where the Data team is the only way to access information about what we’re tracking, stifle innovation and slow down the entire company’s ability to even use data about our customers. My job, as an engineer, is to understand the implementation details of how data is generated (and that it’s accurately generated) and empower stakeholders, be they from Product, Marketing, or even more from the Data team, to utilize it to ask better questions and make more informed decisions. Amplitude makes that job pretty easy because any of those stakeholders can take our data plan and slap together some meaningful charts in just a few minutes.