5 ms·

This is very misguided. There is, fundamentally, always somewhere around an infinite amount of possible work that can be done. The most important thing in actua

This is very misguided. There is, fundamentally, always somewhere around an infinite amount of possible work that can be done. The most important thing in actually getting anything of value done is making sure that you get the right work done. Because if you get sucked into one or another effort sink (of which there are an endless variety) then you won't get anything of substance done. This is even more important in business, because while you're faffing about sinking precious effort (which is, remember, hard currency of the greatest value) into meaningless tasks the competition is getting ahead of you, and stomping on your face in the market, relegating you to insolvency and the dustbin of history.

gravypod 10y ago
I'm not saying don't do anything and sit around all day arguing. What I am saying is don't be mad, or ignore people, that come up and say "you could do X a different way and it would be objectively better for your use case"
- cortesoft 10y ago
  Here is my issue with people who come up and say "you could do X a different way and it would be objectively better for your use case" (note this is in a larger organization with lots of different teams, and I am talking people from other teams): They often don't really understand my use case. They only hear one part of what my team is trying to do, and then act like they know what I need. Yes, your suggestion works for the use case you know about, but not for the 10 other use cases I need to design for. Second, these considerations were usually already considered while we were planning this work, and there is a reason we decided to do it a different way. I don't have time to re-explain why we chose to do things the way we did to 10 different people who come to me and ask why I didn't choose to do it this other way.
  - gravypod 10y ago
    > They often don't really understand my use case. They only hear one part of what my team is trying to do, and then act like they know what I need. Yes, your suggestion works for the use case you know about, but not for the 10 other use cases I need to design for. So then can you not say "but I also have REQUIREMENT_X for this project? Do you think that your solution will mesh with this other need I have?" If you can't have a technical discussion defending why you feel your solution is the best then you must not be confident about your solution.
    - cortesoft 10y ago
      It's not about the ability to defend my solution, it is the time it takes to do it. My team is very busy with lots of things, we don't have time to re-explain why we are doing it this way to ten different people. We DO explain and defend our solution, to our boss and invested stakeholders, but we don't have time to do it again for every random guy on the other teams.
- mwfunk 10y ago
  I think if someone gets mad or ignores someone because they claim that the other person is bikeshedding based on a single comment or suggestion, that's most likely a misuse of the term bikeshedding. Bikeshedding is when an entire discussion gets bogged down or derailed by people who would rather talk about something that's not super relevant, than say nothing and let other people talk about a topic that's important but they personally have no expertise in. They would rather sidetrack a conversation so that they could be more involved, than sit back and let other people talk about the original topic. This makes sense for social situations (where what you're talking about is usually far less important than keeping everyone engaged), but makes no sense for situations where the communication really is about solving problems. You can really see this tension on more developer-focused open source mailing lists, where often a small number of people are working really hard on evolving some critical software, but their discussions get drowned out or derailed by precocious teenagers/overconfident CS undergrads/bored retirees who are just killing time on the list as a hobby, and who expend lots of energy trying to get everyone to talk about how terrible the variable naming convention is (or the source file directory structure, or source file naming conventions, or how much they hate this or that open source Internet celebrity person, or what's the deal with airplane food...) I can totally imagine someone who would dismiss as bikeshedding any comment that they didn't feel like talking about, but that person would be misusing the concept of bikeshedding (and probably being super rude on top of that, as it's an accusation against the presumed bikeshedder as well as a dismissal of what they're saying).
  - gravypod 10y ago
    > I think if someone gets mad or ignores someone because they claim that the other person is bikeshedding based on a single comment or suggestion, that's most likely a misuse of the term bikeshedding. I just see this as a way to justify that behavior. If it's not the indented use for the term then I agree some things are stupid but things that people I've worked with have cared about have came from real world concerns they have about technical choices. Maybe I'm just lucky? > but their discussions get drowned out or derailed by precocious teenagers/overconfident CS undergrads/bored retirees who are just killing time on the list as a hobby I think most of this can be sifted out easily. Why is X objectively better for the project as a hole? I've had project's where people have said "change this! change that!" For instance I was asked for one project, my StarmadeWrapper project, to look for a server in a different path then the one I had been checking. For instance I was checking "./StarMade/" for the .jar and they wanted me to check "./starmade" for the .jar. I said that it wasn't needed because it would break already setup servers and that it was already possible by editing the config file. They couldn't provide a reason for that to be done so I ignored the people suggesting this. This was a compatibility breaking change that could already be done on the side of the end user and fixed what amounted to making the end user run "mv ./StarMade ./starmade -r". This is in stark contrast to something else I was asked. Someone wanted me to make a maven .pom file for my project. At this point this person was contributing to the project and he made his case that "it would make it easy to import the project". I told them if you want it implement it since hell, it was a single file! These are the filters I apply to suggestions: - Does this make sense in a technical light - Does the person who is asking for this have the ability to write it by themselves - Will it break compatibility - Is it better then what I do currently The second change was technically sound, this person was a maintainer, it wasn't going to break anything, and it provided an easy way to work on the project. The first situation was none of these things.

gravypod 10y ago

I'm not saying don't do anything and sit around all day arguing. What I am saying is don't be mad, or ignore people, that come up and say "you could do X a different way and it would be objectively better for your use case"

cortesoft 10y ago
Here is my issue with people who come up and say "you could do X a different way and it would be objectively better for your use case" (note this is in a larger organization with lots of different teams, and I am talking people from other teams): They often don't really understand my use case. They only hear one part of what my team is trying to do, and then act like they know what I need. Yes, your suggestion works for the use case you know about, but not for the 10 other use cases I need to design for. Second, these considerations were usually already considered while we were planning this work, and there is a reason we decided to do it a different way. I don't have time to re-explain why we chose to do things the way we did to 10 different people who come to me and ask why I didn't choose to do it this other way.
- gravypod 10y ago
  > They often don't really understand my use case. They only hear one part of what my team is trying to do, and then act like they know what I need. Yes, your suggestion works for the use case you know about, but not for the 10 other use cases I need to design for. So then can you not say "but I also have REQUIREMENT_X for this project? Do you think that your solution will mesh with this other need I have?" If you can't have a technical discussion defending why you feel your solution is the best then you must not be confident about your solution.
  - cortesoft 10y ago
    It's not about the ability to defend my solution, it is the time it takes to do it. My team is very busy with lots of things, we don't have time to re-explain why we are doing it this way to ten different people. We DO explain and defend our solution, to our boss and invested stakeholders, but we don't have time to do it again for every random guy on the other teams.
mwfunk 10y ago
I think if someone gets mad or ignores someone because they claim that the other person is bikeshedding based on a single comment or suggestion, that's most likely a misuse of the term bikeshedding. Bikeshedding is when an entire discussion gets bogged down or derailed by people who would rather talk about something that's not super relevant, than say nothing and let other people talk about a topic that's important but they personally have no expertise in. They would rather sidetrack a conversation so that they could be more involved, than sit back and let other people talk about the original topic. This makes sense for social situations (where what you're talking about is usually far less important than keeping everyone engaged), but makes no sense for situations where the communication really is about solving problems. You can really see this tension on more developer-focused open source mailing lists, where often a small number of people are working really hard on evolving some critical software, but their discussions get drowned out or derailed by precocious teenagers/overconfident CS undergrads/bored retirees who are just killing time on the list as a hobby, and who expend lots of energy trying to get everyone to talk about how terrible the variable naming convention is (or the source file directory structure, or source file naming conventions, or how much they hate this or that open source Internet celebrity person, or what's the deal with airplane food...) I can totally imagine someone who would dismiss as bikeshedding any comment that they didn't feel like talking about, but that person would be misusing the concept of bikeshedding (and probably being super rude on top of that, as it's an accusation against the presumed bikeshedder as well as a dismissal of what they're saying).
- gravypod 10y ago
  > I think if someone gets mad or ignores someone because they claim that the other person is bikeshedding based on a single comment or suggestion, that's most likely a misuse of the term bikeshedding. I just see this as a way to justify that behavior. If it's not the indented use for the term then I agree some things are stupid but things that people I've worked with have cared about have came from real world concerns they have about technical choices. Maybe I'm just lucky? > but their discussions get drowned out or derailed by precocious teenagers/overconfident CS undergrads/bored retirees who are just killing time on the list as a hobby I think most of this can be sifted out easily. Why is X objectively better for the project as a hole? I've had project's where people have said "change this! change that!" For instance I was asked for one project, my StarmadeWrapper project, to look for a server in a different path then the one I had been checking. For instance I was checking "./StarMade/" for the .jar and they wanted me to check "./starmade" for the .jar. I said that it wasn't needed because it would break already setup servers and that it was already possible by editing the config file. They couldn't provide a reason for that to be done so I ignored the people suggesting this. This was a compatibility breaking change that could already be done on the side of the end user and fixed what amounted to making the end user run "mv ./StarMade ./starmade -r". This is in stark contrast to something else I was asked. Someone wanted me to make a maven .pom file for my project. At this point this person was contributing to the project and he made his case that "it would make it easy to import the project". I told them if you want it implement it since hell, it was a single file! These are the filters I apply to suggestions: - Does this make sense in a technical light - Does the person who is asking for this have the ability to write it by themselves - Will it break compatibility - Is it better then what I do currently The second change was technically sound, this person was a maintainer, it wasn't going to break anything, and it provided an easy way to work on the project. The first situation was none of these things.