I am a chemical engineer who graduated with a degree in 1964. In my country, Argentina, that took 5 years. I’ve also taken graduate seminars in economics and administration, Bayesian inference and distance education.
I am already retired, but I still teach undergraduate and graduate courses associated with Operational Research. Therefore, my opinion is based on the needs of those teaching engineering.
The role of engineers, regardless of their specialty, is to construct mathematical models of the problems they face; simulate processes, business or projects, and develop tools for the optimal control of these processes. Therefore, in addition to a basic training in hard sciences, engineers must also know how to create computer programs that help them in their specific capacities. This is the only way to solve complex problems, especially the so-called “open problems” (ones that have never been solved before). It’s not hard, for example, to build a plant exactly the same as an existing one, but when you are building it in a different location, you are solving a new problem which has never been solved before.
Currently many engineers are able to take courses in informatics and low-level programming. Some courses are more in-depth than others and they sometimes fail to produce operational programs.
I believe that this is a deficiency of training which must be remedied. Regardless of the language in which codes are produced, what matters is knowing the philosophy and mechanics of creating computer programs to solve engineering problems. It is secondary that these programming languages also have a market value for third parties.
Many of the engineers I know that are successful in private activity ─ either in firms or as independent consultants ─ have their own programs to solve their workplace problems. Others use, sometimes with extreme confidence, electronic spreadsheets, ignoring that most have internal sources of error and are hard to audit. The Enron experience should be considered a warning.
Others use programming frameworks that require more or less coding effort and many use languages such as Fortran, C++ or Java, sometimes with a spreadsheet as front end framework.
Recommending what else should be taught seems easy. What isn’t as simple is recommending what should be cut.
In my opinion, if something should be removed from the teaching of engineering, it’s transient knowledge ─ for example memorizing standards and rules which are regularly changed. This process of memorization is fruitless.
What is valuable is to know that standardization exists. A good engineer should have his or her portfolio of existing standards on hand to help every time they select standardized equipment or components.
My experience in the first 20 years of my business career has taught me that all the practical knowledge related to the profession is quickly learnt from more experienced colleagues, foremen and workers who have a practical and timely understanding of each activity’s details. It is not necessary for the Academy to address this part of the training given that if it does, it means unnecessarily lengthening courses. Learning the practical details of each activity may take one semester for a junior engineer or a couple of months for a senior.
Finally, all engineering careers must teach to learn, considering that a graduate has a professional life of 40 or 50 years after graduation, during which time they must learn more new things of his or her specialty than concepts they learned in the classroom. Nowadays most of my teaching is about concepts and theories I have learned after graduation.
Of course, it sounds difficult to convince educators and college administrators about the imperative need to revitalize the system and to add new valuable knowledge.
Teachers are expected to learn more quickly than students. The good teachers are the ones who do research in their specific areas of teaching.
You Might Also Like
