Move fast and break things.
Merge vulnerabilities.
Double the work.
Merge code without tests.
Anything, but don't let code become stale.
this post was submitted on 14 Nov 2023
732 points (97.0% liked)
Programmer Humor
19821 readers
56 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I'm with you. I've worked on a few teams, one of the first was a company where two teams were contributing code changes to the same product. The other team "owned" it and as a result it took ages, sometimes months, to get code changes merged. It meant more time was spent just rebasing (because merging wasn't "clean") than working on the actual feature.
My current role, we just do TDD, pair programming, and trunk-based development. We have a release process that involves manual testing before live deployment. Features that aren't ready for live are turned off by feature flags. It's quick and efficient.
Fundamentally I think the issue is the right tool for the job. Code doesn't need to be managed the same way in a company as it does in an open-source project.
Open-source projects are usually longer lived more maintainable, more stable, and more useful than any closed source code I've ever worked on for a company. Partially because they're not under contract deadlines which create pressure to "deliver value" by a certain date, but still. Might be helpful for companies to consider adopting practices the open-source community has shown to work, rather than inventing their own.