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.”