Peter Kim FrankThis is a weekly roundup of awesome DEV comments that you may have missed. You are welcome and encouraged to boost posts and comments yourself using the #bestofdev tag.
The why branching on git is wrong article spanned 154 comments and was a real lightning bolt of conversation and debate. @nezteb took the top spot with an opinion that seemed to be shared by many in the thread:
@sergio shares a story in the You want HOW MANY years experience?! thread, talking about a consultant interview that took an interesting turn:
Reminds me of a funny story a coworker told me. He was interviewing someone for the position of Elixir consulting; basically we needed someone to vet certain choices we were going to make.
He's grilling this guy on Elixir and he's good, my coworker says. The meeting ends and later in the day he tells the team all about it.
Turns out he was grilling Jose Valim, Elixir's creator hahahahahaha
This is a story I'm never going to forget I still laugh about it.
The above comment was the basis for a #bestofdev thread titled Turns out language creators are pretty good at their language. That offered the opportunity for @tux0r to jump in with a similar story:
That reminds me of an older story:
Between 1969 and 1973, Ken Thompson created Unix with Dennis Ritchie. At the same time he also developed the C language. (...) Google hired Thompson to create a new language, Go. But Google also requires all of its recruits to pass a language test. According to Thompson, he hasn't quite got round to it yet - and so can't submit code.
Switching gears from language creators, @simonhaisz rolls into the Why you should reinvent the wheel discussion to add some context around the oft-repeated advice:
Maybe my experience is just different than yours, but normally when I hear/say "don't re-invent the wheel" it's not around "don't do X, it's been done" but more "you're trying to build X that needs a Y, there's already a good enough Y why not use that and focus more on making your X awesome".
If you are trying to build an app, why make your own database when there are plenty available for you to use? It's a distraction from building your app. Sure, if you want to build your own database to learn, or because you think you can build a better one, or because none of the existing ones meet your exact requirements. But if your goal is to build an app, why but focus on that?
Finally, An Organizer's Guide to Pronoun Buttons provided both valuable resources and an important discussion. @bintlopez does a great job of describing the fundamental importance of making proper accommodations for all attendees:
Names and personal connections at conferences and events are important. Are nametags and badges distracting? Are stickers and swag distracting?
If anything, it'd be super distracting to be at an event and constantly be misgendered or othered. Imagine how distracting it'd be to be at an event where people get your name wrong over and over again. Or imagine if you signed up to go to an event and the organizers didn't care enough to figure out if you had a dietary restriction -- it'd be pretty distracting to find out there's nothing you're able to eat for lunch and then scramble or go hungry for the event. Making accommodations for the people you're hosting is a key part of planning an event where people CAN focus on the subject matter at hand.
Also, if you don't care about what a person's pronouns are, why the resistance to using them?
See you next week for more great comments ✌
I disagree with most of this article, but respect that it works for you.
Any project I've ever worked on where multiple people are commiting to the same generic "development" branch results in lots of merge conflicts unless people are super careful to always pull the latest changes and merge master often. It's also difficult for audit purposes in the future because many features will be added simultaneously on every PR merge.
If anyone decides to try this, I highly recommend that you keep a changelog and follow some sort of commit message guideline.
In my experience, proper use of Git Flow, CI/CD tools, PR status checks, and merge conflict resolution as needed should take care of most of the issues you have with feature branching.
Some useful Git tooling: