"Answer the question, then propose alternatives."

I wanted to share a lesson I learned early in my career (for context, I'm a seasoned developer). On mailing lists in most companies, when people ask for specific advice, what ensues is typically a long cascade of people challenging the premise: why would you do that? Why would you do it that way? Have you heard of this cool open source project? I'm working on something really cool that's better than that thing you're using... and as often as not, after a cascade of dozens of such emails, no one will have answered the actual, specific question that was asked. This can be frustrating to the competent, talented people who know what they're doing and really just want to unblock their progress.

My guidance to all of the engineers I have mentored through the years is simply this: "first answer the question; only then explore the space." Providing a direct answer to the question asked is the cost of entry; if you can't answer the question, you should wait to respond - even if the premise of the question seems flawed.

I'd like to propose this as a guideline for the community. There are so many ways to achieve anything in this environment, and so many other interrelated concerns, that if we start by specifically and directly answering the question and only then broaden the context, I think we will create a better learning environment for ourselves.

Answer the question; then propose alternatives. In my experience, it really does improve the dialogue.



For the most part, this sounds like a good idea to me. But it's really hard when there's a question that presupposes a "bad" (I realize this can be subjective) way of doing things. For example, every once in a while, you'll see a question like, "How can I check the temperature of this sensor every minute and turn on this fan if it's above 75?" This is a poor match for the event-driven model of Hubitat, and in that case I'd rater just mention that in nearly all cases it would make more sense to watch for events from the sensor (and possibly fan) instead of a frequent loop that will cause the hub to do a lot of work all of the time for possibly no effect most of the time. While I'd probably still mention that either way is possible, I'd put the bulk of my effort into explaining the "better" (again, I know, can be subjective) way, as that will lead to a better outcome in nearly any possible use case. This particular kind of "better" can at least be objectively backed up (e.g., how many times will the rule/app wake up based on subscriptions and schedules, etc.).

So, along the lines of the above, I think that it's often best us to state our goal when we have a question, not just ask for one specific thing that might be possible but, without context, could be a bad idea (e.g., how can I do something every minute?). I suppose I'm getting sidetracked here...

But yes, I totally agree with what I think the point is here: just because you would do something one way doesn't mean that's the best way for someone else. I always--or at least always try to remember to--assume that the other person knows more about their environment than me. The behavior you describe from those mailing lists remind me of some posts you used to see here a lot. I think those have significantly diminished recently. We should all try our best to make sure we're not part of that problem. :slight_smile: Good reminder!


I agree 100% as well.... however I think of it in terms of etiquette. Especially when the question is likely coming from someone who is new or has worked on an for 6 hours and is frustrated.

I try to answer in as few words as possible. Often starting with "Yes" or "No" then go on to explain my position. I dislike it when someone answers a question with an explanation first and then the "answer" at the end of 1 or 2 paragraphs.

As for alternatives that you prefer I find it simple either:

  • I've had real good luck doing it this way.....
  • Alternatively you could.....

Fortunately I don't see it too much in this forum. For a while I was following the General Electronics in the Arduino forum. Some of those folks are brutal. Many times it gets into a pissing contest with two regulars and if I were the OP I wouldn't dare post there again :frowning:


statistically speaking, there are more newbies than competent and talented people.
so most of the time they looking at the problem from the completely wrong side and the alternative answer is the correct way to go for their own good.

there is an app on this link......,
it is more appropriate than throw at them RM4 concept they won't understand.

My approach is to offer the simplest or proven answer not necessarily what they asking for.

This is not a professional coders site. Most people here just automating home for fun.


Well, I guess I contest the assumption that newbies are not competent or talented. In my experience, even if they're thinking about the problem wrong, answering the question will help them understand why the alternative is easier.

I'm a relative newbie. Having to ask "how do I handle a virtual switch" five times across ten posts is not the quickest path to understanding.

In my experience giving unsolicited advice (like the OP or this post as well), even if well intentioned, is usually not well received or taken seriously. :man_shrugging:

Or if we are just throwing out sagely advice in general, I'll offer up "Buy low, sell high" and "Treat others as they would like to be treated. And when you don't know how they want to be treated, treat them as you would like to be treated until you know better".

OH! And "There are no stupid questions, just stupid people who ask questions".


I've assisted hundreds of users in another community forum and, given that I do this for free and not on an engineer's salary, I have no time or desire to entertain bad ideas/methods first and only then offer superior alternatives.

It's been my experience that presenting the superior alternative first not only saves time but the recipient is typically appreciative of learning a better way of doing things.

Simple analogy: If someone asks what's the best way to drive a nail with a screwdriver, my answer will be "It's best to use a hammer." There's little utility in explaining how to stab the nail with the butt-end of the handle or swing the screwdriver like a hammer.


I don’t want to detract from the value of the underlying principle in other contexts. I’m just not sure how, as a practical matter, this could become a guideline in an online forum like this one with thousands of users from around the globe and a pretty wide range of tech know-how.


I have a lot of gear-centric technical hobbies and for fun, I over-complicate many things in my life.

But even I can have a problem where I just want to buy something that works, or do things the simple way... and when I have a question and someone posts LOL just write your own driver it’s simple it’s the most irritating thing on the internet. So, I endorse the spirit of the OP: help people within the parameters they have laid out, and then add options... unless they are really making a big mistake. You never know where someone else’s line is, and if they tell you, try to respect it. What seems easy to you can look like black magic to someone else.


This is something my manager does to me and has changed the way I think of things. He wants me to identify the problem, then come up with a solution.

The solution itself may not be the best solution, but it forces me to evaluate the problem by taking a step back and noticing something I may not have noticed previously

Defining the problem is in of itself a problem and you have to get past that before you can hope to offer a solution.

I've noticed that sometimes a poster will be very stuck on the path they are on for whatever reason - usually it's because they have not provided adequate background to their issue or what exactly they hope to accomplish. There is an increasingly frustrated trail of posts until things are sufficiently sussed out so others can actually assist. Sometimes things turn sour and nothing gets fixed/solved.

Of course for those of us trying to help - Our solution may not actually be the "best" one or even an appropriate one for the problem. A thing I've been guilty of is misreading posts / glossing over the salient points and attempting to solve an issue that doesn't exist. This is why an active community with multiple posters is such a great thing.

We all can learn.. but it takes patience and understanding especially since we are all potentially up against cultural and language barriers in these forums for this cool international product.

edit: I would also say that not everyone is available all the time.. I've had posts go unanswered and I suspect it was due to the people willing/able to help not being online/available at that moment. Since there are so many active posts things get buried quickly.. nothing should be taken personally..

In the spirit of this thread. I think this is a fantastic idea. I have seen users become frustraded with the community over unsolicited advise on how this or that is wrong. And you should do this other thing instead never acknowledging the original ask.

I sometimes feel as of the community as a whole lives on both sides of the fence where the grass is always green.

Ask a question, point out a flaw, need a solution. If it is beyond the scope of what can currently be done, the average user will never want that and be confused, you should just buy x hardware, install y software and use z service. All of which require a much higher level of technical understanding than the initial ask.

Which leaves me somehow stuck without a solution between the average user who is "clueless" and having a full time hobby maintaining 9 OS, 12 dockers, and a github full of custom code.

1 Like

People offering advice are doing so on their own time and on their own terms (helpful or not) so you kind of "get what you get".. it is up to the requester to weed through and figure out what is relevant.

Most of the responses to requests for help I've read have been very helpful and those that weren't were usually quickly superseded by more relevant ones... thanks to the power of this community.

This seems very similar to the conversation regarding drivers and apps and user documentation.

The situation is a lot more complicated and subtle than it initially appears..