In August, I was given the honor of being named an AWS Serverless Hero.
When I first got the email, I couldn’t believe it. After the public announcement I believed it less. Once I started getting congratulations from my friends, family, coworkers, and strangers, none of it felt real. I couldn’t believe this was happening to me.
It made me wonder what I did to deserve it. Many of us in the AWS community, not just serverless, strive to become AWS Heroes. So what did I do that was special?
To answer that question, we’re going to have to take a few steps back in my career to lay some groundwork.
I started with Tyler Technologies a month before I graduated college in 2012. I often make the joke that the last month school was the hardest not because of finals, but because I already had a full-time job that didn’t care if I graduated or not.
I began work as a junior dev, building thick client .NET applications. Reminiscing on the early days, I definitely felt like I could not have been less prepared for the job. I had never worked in the tech industry before, so everything was new.
I didn’t fully understand source control, I had never done line-by-line debugging, I didn’t know what a sprint was. So I dove into learning. Unfortunately, and not too uncommon of a situation at most companies, there was little internal documentation on anything I needed to know. Getting up to speed was a chore of reading semi-related internet articles and failing fast.
Over the next few years as I grew professionally I was promoted to a lead engineer position. I took ownership of a couple different applications and was responsible for onboarding new developers, among other things.
I would engage with our support organization, where I immediately recognized patterns in their work that could be automated. So I started building tooling to optimize their workflow. These tools took hours-long processes down to single button clicks.
We started building up our documentation. Onboarding, troubleshooting, best practices, and standards were written down so new developers didn’t have the same experience I did. It was in this phase of my career that a genuine feeling of satisfaction came from helping others.
As time went on, that feeling continued to grow. I started helping other development teams in my division. I began giving presentations internally at developer conferences across the company. I wanted people to be the best they could be.
Around 7 years into my career at Tyler Technologies, I was given the opportunity of a lifetime. I received the chance to lead a team of rockstar engineers to learn about the cloud. We did a few trial runs on different platforms early on and decided that AWS serverless was the right call.
As I mentioned in a recent post, my team and I did a significant amount of R&D in the serverless space starting in early 2019. We learned about CI/CD, multi-tenancy, NoSQL data modeling, and even had to take a refresher on JavaScript.
It only took about a month for me to realize we were in the same boat as when I started my career in 2012. There was little to no content online about building completely serverless production ready apps. Yan Cui had been writing blog posts on serverless for a while, which were incredibly helpful, but he was one of the only sources of information we could find.
So I decided to take on the challenge myself.
We were going to learn about serverless by diving in headfirst, and I was going to document it the whole way.
I started my journey at a convenient time. The 2019 time frame is where AWS serverless really took off with its viability for production usage. Sure, Lambda has been around since 2014, and DynamoDB since 2012, but these services were being enhanced with an eye toward production use cases for what felt like the first time around 2018-2019. Triggers and enhanced features began to pop up left and right, allowing us to seriously apply serverless in a production scenario.
As we built proof of concepts and began forming opinions on how development was done in this paradigm, I started blogging.
People love following a journey. I felt like I was embarking on one that many people would follow in the years to come. Documenting major decision points and building reference architectures were breadcrumbs I could trace back if I needed a reminder along the way.
As I wrote, a couple of things started to happen. First, I found my voice. This not only improved my writing ability, but it also made me more confident professionally. I started having better conceptual discussions with my team, with leadership, and even with external teams about serverless because I discovered how to build my own opinions quickly.
Another outcome of my writing was increased community engagement. Extending my network beyond my team at work was never something of interest for me. I didn’t quite understand how important making connections was, both professionally and personally.
As people started engaging with my content, I started forming relationships. This resulted in a better understanding around serverless because I was gaining insights, tips, and tricks from others who were solving (or had solved) the same problems as me.
By now we’re in 2022. I’ve been blogging for a few years, sharing my journey about lessons learned with serverless and important decisions we’ve made. I’ve made connections in the community from a wide range of backgrounds. Yet I still wanted to contribute more.
In April, I started publishing a newsletter. The goal was to serve subscribers catered content that was the best of the best from the serverless community. I also wanted to begin highlighting people who were doing great work in serverless that may or may not be getting the recognition they deserved.
This resulted in even more connections and more understanding around serverless. I began consuming everything I could find that was being written about serverless week after week. I started having private conversations with serverless leaders about their journeys and what was important to them.
I stopped asking questions privately and began asking them openly. Chances are if I have a question, I won’t be the only one who needs the answer. Everything I started doing, I started actively doing to it help the most people I possibly could. If this meant asking silly, obvious questions on Twitter, then so be it.
Becoming a Serverless Hero was not something actively on my radar. This isn’t a program that you apply for and get accepted or rejected from. It’s a program that highlights community members who consistently help others with high-quality, meaningful advice. It’s for people who AWS wants to represent the brand.
Is there something specific I did to deserve it? Honestly, I have no idea.
All I know is that I have been intentionally trying to spread the good word of serverless through blog posts, newsletters, podcasts, and community engagement. I was not trying to become an AWS Hero, so you can imagine the surprise when I got the invitation!
I firmly believe your heart has to be in the right place to become an AWS Hero. Many people out there believe becoming a Hero is an objective task - “if I write 100 blog posts about AWS, then I’ll make it into the program.” It’s not that.
It’s about being passionate. It’s about sharing. It’s about helping others.
My entire career I’ve made it a goal to help others, documenting the road less traveled. At this point, it has become part of my identity. I’m a teacher and I genuinely care about it.
In regard to the question everybody is asking “how do you become an AWS Hero”, my answer is simple. Help other people. There is no set way to become one. Take it on yourself to learn and grow, then pass that on to others to help them learn and grow just like you did.
It is a true honor to be named an AWS Serverless Hero. It is something I am not going to take lightly. I will continue to provide the community with content around serverless. I’ll provide reference architectures, best practices, standards, and patterns. I’ll form relationships with the community. We’ll go down this road together.
Thank you to everyone who has helped me along the way. Thank you to my team that was in the trenches with me. Thank you to the connections I’ve made new and old and to everyone who answers my silly questions on Twitter. And thank you to my mentors, Mike Wolverton and Mark O’Neal. I truly could not have done any of this without you.
Happy coding!
Thank you for subscribing!
View past issues.