The point is that in a real software engineering process, specs and requirements are rarely defined precisely from the start, and the programmer should be able to identify the gaps and clarify them. A generic answer doesn't help as much as a clarifying question.

A common but amateur mistake is to just make assumptions about how something should work and then forge ahead. As a programmer in a company, you are building things for somebody else (your boss, your client), so you need to ask them first.

[–] 1rre@discuss.tchncs.de 1 points 2 days ago (1 children)

Sure but as I said, that's a knowledge question and not an engineering problem to solve. They're very different and unless you work in software consulting, you're not gonna get a problem that looks remotely like that from a client.

[–] hirihit640@sh.itjust.works 3 points 2 days ago* (last edited 2 days ago) (1 children)

You actually get them all the time, because the programmer is more deeply knowledgeable about the features they wrote and can identify gaps better.

Boss: "Can we move the widget to the left side of the page?"

Programmer: "Sure but that means when the sidebar opens it will obscure the widget, making it hard to see both at the same time. Do we want that?"

Boss: "Hmm I didn't consider that. Let me ask the UX team what they think."

[–] 1rre@discuss.tchncs.de 1 points 1 day ago (1 children)

"Can we move the widget to the left side of the page" is not in the same category as "what is a hash" though?

[–] hirihit640@sh.itjust.works 1 points 1 day ago

I don't think the "what is a hash" question was a great example, but paired with the rest of the comment and context, I understood their point