Asking the right question is more important than getting the right answer | Hacker News Reader

Asking the right question is more important than getting the right answer

lemire.me

87 pointshardmaru14 comments

We all know the right answer is 42 ;)

Anyways, asking the right question is just a consequence, not a cause. If you are searching for the "right question", you won't find it, it is something that comes naturally with knowing about things.

In the penicillin example, he asked himself the right question "why did the mold kill bacteria" only because he knew about how bacteria and mold proliferate, and that he was confident in his experimental results.

To make an analogy, if you roll a dice and get a 7, you will definitely ask yourself the question, inspect the dice, etc... But that's only because you know that dices only go up to 6, that question is a result of you knowledge of dices. Now imagine you know nothing about dices, you wouldn't even ask yourself the question: the last roll was a 6, so why not 7. Worse, you may find yourself questioning the next roll, a 1, because by chance, you never rolled it before, and by the time you finally understand that it is normal, you have forgotten about the 7.

I wouldn't say it comes naturally. It comes from noticing points of confusion in the world and making an effort to ask the big Why? question.

And then refining your question to arrive at a different question, which may be a better question.

E.g. Why is my father in law so difficult to get along with -> Is my father in law difficult to get along with? Well, he gets along just fine with others... -> Why is it so hard for my father in law to get along with me? What is different about our dynamic?

One question leads you to the next, but you have to put some effort into the process.

An excellent book on the topic: A More Beautiful Question https://www.amazon.com/More-Beautiful-Question-Inquiry-Break...

Heya. This is only a minor point, but I thought you might like to know that "dice" is already a plural. The singular is "die". It's just one of those weird words, like "vertex" and "vertices", that don't fit the usual patterns we're familiar with.

On-topic, I agree with your broader point. There are times in development when I'm new to a subject that needs automation, and I'm trying to figure out what I should be doing. I can't really ask the "right" questions because that presupposes knowledge about the domain I'm supposed to be working with. It's a tough nut to crack.

Interesting but you can only know if you're asking the right question in hindsight when the right answer is generated.

Wholeheartedly agree, asking the right question helps in getting closer to the right answer. In my undergraduate Mathematics curriculum, "The Art of Problem Posing" (Brown and Walter) was required reading alongside "How to Solve It" (Polya and Conway).

Secret questions are why computer science advances by standing on toes not shoulders of Giants.

Secret questions imply differential reward to answering.

Secret questions imply harvesting public knowledge of public questions you know to validate the worth implications of holding your secret back.

"In mathematics, the art of proposing a question must be held of higher value than solving it."

- G. Cantor

I think this might be related to Eric Weinstein's discussion about excellence. (Eric works for Thiel Capital)

https://youtu.be/EzdLBGPidAM?t=28

Which must be why, during most tech interviews ...

the emphasis is completely the opposite.

A good technical interview should spend as much energy on the path as the solution, if not much much more.

My high-school physics teacher was always telling us to keep asking questions.

Not until later did I (happily) realize what a big damn radical he was.

"In computer science, we had the XML craze at the turn of the century."

I'm amazed at how much shade gets thrown at XML (still).

The biggest company in world (MSFT) defines their entire office suite in XML. SOAP on the wire is the most efficient M2M protocol for conveying strongly typed message payloads.

But to the Author's point, maybe some of the "questions" asked of XML were incorrect.

The biggest company in world (MSFT) defines their entire office suite in XML. SOAP on the wire is the most efficient M2M protocol for conveying strongly typed message payloads.

That does not point to a particular excellence of XML. XML was designed as a markup language and thus people came up with XML-based domain specific languages with which they could define trees of data and metadata for storage and payloads.

So, in effect, what these people are sending back and forth is trees with metadata. You can encode the same information in JSON or S-expressions, and people have already done all that. You just need to agree on conventions for the semantics but that holds even for XML.

XML has the benefit of wide support across platforms, good reference implementations originally, various standard schemas for different data, but technically it has nothing revolutionary: rather, as people who do know XML inside out it's overly complex as a base format for data encoding. Writing a parser compliant to the spce is not trivial.

XML's best feature is probably the fact that the complexity in the structure and syntax of the language is not enforced and you can easily keep your XML simple. That is what most people actually do.

The fact that you can define an office suite in XML is not particularly a merit to XML: Microsoft just decided to use XML to encode their previously binary documents in plaintext. It's not as if they couldn't have done it without XML but some other format, or, defining their formats in XML would somehow make the documents available for anyone to interpret who has an XML parser. The meat is still in the semantics which you have to implement in your export and import code. Whether those semantics are then applied in the form of JSON or XML or pickled Python dicts or whatever is the trivial part.

SOAP and OOXML aren’t exactly the greatest of examples of XML if your point is to defend it.

OOXML is so verbose (it’s actually dozens of XML files which are completely incoherent to a human reader) that it needed to be compressed into an archive. Microsoft use the ZIP format for that, so clearly they weren’t going for the best tech possible since otherwise they’d have elected to use one of the many newer and vastly superior compression formats. I’m fact the reason Microsoft moved their Offixe Suite to XML+ZIP is purely because they were ordered to adopt an open standard and they didn’t have any control over ODT et al so created their own competing “open standard” to OpenOffices (this was before LibraOffice was forked).

As for SOAP, most devs I know, myself included, hate using SOAP. And it’s certainly not the most efficient way of sending typed payloads - not even remotely. But it is one of the most widespread ways of doing it. However if the history of technology has taught us anything: being in widespread use doesn’t mean it isn’t also complete garbage.

I actually do like the founding principle behind XML; but as a specification it’s horrible to implement. As a human it’s horrible to read. And as an engineer, it’s horribly bloated. We have better formats for encoding structured data.

Reply on news.ycombinator.com