YOLO Coding: The Good, the Bad, and the Risky

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.

The Risks of YOLO Coding

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:

Catastrophic Data Loss Risk

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.

Bypassing Critical Safeguards

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.

Context and Continuity Loss

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:

Consistency is Key

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.

Even Small Changes Can Have Big Impacts

A misplaced character in documentation could lead to confusion or misuse of your software. A seemingly innocent change could have unforeseen consequences.

It's Not Just About the Code

PRs aren't solely for catching bugs. They're opportunities for knowledge sharing, mentoring, and improving overall code quality.

The Power of Pull Requests

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.

A Pull Request Culture

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:

• Establish Clear Guidelines: Don't leave your contributors guessing. Define and document the project's contribution process, emphasizing the importance of pull requests. Provide step-by-step instructions on how to create a pull request and what information should be included.
• Encourage Code Reviews: Code reviews aren't just a formality; they're a lifeline. Make code reviews a key part of the development process. Assign reviewers to each pull request and encourage thorough, constructive feedback. This not only helps catch potential issues but also promotes knowledge sharing and collaboration.
• Automate Testing: Don't leave testing to chance. Implement continuous integration and automated testing to catch potential issues early in the development process. This reduces the reliance on manual testing and ensures that changes are thoroughly vetted before merging.
• Recognize and Reward Contributors: Don't be stingy with praise. Acknowledge and appreciate contributors who follow the pull request process and provide valuable feedback. Celebrate their contributions and make them feel valued within the community. A little recognition goes a long way in keeping your contributors motivated and engaged.
• Lead by Example: Practice what you preach. As project maintainers and core contributors, you have to lead by example. Always use pull requests for your own changes and actively participate in code reviews. This sets the tone for the entire community and reinforces the importance of the pull request process.

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.