Yes although many software engineers try as hard as possible to avoid learning what the business problem is. In my experience though those people never make great engineers.

▲

trimbybj 6 days ago | parent | next [-]

Often those of us that do want to learn what the business problem is are not allowed to be involved in those discussions, for various reasons. Sometimes it's "Oh we can take care of that so you don't have to deal with it," and sometimes it's "Just build to this design/spec" and they're not used to engineers (the good ones) questioning things.

▲

marcus_holmes 6 days ago | parent [-]

"Just shut up and push the nerd-buttons, nerd."

I went and got an MBA to try and get around this. It didn't work.

▲

lisbbb 6 days ago | parent [-]

I had a professor in grad school, Computer Engineering, that begged me not to get an MBA--he had worked in industry, particularly defense, and had a very low opinion of MBAs. I tend to agree nowadays. I really think the cookie-cutter "safe" approach that MBA types take, along with them maximizing profits using data science tools, has made the USA a worse place overall.

	▲	gibbitz a day ago \| parent [-]
		This

▲

lisbbb 6 days ago | parent | prev | next [-]

My problem was that the business problems were so tough on most of the gigs I had that it was next to impossible to build a solution for them! Dealing with medical claims in real time at volume was horrendous.

▲

ruslan_sure 6 days ago | parent | prev | next [-]

Understanding the business problem or goal is actually the context for correctly writing code. Without it, you start acting like an LLM that didn't receive all the necessary code to solve a task.

When a non-developer writes code with an LLM, their ability to write good code decreases. But at the same time, it goes up thanks to more "business context."

In a year or two, I imagine that a non-developer with a proper LLM may surpass a vanilla developer.

▲

tempodox 6 days ago | parent | prev | next [-]

Going by your first sentence, you must be working in a very bad environment. How can anyone solve a problem they don't understand?

	▲	skydhash 6 days ago \| parent [-]
		Hint: They don't They usually code for the happy path, and add edge cases as bugs are discovered in production. But after a while both happy path and edge cases blend into a ball of mud that you need the correct incantation to get running. And it's a logic maze that contradict every piece of documentation you can find (ticket, emails). Then it quickly become something that people don't dare to touch.

▲

pjmlp 6 days ago | parent | prev | next [-]

Usually this only happens to those doing product development.

When the employer business isn't shipping software, engineers have no other option than actually learn the business as well.

▲

sodapopcan 6 days ago | parent | prev [-]

I guess that really is a thing, eh? That concept is pretty foreign to me. How on earth are you supposed to do domain modelling if you don't understand the domain?

▲

victorbjorklund 6 days ago | parent [-]

How many % of software is domain modeled? Must me a small minority.

	▲	perrylaj 5 days ago \| parent \| next [-]
		Nearly 100%. They don't call it that or use that term, and almost never _design_ thinking about the domain. But the absence of a formal 'domain model' still results in domain modeling - it's just done at the level of IC who may or may not have any awareness of the broader implications of the model they are creating.
	▲	alexanderchr 6 days ago \| parent \| prev \| next [-]
		I’d say all (useful) software is modelling some domain.
	▲	pjmlp 6 days ago \| parent \| prev [-]
		Plenty if developed under consulting contract.