Bike-shedding, or the Law of Triviality, argues that groups of people will tend towards discussing trivial topics that are easier to collectively grasp, instead of discussing more important topics that are more difficult to collectively grasp, even if those important topics are the reason for meeting as a group to begin with.
The proverbial example is a committee meeting to discuss plans for a nuclear plant facility, wherein the majority of the meeting is devoted to how to build the bike shed, or, more comically, just what color to paint the yet-to-be-designed bike shed.
In software contexts its used as a warning to not get bogged down in the minutia of a software project when you are meant to be discussing more important topics.
The phrase "let's not bike-shed" is often analogous to "let's not lose the forest for the trees".
This problem is common in software because projects require many different tools, libraries, and external systems in order to exist. There are endless pros and cons when deciding which of these tools, libraries, and framework to choose. A software system is like a forest, and each of its trees are optional tools with pros and cons.
If you need to talk about the forest, talk about the forest. It's much harder to do than to say. And it is quite easy to say: "We're bike-shedding".
A classic example of bike-shedding is programming style/format. For example, in JavaScript, do you want to use semi-colons, avoid double-quotes, avoid parentheses around single parameters, etc.? You could talk as a team of engineers about this for a long time. The most common way to avoid this particular bike-shedding problem is via Prettier, an opinionated code formatter that lets you no longer think about the problem.