4 ms·

This point of view seems to have a lot to do with programming as craft, and very little to do with programming as engineering. Nothing wrong with that, but mos

This point of view seems to have a lot to do with programming as craft, and very little to do with programming as engineering. Nothing wrong with that, but most developers are more concerned with the latter. Writing your own (compression routines|HTML parser|stepper motor driver|user interface controls|game engine) that's fast, cleanly designed, and bug-free is an act of craftsmanship. But if it takes a week and working around the quirks of one off the shelf takes an hour, and the resulting program meets the same requirements either way, it's the wrong engineering choice.

Annatar 8y ago
"But if it takes a week and working around the quirks of one off the shelf takes an hour, and the resulting program meets the same requirements either way, it's the wrong engineering choice." (Un)fortunately, that's not how the world works: it never takes an hour to get the work done even with the off of the shelf solution, and software which gets put together this way usually ends up needing to be babysat and the long term costs to maintaining it are exorbitant. Curiously, the quality of the software ends up being extremely poor not because of using readily available components, but because of the mentality of the people springing for such solutions. And somehow I have the impression that you and I have different defintions of "engineer": a programmer is not and never had been one. An engineer (which is what I do) gathers requirements, writes a technical specification based on those requirements, designs the software architecture which meets the specifications put forth, proceeds writing said software using scientific theories and principles (the actual process of engineering) and finally writes comprehensive documentation for that software.