#DevStats
BekahHW
5 mins read
Recently, while looking at pgvector, a popular PostgreSQL extension for handling vector embeddings in machine learning, we were surprised to see that Andrew Kane (@ankane), the creator of pgvector, wasn't among the top five contributors to the project in its Lottery Factor chart.
This seemed counterintuitive—how could the project's creator not be a top contributor? A little background on lottery factor: we look at the top contributors based on Pull Requests (PRs) to the project to determine how at risk a project is if a top contributor were to leave. The higher the lottery factor, the more at risk the project is. In the case of Andrew Kane, rather than following the typical pull request workflow, which involves proposing changes, getting feedback, and iterating before merging, he was committing his changes directly to the main branch—a prime example of YOLO coding.
YOLO coding, or "You Only Live Once," is when developers commit changes directly to a project's main branch without going through the conventional pull request and code review process. While Kane's direct commits might allow for faster development, they bypass the code review and testing stages.
Let's be clear: pushing directly to main is a risky practice, regardless of who you are or what you're changing. Here's why:
One bad force push to main could erase your entire project's history. This isn't hyperbole - it's a real risk that has affected even experienced developers. Your project's history isn't just a log; it's a valuable resource for understanding decisions, tracking changes, and maintaining the codebase.
Code reviews aren't just bureaucratic red tape. They're essential safeguards against errors, style inconsistencies, and potential security vulnerabilities. By pushing directly to main, you're skipping this key step.
Pull requests (PRs) provide valuable context for changes. They allow for discussion, explanation, and documentation of why certain decisions were made. This context is invaluable for future developers (including your future self) trying to understand the codebase and is another way to decrease the challenges of losing a maintainer.
Now, you might be thinking, "But what about small changes? Do I really need a PR for a typo fix in the docs?"
Yes, you do. Here's why:
By treating all changes with the same level of caution, you build good habits and maintain a consistent workflow. This reduces the chance of accidentally pushing a more significant change directly to main.
A misplaced character in documentation could lead to confusion or misuse of your software. A seemingly innocent change could have unforeseen consequences.
PRs aren't solely for catching bugs. They're opportunities for knowledge sharing, mentoring, and improving overall code quality.
Popularized by GitHub, pull requests provide a structured way for contributors to propose changes to a project, allowing for review, discussion, and iteration before merging the changes into the main branch. It's like having a safety net for your codebase.
When you have a pull request culture, you decrease the risks brought on by YOLO coding. It's not just about avoiding disasters; it's about fostering collaboration and ensuring the long-term health of your project. Here are some key steps to achieve this:
For small personal projects, the risks of YOLO Coding might not be a big deal. While it might seem tempting to bypass the PR process for quick fixes or when you're confident in your changes for projects with users that collaborate with others, the risks outweigh the minimal time saved. By treating every change, no matter how small, with the respect it deserves, you're not just protecting your codebase - you're creating a culture of quality, collaboration, and continuous improvement.
Remember, in software development, we don't just code for today - we code for the future. We're building something that will outlive us, and we have a responsibility to do it right. Make pull requests a non-negotiable part of your workflow. Your future self (and your team) will thank you.
Bekah graduated from a coding bootcamp in May of 2019 and since then has spent time as a frontend developer, started the Virtual Coffee tech community, spent time in DevRel and has continued to mom her four kids. She currently co-hosts the Compressed.fm and Virtual Coffee podcasts, lifts heavy things in her free time, & works as the Developer Experience Lead at OpenSauced.
Recent Posts
#OSCR
BekahHW
7 mins read
Unlock the full potential of your open source community by understanding and valuing well-rounded contributors. Learn how the OSCR can highlight unsee...
#OSCR
BekahHW
6 mins read
Explore the dual power of metrics and storytelling in open source contribution. Learn how tracking numbers and crafting narratives together can help y...