My first experience with open source

I did something my imposter syndrome told me I'd never do, and something my inner critic, now tells me is not that big deal.

I'm a self-taught developer who didn't initially realize my passion for computers could become a career. It wasn't until I began working as an analyst at an investment bank that this became clear. Due to my lack of formal software engineering education, I've often struggled with imposter syndrome—feeling like I'm not a "real" developer. But last week, after getting my first open-source pull request approved, I realized it's finally time to let go of this limiting belief.

In this blog, I'll share my experience contributing to an open-source project and the valuable lessons I learned. Hopefully, this story inspires you to overcome whatever may be holding you back in your own professional journey.

How it Started

I'm currently working on a tool to automate migrating SSIS (SQL Server Integration Services) packages to modern platforms such as Snowflake, Databricks, or Fabric. A key requirement for this tool involves parsing T-SQL statements to rewrite them appropriately for different targets.

I chose the datafusion sqlparser library to generate an Abstract Syntax Tree (AST) from SQL statements. However, I quickly hit a roadblock: the library didn't support the OUTPUT keyword, which, although non-standard ANSI SQL, is commonly used in T-SQL to extract the results of CRUD operations.

My usual approach would be to scour the internet for a different library or workaround, often spending considerable time. But this time, I decided to try something new and proactive:

Creating an issue

First, I created an issue on the project's GitHub repository. While creating issues isn't new to me, previously I'd only done so internally—either for myself or my team—where a lot of context could be assumed or discussed informally. This time, however, I needed to clearly communicate my problem to people with no prior context, maintainers volunteering their valuable time, already managing 179 open issues.

This experience taught me the importance of clarity, precision, and conciseness in documenting issues. Moving forward, I'll adopt this approach at work by providing explicit examples of current behavior and clearly defining the desired outcomes. Too often, internal issues become stale because context fades over time.

You can see the original issue here: 1789.

Time boxing the investigation

I'm naturally optimistic about problem-solving, believing I can tackle almost anything given enough effort. But this optimism sometimes leads me down rabbit holes, spending disproportionate time on small issues. To prevent this, I decided to time-box my initial investigation to one day. This approach significantly reduced my hesitation and allowed me to quickly evaluate whether handling the OUTPUT clause was feasible.

I soon discovered the necessary change was quite manageable, motivating me to solve the issue immediately. This taught me a valuable lesson about decision-making: limiting exploratory efforts can yield quicker insights and better-informed discussions.

This strategy has already improved our workflow at my job. Recently, a colleague proposed refactoring our proof-of-concept. Instead of lengthy theoretical debates, we encouraged him to experiment directly. His hands-on experience led to a significantly better solution, different and superior to both our initial ideas and his original proposal.

What surprised me

Reading beats writing. I previously assumed contributing to open-source required exceptional coding skills. However, I discovered that understanding the codebase deeply is far more critical than writing flawless code. Many helpful comments on my pull request focused on matching the existing code style rather than correctness. This reinforced the importance of familiarity with the codebase, explaining why some developers seem effortlessly efficient.

I still don’t really understand what git rebase does. Collaborating globally means manual fixes for git issues aren't practical, unlike my day job, where we sit together. My unfamiliarity with git rebase caused avoidable mistakes and extra work. Improving my git proficiency has become a new priority because smooth collaboration is essential for successful software projects.

You can see the finalised pull request here:: 1790.

Reinforcing What I Already Knew

Testing is what makes your project scalable. Although I'm not fully convinced by Test-Driven Development (TDD), robust testing gave me the confidence to contribute without fear of breaking existing functionality. Proper testing clearly makes projects more scalable and easier to maintain.

Being nice is a super power. The reviewer of my pull request was exceptionally friendly and supportive. While I don’t believe in being nice no matter what. This positive interaction inspired me to continue contributing and to support others similarly.

Conclusion

This was a great experience for me, and I feel like I made the world a tiny bit better. We often overlook that modern software relies heavily on open-source foundations (sqlparser-rs, for instance, powers libraries I regularly use like pola.rs). Many of these projects rely on just a few dedicated maintainers. Next time you encounter an issue, I encourage you to report it or contribute directly. Your small effort can make a meaningful difference.