Feels sorta pedantic.
Fun read nonetheless.
Feels sorta pedantic.
Fun read nonetheless.
In exactly the same way, a software developer isn't just hired to write code. We're hired to solve problems. We usually do that by writing code but that's not always the right approach. If your employer told you they wanted to be able to control a Windows computer from a different computer in the next room, I hope you wouldn't start writing code, you'd just show them Remote Desktop (or VNC etc.) If your employer wanted a web dashboard for your product, you might write a bit of code, but you'd try and find some existing dashboard project with an appropriate license, and hook your product's metrics up to that. Writing code is a tool, of course, and if there's no better way to do a thing (like if you're developing a new product) then writing code is going to be necessary, but a lot of times it's a tool of last resort.
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.
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.
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.
The real output is the shipped project, and sometimes your own code is only a tiny part of it.