Just today my AirPods case wasn't charging because lint got into my lightning port. I didn't realize the case wasn't charging until I realized my AirPods were low on power despite me charging the case a lot the last few days. Inductive charging is a lot more durable in a lot of ways.
I take my AirPods everywhere with me. They fit perfectly into a pair of jeans. They are one of Apple's best products in years.
I find myself listening to way more audiobooks and podcasts because of this. If I have a minutes to burn, I can just pull them out and listen. Also, AirPods are great for phone calls. I use them for almost every phone call, and having them always on me has changed how I interact with computing devices. If the Apple Watch ever really gets full featured (with more robust cellular features in particular), I could see myself often just having a Watch and AirPods with me, while leaving my phone behind.
The other things I would like to see Apple do are: Official water resistance ratings to better work for athletics and in the rain; and the ability to have different tips on them to increase fit for more people and to provide the option of sealing out outside noise.
This is the single biggest reason why I won't upgrade to the AirPods. For me, the AirPods simply fall out of my ears. That's why I stick with the Etymotic Ear Phonnes: https://www.etymotic.com/consumer/earphones.html
For whatever reason, that flanged shape fits my ears so perfectly well and blocks out all other noises that I don't see myself using any other Ear Phones for a long while. If AirPods provided the option of a flange shape like the Etymotics, then I'd be compelled to buy an AirPod.
It's frustrating and sad to see people do that. I was myself a "Right Way Guy" at the beginning of my programming for a few years, before I learned how much depth there is in CS besides junk like best practices and code style and how to focus on the only thing that matters - working code. They are often too convinced of their rightness.
Imagine a committee commissioned to approve plans for a Nuclear Power Plant. But the committee spends all their time discussing the color of the bike shed that they want built nearby.
In your case, their focus on separate VMs for QA/Production, systemd deployments, templating system for a few strings, and an ORM for a few SQL queries, especially for a project with a limited user base (10 people) really exemplifies Bike-shedding.
They’re emphasizing minor, arguably unnecessary details rather than the core functionality or purpose of the project [2]. This usually occurs because these trivial aspects are easier to understand and discuss, especially for junior devs, which leads to increased involvement on minor details while the more meaningful parts of a project (which might be more challenging to address), are overlooked or given less attention.
IMO, a good leader knows how to strike a balance between the “Right Way” and avoiding the pitfalls of “Bike-shedding”.
[1] https://en.wikipedia.org/wiki/Law_of_triviality
[2] I would argue complete documentation of the meaningful parts of the project is not bike-shedding.