Many of the people I have had the pleasure to work with are "detailed oriented".... or at least that's what the claim. I consider myself one of those people too. But the more I think about it, the more I realize that there maybe moments we are just bikeshedding.

"Bikeshedding" is a term that comes from "Parkinson's Law of Triviality" which explains how an organization gives disproportionate weight to trivial issues. The term was coined from the example Parkinson used to illustrate the concept; If a committee is tasked with approving the plans of a nuclear power plant, they will spend the majority of their time discussing easy to grasp issues such as what materials to use for the staff bike shed rather than the more complex nuclear power plant. It's an idea that people will gernally have an opinion on the most comprehendable part of the problem while avoiding the more complex issue (ambiguity aversion).

Being detailed oriented can be a source of pride for many people. It is also a source of exhaustion for our colleagues. We don't like being a source of exhaustion for our colleagues. We generally like the people we work with and we want to ensure that any time spent with us is productive and collaborative and not a waste. That means balancing being a avid listener and a humble teacher but also identifying when we are just bikeshedding. Trying to reconcile when our obsession with the details is productive and when it's just bikeshedding is critical. But how?

Avoid tangents.

One of the first big signs that you are bikeshedding is when the item you are fretting over is tangential to the product but not directly focused on the product. For example, let's say we are working on a brand new feature for our product that requeres a new sexy UI. Suddenly, we are spending an inordinate amount of time discussing the merits of the color of some buttons but we have not even made a prototype of the feature yet. We have not even seen the feature in action but here we are talking about how the button color is not quite right.

Is the color of the buttons important? Yes. Well..maybe but the color is not the most important and complex part part of the feature! While we are fretting over the colors we have completely missed that the experiexce is extradorinarily slow.

When we find ourselves in a heated dicussion ask ourselves and others "what else could we be solving?". If it is truely the most important thing then there will be no other definitive answer but if the explanation is not clear or drags on then we are probably bikeshedding and we need to abort.

Going in circles.

We have all been in those meetings where the conversation not only veers way off course but we end up in a cicular discussion, hearing from everyone and their mother about the bloody thing. Lord knows I have instigated a few of those meetings; Some well meaning idiot (myself) makes a too assertive statement and the next thing you know we are in a circular discussion about how calling a class/struct a Manager vs a Supervisor is going to imploded the entire codebase.

The conversation goes in circles either until we are all exhausted, time runs out, or until someone with a bit more sense suggests we call it a "Mediator" and we never push that commit. Meanwhile the product is no better off and you have just wasted a lot of time and money.

Again, is naming the naming of the class/struct important? Yes. But if we are having cicular conversations it maybe a sign that the problem in focus is not all that meaningful or we need defer the decision.

When we find ourselves in these circular discussions be brave (even if you instigated it) and ask why we are discussing this? What is the impact of this decision? What are we trying to achieve? There will always be a reason but its all about impact.

The cart before the horse.

I personally find that bikeshedding is best understood as putting the cart before the horse. Even in Parkinson's example, the bike shed is important but not in the moment when the nuclear power plant is not even planned yet. The thing that makes the details so distracting is they are important but they may not be urgent.

It's useful to remember that timing is everything. Hell, even the first iPhone's screen was originally plastic and it was only after so much of the product was built that Steve Job's demanded it be glass. By that time (around 5 months from release) the products core features were either well defined or already built. Was the glass screen important? Yes. But compared to the software based keyboard or the multi-touch screen, any earlier dicussion would have been bikeshedding.

Being detailed oriented is only as good as the timing when you choose to focus on specific details.

Remember that the fine line between being detailed oriented and bikeshedding is about understanding the impact to the product, recognizing when we are focusing on inconsequential details, and understanding the timing of when to focus on certain details.

Caring about the little things is critical to a great product but worry about the curvature of the button when there is no screen to put said button on is not only bikeshedding its just plain stupid and I say that as being the idiot who has done it.