Reminds me of a story a friend related a long time ago about how to manage bosses. That probably applies to bike sheds.
The general idea is to introduce a glaring mistake into any proposal you make. Then the boss (or whoever feels like bikeshedding) can "catch" that mistake upon which you congratulate them on their infinite wisdom, fix the mistake, and the project can move along.
So to avoid the bikeshed color discussion, just do something totally stupid, like not have a roof, or a wall, then the nit-pickers will comment on that, you can quickly "address their concerns" and proceed to have a bike shed of any color you want.
I’ve never had the mental bandwidth to try to manage my manager and team like this. While I don’t trust them to provide the best feedback, I also don’t trust that I won’t make mistakes. And what does it matter if I cannot control everything, unless too much risk is involved.
The color of that bike shed is distracting, though. Is it purple or pink?
> Although I’ve never had a boss that needed to find an error.
I think that is key. A great mentor early in my career pointed out to me: "A" rated people need to work for "A" rated bosses. It's possible to have a "B" or "C" person work for an "A" boss, but when you put "A" people under "B" or (god forbid) "C" bosses, all kinds of problems ensue.
[I've personally experienced that situation only once, and swore never again.]
I’m not sure what maps to “A,” “B,” “C” here. My gut says: “B” is the kind of person who you’d use this trick on, “C” might be too lazy and just not bother, and “A” might be confident and respected enough to say (and have everybody believe) that they checked and didn’t have any issues. Only “B” has that mix of insecurity and some ability…
Actually, I bet you could have an ok workplace with “A” workers under “C” management. Or maybe the “C” turns into an “A” if they manage to hire good people and get out of their way…
I guess it depends on what "A", "B" and "C" means exactly.
But the problem with "C" managers is that they won't judge "A" work as "A" work, won't understand why some of the "A" work is important, and will get in the way of the "A" engineers, making them go down "C" paths.
A "C" level manager brings the whole team down to "C" level and destroys the morale of "A" and "B" workers while they're at it.
An "A" level manager can guide everybody towards "A" level work.
I was writing software at a bank and found a bug. I was told to save it for when we had our audit —- because no matter what, the auditors were going to insist we fixed something and it might as well be something the development team wanted fixed too.
I’ve heard of contractors who leave electrical outlets out of their plans so that the building department, which will insist something be changed in the plans (proving the department’s usefulness), does not insist on something hard.
I mean, all banking software has genuine bugs team dont have time to fix. There is about zero reason to save a bug for audit purposes when you can just take something off jira.
This is often my pain as a senior dev. If the more junior members of my team propose something, and it's perfectly acceptable, if I just rubber stamp it then it looks like I didn't read it or do anything. So with some of the past managers I've had, I felt like I had to find something to point out, so best to find something that doesn't inconvenience the proposal author too much.
I could see the same dynamic in reverse when I had to propose stuff to the central tech team at that employer.
Some people do. It is silly and childish. However they do find some good things to speak up about once in awhile and they are least are not shy about those things. What we need though are people who will speak up about important things but have the gut so keep quiet otherwise - very few of those exist.
It is my firm belief that it isn't likely to find a the flaws in anything important (except for the obvious flaws intentionally left that other posters have mentioned) in the scope of a meeting. Once in a while you will by chance, but even if there is a flaw it needs some to look and think. People who think out loud often drive the meeting in the direction they are thinking and if there happens to be something in that direction they will find it sooner - but they miss the other directions others would have gone thinking in because they directed the thoughts of everyone.
Yes, but you're thinking far too literally. This is a negotiation tactic from the far reaches of history. Humans have always done this to manipulate one another.
You want something from someone else, at some cost to you. If you let the other party decline something you seemingly want, they have the impression that they're giving up less or are getting a better deal.
It's just compromise. Except you never actually wanted the thing you're compromising on and the ltjer party never cared about. It's just ticking the psychological boxes.
Yeah. It works wonders depending on the kind of people you work or deal with.
Some people will go through great lengths to find a flaw in whatever they look at, and once they see one they will keep asking about it continuously even if fixing it is something very counterproductive.
In the law school contract-drafting course that I teach, students read about "Combat Barbie" as a way of giving the other party's contract reviewer something to ask to be changed.
That's awesome. Having done a bit of contract ping-pong and karate (many times as collateral damage of one of the legal teams) as a founder, this makes a ton of sense, now :)
This point and the article is more interesting than the OP, IMO
The better version of this is to deliver something so big, that no one will read it. Put the good, the bad and the ugly in it. Make it huge, make it read like a mastrubatory PHD thesis...
The printed version, should, if dropped on a desk from about a foot, make a thud.
Then write the summary that is short, sweet, to the point, and nothing but glowing.
Every one will just smile and nod and agree with you.
It doesn't have to a mistake, it could be any other detail that you know would be disagreed with.
Comedy sketch writers would write a throwaway that was too off the wall to air, then include it in their proposal among others to make sure their darlings made it through.
I'm also reminded of the story of the Tetris contract in which a revision of the contract had an important change of a few words, and also an increase of some other fee. This fee change stole the attention and hid the other more insidious revision.
> It doesn't have to a mistake, it could be any other detail that you know would be disagreed with.
A friend's father who was an architect used to do that all the time. He'd submit a drawing that definitely wouldn't pass planning regulations, then go for a meeting with the planning officer and say "Right well how about we swap the swimming pool I am allowed to have, for the dormer windows that I'm not allowed to have?"
Given that even down south here at 56°N no-one really bothers with having a pool, it's an easy trade.
My late father solved the "getting round the planning department" thing by simply being the only person prepared to keep welding new floor pans into the local head planning officer's string of rusty old Opel Manta GTEs...
One more reason to opposed planning departments - too often they are focused on the wrong things. They need to ensure the fire department can rescue people if there is a fire. If my house has a dormer - that should be a first amendment free speech issue they have no interest in (assuming it is otherwise safe). However the looks are easy for someone to verify, while the important things need an engineer to spend time.
So if I buy the plot of land in front of yours and want to build my house as a 40-metre tower of rusted Cor-Ten steel with 1kW floodlights every metre or so, you'd be okay with that?
The version I heard involves a 3d artist adding an obnoxious fairy flying around the character, so not critical, but noticable.
I also think the idea here is to apply it to bosses who's self-worth seems to be tied to putting their mark on the product without being burdened by knowledge. (Because they'll want to change something regardless of the state)
That could work. It's like a variation of The Dead Cat Strategy.
"The dead cat strategy is a kind of misdirection where somebody will say something so ridiculous or do something so outlandish that it takes your attention away from where they don't want you to look. ..."
I’ve never done this and I’ve never told my team to do it.
What we have done though, and I will continue to do, js force us to leave things we want a decision on in a clearly broken/prototype state. The number of times I’ve gone into meetings to unblock a team only to have the whole thing derailed by a nothingburger bug that was hard to not see was the inspiration.
if you leave the UI element magenta with cyan font instead of default application style then you’ll actually get a discussion on your UI element.
> The general idea is to introduce a glaring mistake into any proposal you make. Then the boss (or whoever feels like bikeshedding) can "catch" that mistake upon which you congratulate them on their infinite wisdom, fix the mistake, and the project can move along.
As a programmer who perhaps has a little bit of OCD concerning code quality ;-) when I see such a mistake, I rather tend to dive much deeper into the proposal than when it looks "basically OK", because if there is one such glaring error, in my experience there often are at least dozens. And well, I indeed typically tend to find lots of them in such a situation.
TLDR: Depending on the personality traits of the person who reads the proposal this can be an insanely dangerous game to play.
Here is the thing. If you have a Convention Manual which calls for a certain color for bike sheds, then you use that. Failing that, if you have several other bike sheds of a certain color, then that's what you use, for consistency with existing bike sheds.
The color of the bike shed only doesn't matter if it's the only bike shed, and there is no documentation which has already settled the matter.
The rule there is that it doesn't matter how many style guides you have or tools to auto-style your thing or whatnot people will still find something to nitpick and argue about.
If the Convention Manual says all sheds shall be green they'll argue about what shade of green. If it says it should be Magellan Green they'll argue about whether it should be clear coated and what grit should be used to prepare the surface. It never ends. They'll argue about whether the window frames should be the same color etc.
We are a continuous learning organization, and selecting this bike shed’s color is an opportunity to leverage everything we’ve learned since the last bike shed project. It’s a fast moving space, and we’re a different team at a different point in time. The color we selected in the past may not be the right color today. In fact, this is an ideal time to consider a bike shed color transformation program to update all legacy bike shed coloring for consistency.
How boring to have all the bike sheds the same color. I've seen the end result of that - all houses in every direction are 100% identical, both the paint color and the facade in front. I guess they sold them, but I don't understand why anyone would want to live there.
Just be careful. Paint is very important on a bike shed. If you spend too long arguing you will end up with the weather destroying your bike shed. This was the point, but it is missing something critical.
Color is important even though it serves to objective purpose. Some colors blend in well making an ascetic whole neighborhood better - but even that way can go too far and you get a monotonous mono-tone which is worse than clashing colors! There is - and can be - no agreement on what is best (I'm color blind: I can see colors but not the same way most people do and so even if there was some objective perfect - it would still be different for me vs normal people), but we should spend some time figuring out colors.
The important thing is to give everyone time to think, then express their opinion in a way that everyone else listens to understand (as opposed to listen to rebut) and then we come to a good compromise - understanding letting someone else win is often the best compromise - things like meeting in the middle can be worse!
See also a rebuttal of sorts [1] from Brett Glass, the sole programmer singled out by name in phk's essay:
> Poul-Henning's assertion that all such ideas should be dismissed as "bikeshedding" reflects this dismissive attitude, which can be just as damaging to a software project as taking too many suggestions (or accepting bad ones). At the time of the discussion I mention above, internal squabbles drove several talented programmers from the project, and I was discouraged from becoming more deeply involved in it. FreeBSD was falling behind Linux in features and in popularity. While it has now caught up in terms of technology, it remains an underdog. This is, in part, due to the developers' dismissal as "bikeshedding" of good ideas that Linux adopted much earlier.
I feel like I'm missing the context of the sleep(1) debate and reading both points of view they seem like they're arguing for the same side? Would love for someone to cleanly explain both sides to this as I clearly don't quite get it.
It sucks to be called out by name in a document that’s been referenced continuously for decades. I would be surprised if whatever he said to piss off Poul Henning Kamp warrants that level of retribution.
The action itself is trivial, sure, but that and the quora answer itself kind of indicates the issue has been living in their head for at least 15 years, which is a rather long time for a dumb quip to be taking up any amount of mental space. Most people wouldn't even think of the idea of taking a domain name for the purpose of an internet argument. Granted, most people don't have that internet argument continuously referenced for decades, but I doubt 99.99% of later readership outside of the original mailing list were thinking about the name randomly being called out and were more interested in it solely for etymology's sake.
But it's not just a "quip", he mentioned some internal squabbles that discouraged him from contributing, so not a trivial thing to forget. It's also constantly reinforced as a meme, so hard to forget, so again the tiniest of axes works just fume to justify trivial actions like writing a response or getting a domain.
I write code and also cycle. I built a bike shed in my back yard. It has become quite difficult to search for advice on how to actually build a bike shed.
That's actually a great point. If this community keeps claiming building a bike shed is trivial, surely we can expect some good ideas. My acceptance criteria would include a solution for water damage, and anchoring - based on previous failed attempts to do that task :-)
How delightful, if you click on the picture of the shed it changes the background color of the page and the shed since it's a png with transparent pixels over the shed walls.
Reminds me of a story a friend related a long time ago about how to manage bosses. That probably applies to bike sheds.
The general idea is to introduce a glaring mistake into any proposal you make. Then the boss (or whoever feels like bikeshedding) can "catch" that mistake upon which you congratulate them on their infinite wisdom, fix the mistake, and the project can move along.
So to avoid the bikeshed color discussion, just do something totally stupid, like not have a roof, or a wall, then the nit-pickers will comment on that, you can quickly "address their concerns" and proceed to have a bike shed of any color you want.
I've heard this called "A Duck"
https://blog.codinghorror.com/new-programming-jargon/#:~:tex...
I’ve never had the mental bandwidth to try to manage my manager and team like this. While I don’t trust them to provide the best feedback, I also don’t trust that I won’t make mistakes. And what does it matter if I cannot control everything, unless too much risk is involved.
The color of that bike shed is distracting, though. Is it purple or pink?
Do people actually do this? It seems silly and childish. Although I’ve never had a boss that needed to find an error.
> Although I’ve never had a boss that needed to find an error.
I think that is key. A great mentor early in my career pointed out to me: "A" rated people need to work for "A" rated bosses. It's possible to have a "B" or "C" person work for an "A" boss, but when you put "A" people under "B" or (god forbid) "C" bosses, all kinds of problems ensue.
[I've personally experienced that situation only once, and swore never again.]
I’m not sure what maps to “A,” “B,” “C” here. My gut says: “B” is the kind of person who you’d use this trick on, “C” might be too lazy and just not bother, and “A” might be confident and respected enough to say (and have everybody believe) that they checked and didn’t have any issues. Only “B” has that mix of insecurity and some ability…
Actually, I bet you could have an ok workplace with “A” workers under “C” management. Or maybe the “C” turns into an “A” if they manage to hire good people and get out of their way…
I guess it depends on what "A", "B" and "C" means exactly.
But the problem with "C" managers is that they won't judge "A" work as "A" work, won't understand why some of the "A" work is important, and will get in the way of the "A" engineers, making them go down "C" paths.
A "C" level manager brings the whole team down to "C" level and destroys the morale of "A" and "B" workers while they're at it.
An "A" level manager can guide everybody towards "A" level work.
I was writing software at a bank and found a bug. I was told to save it for when we had our audit —- because no matter what, the auditors were going to insist we fixed something and it might as well be something the development team wanted fixed too. I’ve heard of contractors who leave electrical outlets out of their plans so that the building department, which will insist something be changed in the plans (proving the department’s usefulness), does not insist on something hard.
I mean, all banking software has genuine bugs team dont have time to fix. There is about zero reason to save a bug for audit purposes when you can just take something off jira.
I was taught to always speak up in every meeting by my boss at that time. Always, no matrer what, I had to come up with something.
If you do that, you'd do me a favour.
This is often my pain as a senior dev. If the more junior members of my team propose something, and it's perfectly acceptable, if I just rubber stamp it then it looks like I didn't read it or do anything. So with some of the past managers I've had, I felt like I had to find something to point out, so best to find something that doesn't inconvenience the proposal author too much.
I could see the same dynamic in reverse when I had to propose stuff to the central tech team at that employer.
Why not compliment them with a job well done? Add some details in your compliment that shows you've read their proposal.
Do you mean the babble hypothesis? https://en.wikipedia.org/wiki/Babble_hypothesis
That's exactly it! I didn't knew it had a name until today. Thanks!
Some people do. It is silly and childish. However they do find some good things to speak up about once in awhile and they are least are not shy about those things. What we need though are people who will speak up about important things but have the gut so keep quiet otherwise - very few of those exist.
It is my firm belief that it isn't likely to find a the flaws in anything important (except for the obvious flaws intentionally left that other posters have mentioned) in the scope of a meeting. Once in a while you will by chance, but even if there is a flaw it needs some to look and think. People who think out loud often drive the meeting in the direction they are thinking and if there happens to be something in that direction they will find it sooner - but they miss the other directions others would have gone thinking in because they directed the thoughts of everyone.
Yes, but you're thinking far too literally. This is a negotiation tactic from the far reaches of history. Humans have always done this to manipulate one another.
You want something from someone else, at some cost to you. If you let the other party decline something you seemingly want, they have the impression that they're giving up less or are getting a better deal.
It's just compromise. Except you never actually wanted the thing you're compromising on and the ltjer party never cared about. It's just ticking the psychological boxes.
It's extremely common in graphic design because it's so easy for everyone to have an opinion.
Yeah. It works wonders depending on the kind of people you work or deal with.
Some people will go through great lengths to find a flaw in whatever they look at, and once they see one they will keep asking about it continuously even if fixing it is something very counterproductive.
In the law school contract-drafting course that I teach, students read about "Combat Barbie" as a way of giving the other party's contract reviewer something to ask to be changed.
https://www.contract-rpm.org/#combat-barbie
That's awesome. Having done a bit of contract ping-pong and karate (many times as collateral damage of one of the legal teams) as a founder, this makes a ton of sense, now :)
This point and the article is more interesting than the OP, IMO
The better version of this is to deliver something so big, that no one will read it. Put the good, the bad and the ugly in it. Make it huge, make it read like a mastrubatory PHD thesis...
The printed version, should, if dropped on a desk from about a foot, make a thud.
Then write the summary that is short, sweet, to the point, and nothing but glowing.
Every one will just smile and nod and agree with you.
How does one do this without appearing incompetent?
It doesn't have to a mistake, it could be any other detail that you know would be disagreed with.
Comedy sketch writers would write a throwaway that was too off the wall to air, then include it in their proposal among others to make sure their darlings made it through.
I'm also reminded of the story of the Tetris contract in which a revision of the contract had an important change of a few words, and also an increase of some other fee. This fee change stole the attention and hid the other more insidious revision.
> It doesn't have to a mistake, it could be any other detail that you know would be disagreed with.
A friend's father who was an architect used to do that all the time. He'd submit a drawing that definitely wouldn't pass planning regulations, then go for a meeting with the planning officer and say "Right well how about we swap the swimming pool I am allowed to have, for the dormer windows that I'm not allowed to have?"
Given that even down south here at 56°N no-one really bothers with having a pool, it's an easy trade.
My late father solved the "getting round the planning department" thing by simply being the only person prepared to keep welding new floor pans into the local head planning officer's string of rusty old Opel Manta GTEs...
One more reason to opposed planning departments - too often they are focused on the wrong things. They need to ensure the fire department can rescue people if there is a fire. If my house has a dormer - that should be a first amendment free speech issue they have no interest in (assuming it is otherwise safe). However the looks are easy for someone to verify, while the important things need an engineer to spend time.
Okay, so no planning regulations at all?
So if I buy the plot of land in front of yours and want to build my house as a 40-metre tower of rusted Cor-Ten steel with 1kW floodlights every metre or so, you'd be okay with that?
You have a responsibility to not spill excessive light or other polution to my property. Otherwise yes.
The version I heard involves a 3d artist adding an obnoxious fairy flying around the character, so not critical, but noticable.
I also think the idea here is to apply it to bosses who's self-worth seems to be tied to putting their mark on the product without being burdened by knowledge. (Because they'll want to change something regardless of the state)
You just gotta pick mistakes that are plausible. The point is whatever you do the "bad boss" will find something.
The very competent can do this without the boss realizing ;) Or it's just a tall tale.
Spellcheck is a thing…
One strategically misspelled word placed somewhere around and neer the lower right of the page…
At least that’s the way some lawyers I know do it.
You have a typo there!
Everyone is incompetent, at least situationally.
Reminiscent of the Philip K. Dick short story "War Game":
https://philipkdickreview.wordpress.com/2014/06/04/war-game/
Reminds me a bit of the story about "bird mode" at google
[0] https://mashable.com/article/google-maps-origin-story-satell...
Wait Google Maps is not satellite photography it’s aerial?? I feel like I’ve been lied to.
It's a (mostly) seamless blend of satellite, areal, and ground photography.
That could work. It's like a variation of The Dead Cat Strategy.
"The dead cat strategy is a kind of misdirection where somebody will say something so ridiculous or do something so outlandish that it takes your attention away from where they don't want you to look. ..."
1 minute summary: https://www.youtube.com/watch?v=U3NvncA_oh0
I’ve never done this and I’ve never told my team to do it.
What we have done though, and I will continue to do, js force us to leave things we want a decision on in a clearly broken/prototype state. The number of times I’ve gone into meetings to unblock a team only to have the whole thing derailed by a nothingburger bug that was hard to not see was the inspiration.
if you leave the UI element magenta with cyan font instead of default application style then you’ll actually get a discussion on your UI element.
later: "how did this get built without a wall?"
Can't help but think that getting a good review is also important, not just avoiding friction.
What if they catch the roof, but everyone gets a little tired as the review goes on and they miss some small mistake you actually made?
> The general idea is to introduce a glaring mistake into any proposal you make. Then the boss (or whoever feels like bikeshedding) can "catch" that mistake upon which you congratulate them on their infinite wisdom, fix the mistake, and the project can move along.
As a programmer who perhaps has a little bit of OCD concerning code quality ;-) when I see such a mistake, I rather tend to dive much deeper into the proposal than when it looks "basically OK", because if there is one such glaring error, in my experience there often are at least dozens. And well, I indeed typically tend to find lots of them in such a situation.
TLDR: Depending on the personality traits of the person who reads the proposal this can be an insanely dangerous game to play.
Here is the thing. If you have a Convention Manual which calls for a certain color for bike sheds, then you use that. Failing that, if you have several other bike sheds of a certain color, then that's what you use, for consistency with existing bike sheds.
The color of the bike shed only doesn't matter if it's the only bike shed, and there is no documentation which has already settled the matter.
The rule there is that it doesn't matter how many style guides you have or tools to auto-style your thing or whatnot people will still find something to nitpick and argue about.
If the Convention Manual says all sheds shall be green they'll argue about what shade of green. If it says it should be Magellan Green they'll argue about whether it should be clear coated and what grit should be used to prepare the surface. It never ends. They'll argue about whether the window frames should be the same color etc.
And per Sayre's Law[1] the more inconsequential the decision, the more intense the argument will be.
[1] https://en.wikipedia.org/wiki/Sayre%27s_law
That's why academic politics /is/ so bitter, not /are/, god damn it!
:)
Not if the bike shed style guide is substantial enough to contains every possible detail that a human being can possibly ever observe.
Of course that can only work in a perfect world where spending millions of man hours compiling the ultimate bike shed style guide makes sense.
We are a continuous learning organization, and selecting this bike shed’s color is an opportunity to leverage everything we’ve learned since the last bike shed project. It’s a fast moving space, and we’re a different team at a different point in time. The color we selected in the past may not be the right color today. In fact, this is an ideal time to consider a bike shed color transformation program to update all legacy bike shed coloring for consistency.
How boring to have all the bike sheds the same color. I've seen the end result of that - all houses in every direction are 100% identical, both the paint color and the facade in front. I guess they sold them, but I don't understand why anyone would want to live there.
Wouldn't you change the color if there's existing bike sheds of the same? So you can reference them by color.
Wrong URL; it should be https://blue.bikeshed.com/
Or perhaps https://steelblue.bikeshed.com/ .
(For those who haven't seen, the site accepts any CSS color as a subdomain.)
Not sure those two really capture the essence. Plus you need to capture the luminance too. Something like <R,G,B>.bikeshed.com is what's needed.
It's pretty obvious that instead https://darkkhaki.bikeshed.com/ is the correct URL. Everyone knows.
SCNR
Thank you. You can expect my ophthalmologist bill in the mail, after I used "fuchsia". o.O
Just be careful. Paint is very important on a bike shed. If you spend too long arguing you will end up with the weather destroying your bike shed. This was the point, but it is missing something critical.
Color is important even though it serves to objective purpose. Some colors blend in well making an ascetic whole neighborhood better - but even that way can go too far and you get a monotonous mono-tone which is worse than clashing colors! There is - and can be - no agreement on what is best (I'm color blind: I can see colors but not the same way most people do and so even if there was some objective perfect - it would still be different for me vs normal people), but we should spend some time figuring out colors.
The important thing is to give everyone time to think, then express their opinion in a way that everyone else listens to understand (as opposed to listen to rebut) and then we come to a good compromise - understanding letting someone else win is often the best compromise - things like meeting in the middle can be worse!
This article has been shared at least 10 times before on HN over the last decade. Amazing to see people organically find it over the years.
These appear to be the interesting threads. Others?
Ask HN: How do you avoid bikeshedding? - https://news.ycombinator.com/item?id=30959723 - April 2022 (14 comments)
Why Should I Care What Color the Bikeshed Is? - https://news.ycombinator.com/item?id=29772108 - Jan 2022 (1 comment)
Why Should I Care What Color the Bikeshed Is? (1999) - https://news.ycombinator.com/item?id=12533079 - Sept 2016 (52 comments)
Bikeshedding - https://news.ycombinator.com/item?id=12403557 - Sept 2016 (31 comments)
Why Should I Care What Color the Bikeshed Is? (1999) - https://news.ycombinator.com/item?id=6188408 - Aug 2013 (31 comments)
Why Should I Care What Color the Bikeshed Is? - https://news.ycombinator.com/item?id=1739203 - Sept 2010 (2 comments)
Why Should I Care What Color the Bikeshed Is? - https://news.ycombinator.com/item?id=272246 - Aug 2008 (14 comments)
Why Should I Care What Color the Bikeshed Is? - https://news.ycombinator.com/item?id=25888 - June 2007 (4 comments)
Why Should I Care What Color the Bikeshed Is? - https://news.ycombinator.com/item?id=25888 - June 2007 (4 comments)
Wow, thanks, not sure how I missed that one! Added above.
Including this one, 34 times :')
Interestingly phk's own site has only been referenced once http://freebsd.dk/sagas/bikeshed/
See also a rebuttal of sorts [1] from Brett Glass, the sole programmer singled out by name in phk's essay:
> Poul-Henning's assertion that all such ideas should be dismissed as "bikeshedding" reflects this dismissive attitude, which can be just as damaging to a software project as taking too many suggestions (or accepting bad ones). At the time of the discussion I mention above, internal squabbles drove several talented programmers from the project, and I was discouraged from becoming more deeply involved in it. FreeBSD was falling behind Linux in features and in popularity. While it has now caught up in terms of technology, it remains an underdog. This is, in part, due to the developers' dismissal as "bikeshedding" of good ideas that Linux adopted much earlier.
[1] http://bikeshed.info/
I feel like I'm missing the context of the sleep(1) debate and reading both points of view they seem like they're arguing for the same side? Would love for someone to cleanly explain both sides to this as I clearly don't quite get it.
I don't think Brett was on the other side of the sleep(1) debate, just that he'd previously had disagreements with the author of this post.
Grabbing that domain, they must have quite an axe to grind. Not that the attack on them was any less childish.
It sucks to be called out by name in a document that’s been referenced continuously for decades. I would be surprised if whatever he said to piss off Poul Henning Kamp warrants that level of retribution.
Why? Isn't that a trivial thing to do so that even the tiniest of axes could justify?
The action itself is trivial, sure, but that and the quora answer itself kind of indicates the issue has been living in their head for at least 15 years, which is a rather long time for a dumb quip to be taking up any amount of mental space. Most people wouldn't even think of the idea of taking a domain name for the purpose of an internet argument. Granted, most people don't have that internet argument continuously referenced for decades, but I doubt 99.99% of later readership outside of the original mailing list were thinking about the name randomly being called out and were more interested in it solely for etymology's sake.
But it's not just a "quip", he mentioned some internal squabbles that discouraged him from contributing, so not a trivial thing to forget. It's also constantly reinforced as a meme, so hard to forget, so again the tiniest of axes works just fume to justify trivial actions like writing a response or getting a domain.
“Bikeshedding” is one of my favorite terms I’ve learned since becoming a programmer :)
I write code and also cycle. I built a bike shed in my back yard. It has become quite difficult to search for advice on how to actually build a bike shed.
Enlighten us!
What differentiates a good shed from a bike shed?
That's actually a great point. If this community keeps claiming building a bike shed is trivial, surely we can expect some good ideas. My acceptance criteria would include a solution for water damage, and anchoring - based on previous failed attempts to do that task :-)
The colour, of course.
Let's crowdsource that question on HN.
> What differentiates a good shed from a bike shed?
If my bike is there when I go to it.
How delightful, if you click on the picture of the shed it changes the background color of the page and the shed since it's a png with transparent pixels over the shed walls.
We are happy to be providing this public service :-). I wish the term were better known outside tech; it's useful in so many contexts.
Why can’t a site like this be reformatted so the text is viewable on mobile (at proper size)
> it is about being able to point somewhere and say "There! I did that."
This doesn't explain much since you can do that without personally arguing about the colors
It's incredible how "old-timey" the writing feels, even as someone who was online at that time.
Does anyone have a reference to the original thread or issue about sleep(1)?
way to shoot your own point in the head by making it unreadable and posting it a billion times ptui
(1999)