Of course, the underlying principles of engineering do not change, and these principles can be ingrained by hand problem-solving or by doing it on a computer. But engineering involves a good deal of technical knowledge as well. You can know Newton's Laws as well as the next guy, but if he can solve problems using Matlab and you can't, guess who is going to make more money? It's the technical things that get outdated very quickly. I spent a semester learning Pascal. It was the computer language of the future in 1987.
To start off, every engineering major had to take a year of Engineering Graphics. This involved drawing cones, cylinders, and other solids from various perspectives, using a little drafting kit you had to buy at the bookstore. They would show you a line and a cone, and you'd have to graphically figure out the two points where the line pierced the surface of the cone. This was not too hard for me, because I'd taken a year and a half of drafting in high school (against my guidance counselor's advice), but it completely defeated about 20% of the kids in the class. It was what we would call a "major weed-out class".
Engineering Graphics served me well indeed, because in my job interview with Honda, they asked me to draw a three-view of a little bracket, which I did quickly and correctly. I can guess they'd interviewed some people who couldn't do it, by the way the interviewers sort of smiled and nodded at each other when I finished. I also made a lot of piping drawings by hand at a co-op job. Though I've never hand-drawn a blueprint since then, it's handy to be able to sketch things. That was not a talent I was born with by any means.
We took a two-course sequence called System Dynamics, which involved calculating the dynamic response of systems such as car suspensions, servo-valves and thermostats. This was really important in the days when most controllers were mechanical. As my roommate said at the time, System Dynamics "is" mechanical engineering. By that, he meant you had to analyze a system with a useful function, not just isolated components.
The antiquated parts of System Dynamics were two. First, there was a heavy emphasis on analog systems that dealt in real, physical quantities like velocity and pressure. Nowadays, electronics are so cheap and adaptable that you use them wherever you possibly can, so all the controlling is done abstractly, by programming the controller. The other antiquated part was our use of analog computers to solve problems. In physics you learn about electric circuits that are analogous to mechanical or thermal systems. Well, in System Dynamics we actually built the circuits, excited them with a signal generator, and observed the solution using an oscilloscope. That's an analog computer.
The System Dynamics way of doing things extended into several other courses, including a measurements lab and an automatic controls course. I don't work in controls, so I can't say for sure, but I would bet that no controls engineer was using analog computers even back then.
The System Dynamics professor was fussy and made us write our reports by hand using a strict format. You had to buy special report covers just for that class, and plot up all your data on graph paper, by hand. You had to buy semi-log and log-log graph paper to do those kinds of plots, and then label your plots with adhesive labels. The guy was a stickler. If you failed to label an axis, or used the wrong kind of paper, you'd lose a letter grade.
At the very end of System Dynamics, we were introduced to a (digital) computer program, CSMP, that could be used to simulate some simple systems. Sounds modern, but you had to run this program in batch mode on a text terminal. You could get "graphical" output, but the program made it by printing characters. It built lines out of dashes and plotted points as asterisks. I had certainly used a PC before and was accustomed to running programs interactively, so batch mode was a real letdown. But the best part was the computer lab. The terminals were in a big room, all hooked up to an IBM mainframe in another building. You'd submit your job, and the output would be generated by a line printer (for you kids, a line printer is an impact printer that prints an entire line at a time instead of one character at a time.)
If it wasn't too busy, you could hear the printer roar to life as your program executed. So help me, it sounded like a lawnmower. The printers were not physically accessible to the users. A flunky behind a counter would fetch your printout from the printer. The printout would have your student ID number (same as your social security number; nobody treated this as secret). There were 100 mail slots, numbered 00 to 99, and the flunky would put your printout in the slot with the last two digits of your ID number. Then you would go up and fetch your 30 pages of green-white fanfold, discover you'd misplaced a semicolon in your program, and go back to the terminal to fix it. God almighty was it tedious. It's not uncommon for a buggy program to generate excessive output. Today, the output goes to the screen and you just hit Ctrl-C to kill the job. Back then, the printer would run and run, and eventually the flunky would kill the job and stuff the hundreds of pages into your box.
The last antique class I'll talk about was Kinematics. In this class, we learned graphical methods for solving kinematics problems. For example, to find the tangential component of a velocity vector, you'd draw the vector very carefully to scale, project it onto the tangential axis, and measure the projection to get the answer. It got more complicated from there. There were methods for designing cranks and linkages completely using these graphical methods. Needless to say, nobody designs anything using graphical methods any more.
Now, all those old fogeys who taught the classes would say that you learn the principles better when you do it by hand. And they may be right. Today, it's so easy to use a computer to generate mountains of numbers that some engineers start to think the numbers themselves are more important than what they represent. There's even a theory that the universe is really a big computer, the laws of physics are its software, and physical phenomena are its output. I think that's nutty, because while the fundamental laws of physics are very accurate, we have no evidence they are exact, and I don't know how we would know if they were.