How One Open-Source Code Donation Got Me Promoted

This blog was originally published in my blog website “Ran The Builder”.

On October 2nd, 2020, my first pull request to an open-source project was merged.

Little did I know that it would lead to my promotion to System Architect and that I’d be talking about it at the AWS TLV Summit in Israel.

In this blog, I’ll explain how this one PR changed my career and how you, too, can advance your career while keeping your work-life balance in check.

How Did It Start

Hi, My name is Ran Isenberg, and I’ve been developing software for over ten years.

On October 2nd, 2020, I was a Software Architect in CyberArk, part of the cloud engineering group (more about it here), trying to figure out my way in the AWS Serverless world.

It all started when I faced an issue with AWS Lambda input validation and, more specifically, tried to figure how to parse and validate different events in the AWS Lambda function. Googling ‘AWS Lambda input validation best practices’ didn’t yield any results back then, so I resorted to figuring it out myself.

After a few weeks, while browsing GitHub, I found an excellent repository that caught my eye: AWS Lambda Powertools for Python. It promised to deliver best practices for AWS Lambda functions such as logging, observability, and more. I noticed that AWS engineers maintained it, so I knew this was a pro-level repository.

I browsed their GitHub issues out of curiosity, and one RFC issue intrigued me the most.

The RFC issue described the need for a **parser** utility to validate incoming events to the AWS Lambda function. This is the same problem that had troubled me before, which I had solved.

It got me thinking.

I’ve always heard people say how you should donate code to open-source projects. However, I’ve never really done that nor knew where to start.

I decided to go for it. I thought that it be a nice experience, and I didn’t have anything to lose.

So I posted a message in that RFC issue and started a discussion. I suggested my solution to the maintainers and explained why it’s the best.

They were very friendly and helpful and wanted to see a working POC so they could judge the user experience.

After my kids had gone to bed, I went on to clone the project and started working on that PR. I spent about 1–2 hours per evening for a week until I finally got a green PR.

Fast forward several weeks, code reviews and user experience revisions, and the PR was agreed to be merged and released in the next release. Success!

I felt immense satisfaction. All that hard work paid off, and I knew that developers worldwide could now solve the same issue with ease.

However, it didn’t end there, far from it.

To learn more of the parser utility you can either check the documentation or my blog here.

The Butterfly Effect

This PR started a butterfly effect.

Merging the PR breached an internal wall in my mind. One opportunity led to another.

To donate the code to AWS, I had to use their tools and understand how their pipeline works. I’ve encountered new tools and best practices I wasn’t familiar with know.

I decided to use them in our pipeline, which my managers viewed as an excellent initiative.

I had an idea for a new utility, the feature flags utility. I suggested it to the AWS Lambda Powertools team and wrote an RFC. Boom, another utility merged.

I’ve continued my work with the Parser and added more AWS events support. I got the hang of it and it started to be easier.

During this process, I’ve met developers and created connections with people from around the world.

Later on, I was invited to be part of an AWS Webinar about the parser utility. I’ve never done such a thing before and decided to go for it, challenge myself, and try something new.

The experience was terrific, who knew that talking live about code could be so much fun.

I realized that being a developer advocate is something that I like. I discovered that I enjoy discussing and explaining utilities and best practices. So I also went ahead and presented the utilities internally at CyberArk. You can check out the AWS webinars recordings here.

From then on, I decided I wanted to try new things and get out of my comfort zone to challenge myself. I kept a backlog of cool stuff I wanted to learn and try.

I decided to write blogs about the utilities I created to help spread the word about them and challenge myself to do new things. CyberArk helped me with a blogging workshop where I gained the basics. However, blog writing is like a muscle; you must train it to improve.

So I continued to write about my AWS Serverless experience in my spare time.

I have written over 15 blogs on medium and here, at my new website, and I plan to keep going.

Building Up A Reputation

When I heard of the AWS Community Builders program, I knew I had to apply.

Since I now had a portfolio of AWS-related community work, such as blogs, code donations, and webinars, I was accepted to the program. This program strengthened my AWS knowledge and helped me to create new connections with builders around the world, which led to even more exposure and opportunities.

At work, things changed too. We started to use the utilities I donated internally at CyberArk, and people began to recognize me as an AWS trusted advisor for best practices in AWS Lambda functions and Serverless.

So when the opportunity came, and a new position opened — a System Architect for my group, I applied and got the job.

AWS TLV Summit

The biggest AWS event I spoke at was the AWS Summit TLV last May. I had the pleasure of presenting the parser utility in front of a live audience, which I haven’t done in a while due to Covid-19. It was exciting and a lot of fun and a bit of closure for that one code donation that started it all.

I think that my experience proves that you never know what can happen when you challenge yourself and try new experiences.

This one PR led me to do webinars, write blogs, talk in conferences, become a trusted advisor on AWS Serverless matters, and eventually to my promotion.

OK, So What About You?

Code donations can be just pure fun. It’s a fantastic feeling to know that developers use your code all over the globe and that it provides value.

Code donations can be a nice challenge and a way to learn something new.

Code donations can help you meet new developers and create new connections.

Code donations can open doors for you; they can be a cool project you can discuss in a job interview or help build up a reputation.

Who knows what these opportunities can create for you. The sky’s the limit.

From a personal perspective, I can tell you that code donations ignited something in myself I didn’t know there. I was hooked. Once I conquered a challenge or had a new experience, whether it may be a webinar or a frontal presentation, I wanted to keep pushing.

Tips

Looking back at it now, I think I can conjure up several tips that helped me along the way.

So my main tips for you are:

1. Keep challenging yourself — get out of your comfort zone. Try new things, whether it may be code donations, blogs, webinars, learning a new programming language, etc. Each unique experience is rewarding in its own way.

2. Be curious, and try to improve yourself and your craft. You can always learn something new from anybody.

3. Be open to feedback. Code reviews from strangers can be harsh. Try to learn from everybody and don’t take it personally.

4. Keep a backlog of things you want to do so you are never bored or stuck.

5. Set a time in your schedule for fulfilling the backlog. It may be 5 hours or 30 minutes per week. The important thing is to keep at it BUT in at a time that fits your schedule. Don’t force it or over-work yourself. Your mental health is more important than crossing an item off your backlog.

6. Have fun!

You never really know where this approach leads you.

It might be a promotion, a new job, or just plain satisfaction.

However, I know one thing; these experiences will help you grow as a person and a developer.

Want to start writing open-source code donations too? Look for my upcoming code donation 101 guide which I will publish soon.