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.
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.
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.
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.
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.”
“Can we move the widget to the left side of the page” is not in the same category as “what is a hash” though?