Some day we will recognize that some areas of "programming" are very different and require different skill sets, and eventually different titles.
We tend to call everything "software engineering" so that everybody can feel proud of such a title ("I'm an engineer"), but engineering is certainly not about figuring out how to vertically center divs with CSS (and it's also not about proving algebra theorems either -- even if it can be essential when it comes to specific problems that require it).
I can't imagine Linux and PostgreSQL being built without "science", they use a lot of it, and I'm pretty sure the authors all have read SICP and those theoretical books.
Poking at things proved to be efficient to building things quickly, but it's just not how one builds critical systems/software that are robust, efficient and maintainable.
Engineering (no matter whether mechanical, electrical, software...) is the process of designing an artifact to be constructed out of available materials, which meets a set of requirements while minimizing cost.
In mechanical engineering you design your artifact using off-the-shelf bearings, motors, pumps, etc.
In electrical engineering you design your artifact using off-the-shelf cables, contactors, relays, VSDs etc.
In electronic engineering you design your artifact using off-the-shelf ICs, resistors, capacitors, resonators etc.
In IC engineering you design your artifact using off-the-shelf silicon wafers, etching chemicals, core/logic designs etc.
It's turtles all the way down, and software is no different.
Most engineers are working under some quantifiable or standard set of requirements, rather than ad hoc "make it work good and look pretty" requirements. Most engineering disciplines also have processes to ensure that its adherents take the proper precautions to avoid poor and unsafe designs, delivered in standardized sets of guidelines and recommendations.
And many programmers aren't engineers, they're just interested tinkerers; people who play around in their free time enough to know how to make something work. Not unlike if you went to the store, bought some wires and batteries and tools, and then played with them until you got hired as an electrician.
Sharing culture is instinctive. People will do it. You might as well try to tell people they can't have sex without your permission unless they pay first. Oh wait, that's the porn industry. Everyone pays for porn, right?
> I can't imagine Linux and PostgreSQL being built without "science", they use a lot of it, and I'm pretty sure the authors all have read SICP and those theoretical books.
Unless you restrict "authors" to the people that worked on the original Postgres95 (and maybe not even then), I'm certain that that's not generally the case (being a postgres committer and not having read SICP).
Software Engineering is more about methodically solving software problems than it is about which problems are being solved. A web developer who writes rigorous formal tests for a new page is engineering just as hard as an embedded developer writing rigorous acceptance tests for a board-support package. The engineering comes from the rigor and the fact that there is a controlled process for how software features get implemented.
I agree with that. The engineering process can be applied on every type of problem.
Yet, for that specific web dev problem, I haven't seen any way of formally testing the rendering web pages, which would make it consistent on every browsers. The testing process (almost) always leave that up to the developers themselves, and refreshing pages is the norm.
We tend to call everything "software engineering" so that everybody can feel proud of such a title ("I'm an engineer"), but engineering is certainly not about figuring out how to vertically center divs with CSS (and it's also not about proving algebra theorems either -- even if it can be essential when it comes to specific problems that require it).
I can't imagine Linux and PostgreSQL being built without "science", they use a lot of it, and I'm pretty sure the authors all have read SICP and those theoretical books. Poking at things proved to be efficient to building things quickly, but it's just not how one builds critical systems/software that are robust, efficient and maintainable.