waynecolvin
Joined 16 years ago
Joined 16 years ago
Abstration can take many forms. But can often be described as "seperating things that change and/or repeat from those that don't", or something like that.
The last paragraph may be a joke, or based on one of the Principles in the O'Reilly Design Patterns [2] book.
[1] https://mitpress.mit.edu/sicp/ [2] http://shop.oreilly.com/product/mobile/9780596007126.do
Recommended reading: https://www.reddit.com/r/programming/comments/9nipa/joel_on_... ( https://www.joelonsoftware.com/items/2009/09/23.html )
http://www.paulgraham.com/avg.html
http://www.lessonsoffailure.com/tag/paul-graham/ <-- note "flamewar" in the title!
Dictionaries, sets and lists can be nice though.
Go here( https://www.thecodingforums.com/threads/performance-sets-vs-... ) and search-find "Terry Reedy".
The idea of "Software Engineering" was born with the Software Crisis report in the 1960's.
Later on practicing SE's would study things like Design Patterns so things evolved over time.
EDIT: Software Engineers probably should know some relevant basics, but programmers could never come up with a "body of knowledge" like real engineers have.
It all depends what you work on and what new developments keep coming out...
Admitting mistakes to move on, failing fast, should prevent prolonging arguements though (if you can pull it off).
Now you have me thinking about how to plan that long! You would need an architecture easy to port and good documentation...
Or become so important that old platforms are maintained for your sake!