if you hired a plumber, and asked him to fix the toilet, you expect him to fix the toilet.
You don't expect him to tell you your whole house's plumbing sucks, you have lead pipes and to properly fix the toilet you need to replace it all.
Just do the smallest, cheapest thing to fix the toilet.
Replace 'fix the toilet' with 'writing code', for programmers.
But software engineers are tasked with solving business problems. Ofcourse writing code is part of it. But other things too, for example communicating with users to understand requirements better, which lead to a reduction in scope, which reduced the code to be written.
Or sometimes it is found that a good solution can be devised but which satisfies about 80 percent of the requirements, and it may be prudent to attempt to negotiate to remove the 20 percent requirements which cannot be satisfied.
> But software engineers are tasked with solving business problems.
i would imagine that a business owner may want to hire a business analyst to undertake such a task, rather than a software engineer. Someone ideally with domain expertise in such business problems.
A software engineer is trained to produce software, given a set of requirements. If this software engineer is also tasked with gathering these requirements, which somehow, is increasingly the case now-a-days, then he's doing more than the job of a software engineer - he's also doing the role of BA.
A lot of the times, the BA gives you wrong business requirements, and an experienced software engineer can see it's wrong by reading it, and refuse to start it until the requirements are fixed. By "wrong", I meant there is a logical contradiction, or there would be harmful logical side effects because the BA can't play out the logic in their head, or it's technically impossible, or the development effort would not be worth it (for example, replicating what Google took years to build as a nice-to-have feature for an internal tool that isn't critical to the business).
Code isn't an output, it's just the final form of requirements. The software engineer job is just going from the informal talk about the feature to the formal nature of code that implements it. Yes, you can have an experienced person that broadly strokes the direction and have another less experienced programmer implements it, but there's no clear demarcation for the separation of role.
The real output is the shipped project, and sometimes your own code is only a tiny part of it.
I would absolutely love for the plumber whom I hired to fix my toilet to let me know what other crap I missed in my house's plumbing. Just doing the smallest, cheapest thing to fix the toilet is sometimes desirable but if it's just going to cause issues again soon, or if there are other issues I'm not aware of, I'd better at least start planning for those!