[jacknews]

Of course understanding the requirements is essential, but the post effectively said the most important aspect of SE is to help the client business.

Imagine it's civil engineering, and we're talking about building a bridge.

To what extend does a bridge engineer need to understand regional trading patterns, and what bridge location and size would give maximum economic benefit?

To me that's a separate discipline to building actual bridges, and no amount of practice with different bridge designs or methodologies is going to be relevant to that, and vice versa.

[MAGZine]

I don't think you're making the point you think you're making.

You should absolutely understand what the purpose of the bridge is, what sort of things will be transported across it (trains? pipelines? weights? hazardous materials?), what sort of volume it will handle, what are the goals you're looking to solve with the bridge, what are acceptable and unacceptable tradeoffs? where are OK connection points, and where won't work (and how does it tie into the broader regional/municipal transit story)? I could go on...

you give most software engineers a bridge building problem and they'll build the bay bridge when all they needed was a simple suspension bridge for foot traffic.

[vlovich123]

> you give most software engineers a bridge building problem and they'll build the bay bridge when all they needed was a simple suspension bridge for foot traffic.

Care to give me an example in the physical world a case where overnight that foot bridge overnight suddenly becomes a highway off-ramp? Oh and suddenly we’ve realized that our highway motorists all need a place to park within walking distance of the hotel right nearby that we built last night? Also, there’s going to be spies looking for weaknesses in your bridge, robbers and invading armies looking to loot and pillage on a daily basis.

[jacknews]

I don't think you read what I wrote.

Of course engineers need to understand all the requirements for the bridge.

But coming up with those requirements, ie designing the economic/business case, is a separate discipline. As someone said, some of that may also be engineering; economic engineering, traffic engineering, social, political etc, but it is not bridge engineering.

[vlovich123]

Definition of software engineering I got from DuckDuckGo: The application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems.

> "Being able to understand the business of the customer and create software that helped them do that easier." I don't consider that software 'engineering' necessarily.

Economical and efficient processes and systems to help someone figure out how to do their business would seem to fall under that definition, no?. I’m curious if you did attend engineering school because part of my curriculum in being part of an accredited engineering curriculum was classes that explored what it’s like being an engineer. You have to prioritize public safety first, integrity of being an engineer second, making sure the business succeeds and providing your advice third.

I disagree with OP in that learning languages does help you be a better engineer. It broadens your exposures to different ideas and cost effective ways to write code to solve those problems so that you can make better recommendations. That’s equally as important (perhaps even more in the beginning of a career) to being a well rounded engineer as is understanding business needs and matters enough that dismissing it as “I could do the same thing in Bash” kind of misses the forest through the trees because technology choices to impact cost to build, test, maintenance, ability to hire talent, cost to train people, etc etc.

[dasil003]

Well, first of all, in your example bridge building is not the only civil engineering discipline involved—traffic engineers absolutely would be involved in those other questions.

More to the point though, software is not like a bridge. With a bridge, the high-level requirements are easily defined in a way that any layman can understand (weight limits, lane count, etc). Failure of a bridge is also viscerally obvious. Obviously there may be extreme engineering challenges in actually building a given bridge, but at the end of the day no one involved ever runs a serious risk of losing their handle on the big picture.

Software, by contrast, is arbitrary logic full of leaky abstractions and unknown touchpoints. Even if we narrow down to the most vanilla business CRUD app, precise requirements can be frustratingly elusive. No matter how well thought out a project, there are always discoveries at build time of any non-trivial project which significantly impact the requirements.

For this reason, I consider it a core responsibility for senior engineers to help define requirements and not just be a passive recipient of them. Martin Fowler captures my viewpoint more eloquently: https://www.youtube.com/watch?v=4E3xfR6IBII