[badminton1]

An abridged definition of engineering is "applying science to create technology". A software engineer applies computer science to create software based technologies. Under that definition you worked with programmers not engineers.

Then, true. You might have worked with programmers that seemed productive and learned on the job. But much of that learning happened at the expense of exposing the company and the customers to great risk.

For instance, if you are manipulating financial information, and you don't know what a floating point number is, you are eventually going to have a bad time. If you don't understand concurrency and parallelism, you might end up corrupting important data, if you are suffering networking issues and everything you know is HTTP at a high level... you are going to have a bad time. And the list goes on and on and on.

Friendly software development technologies were created to augment productivity, not to release people from the responsibility of knowing what is going on with them.

Now to your point, it is clear that not all computer science programs focus in producing highly-qualified software engineers. But that doesn't mean that you can simply skip the fundamentals.

[superswordfish]

Not all software requires the same degree of rigor in design and implementation. Software has bugs, but it sounds like you'd prefer if such software were never written in the first place. Regarding risk, it's as likely that the super-educated "engineer" drops unfiltered input directly into a SQL query as it is that Joe Programmer has the chance to corrupt data with a concurrency bug.

[badminton1]

Bugs and defects will happen at the time of implementing functional and non-functional requirements no matter how strong your preparation and problem solving skills are. But they differ since assumptions would differ in nature.

Many people would work on a problem until it works (or stops being an obstacle). But it takes some preparation to understand if an implementation is acceptable from a non-functional requirement standpoint.

[twblalock]

I never said anyone should skip the fundamentals. But you don't need to go to college to learn them.

Your nitpick on the difference between engineering and programming is ridiculous, and your definition of engineering is wrong.

[badminton1]

In the information age, given the right questions, you might eventually get the right answers. But you need to be able to formulate the right questions first.

If you do not possess a strong problem solving approach, you might not be able to formulate those questions in the first place.

Then, corporate interest aside, there are definitions of software engineering that are very clear. Refer to the IEEE definition of software engineer for instance, it might be more aligned to mine than to the "I feel like an engineer today" idea you are trying to push.