[eric4smith]

I’ve worked deeply with about 9 programming languages.

Not hobby level, but client work level.

They did not really help me to become a better software engineer.

What did?

Being able to understand the business of the customer and create software that helped them do that easier.

That’s why today I tell junior programmers that almost everything we do these days could be accomplished with Bash, text files to hold the data and static html files.

Don’t focus on the language, focus on the business case.

Sure some languages are more efficient than others but all those do is help you build a solution faster. And languages are similar for the most part - so that helps you learn new languages faster.

[jacknews]

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

Yes to be a more useful employee or more successful freelancer etc understanding the business case is absolutely an essential skill. But the 'engineering' begins once the problem has been defined; how do you actually implement the vision.

[wiseowise]

Their point still stands. There’s little that can’t be accomplished by any modern, general-purpose programming language.

[jacknews]

You can build it all with Church calculus, but the point of engineering is to create and then follow better methods to solve problems.

[RHSeeger]

This is what I see as the main point to get out of this. The larger your toolbox, the better you are able to solve problems. Learning new languages adds tools to that toolbox.

[ad404b8a372f2b9]

Defining the problem is a core part of engineering to me.

[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

[fabianhjr]

That's more on the project management side. (Initiating a project / gathering requirements)

[sicp-enjoyer]

You can write basically the same code with different syntax, or you can learn the paradigms, styles, and idioms associated with each language. That latter is the valuable part because it teaches you a new way to conceptualize and approach problems.

[deltasevennine]

That's because you've been learning languages that are similar. The algol family of languages with OOP.

You need to learn languages outside of this family to see the benefit. But the benefit won't be in your ability to do "business". It will be exclusively improvements in programming unrelated to "business programming"

>That’s why today I tell junior programmers that almost everything we do these days could be accomplished with Bash, text files to hold the data and static html files.

Why? Junior programmers are aware of this already. And get this: junior programmers are even aware that everything can be accomplished with assembly language. They are also aware why things aren't done in assembly, typically.

[gjm11]

> That's because you've been learning languages that are similar. The algol family of languages with OOP.

What makes you so confident of that?

I took a look at eric4smith's website. His current language of choice is Elixir, which is not in fact a member of "the Algol family of languages with OOP".

[deltasevennine]

That's one language. He said he learned 9. I'm betting out of the nine of those most of them are from the algol family and involve OOP. Yeah it's an assumption. My confidence is based on the fact that most languages are from the algol family and are OOP.

[mattmanser]

The GP didn't mention any languages, but if you open his profile it says 'Elixir developer'.

Maybe a brief bit of research before throwing stones next time?

[deltasevennine]

GP mentioned 9 languages. I'm betting most of those 9 languages are inline with what I said. Yeah it's an assumption, but it's a very likely one.

Second of all, no stones were thrown. I made an educated guess. Don't assume I'm "throwing stones", this is not an attack. Just a statement of my thoughts.

I would say the "throwing stones" comment was waay more accusatory and presumptuous then mine, and would indeed require verification before pointing a finger. But to each his own. Yes... I certainly admit I'm making an assumption about the 9 programming languages he learned.