I would agree that [hiring on the basis of software knowledge] is often a problem. I see people who learn how to use a particular software package but are not able to tell when the answers are wrong. In process control (my field) loop tuning is a classic example. I have seen people with strong software and analytical skills use loop analysis software to come up with tuning parameters for PID loops that wreak havoc in an operating plant simply because they don't understand the difference between meaningful input and garbage (a thorough understanding of the loop and the process would often help too).

I've often heard this opinion [that it's easier to learn software after theory than vice-versa], however I believe it is just as incorrect. If you are talking about using a computer or a software package as an advanced calculator you are right. Once you get beyond that, there are fundamental skills and abilities for problem solving on computers that don't have a meaningful "by hand" method. I'd rather teach someone to use Fourier transforms than teach them to use UNIX pattern matching tools and regular expressions or to efficiently and effectively use search tools or bulk configuration tools.

Hand Calculations v. Software

Companies will hire those with experience with the software, whether or not those hires understand what the software does. On the other hand, if you can find a result by hand, you can learn the software. Is the reverse true? An engineer needs not only to be able to answer questions, but to ask the right questions.

It may be a caricature of engineers to say that older professionals are uncomfortable with computers, while younger ones accept what computers tell them without question. But there is a grain of truth there, and evils come in pairs of opposites -- in trying too hard to avoid the one you can fall into the trap of the other.

Those who've become dependent on spreadsheets and programmable calculators may find themselves unable to perform a hand calculation correctly on the spot if they need to. It's worthwhile to exercise our minds from time to time on problems that work out to known, or simple solutions -- those problems will quickly tell us if we're doing something wrong. On the other hand, those of us who can perform complex calculations in our heads have to remember to be humble enough to check our answers. :-)

As with any program, it's possible to perform calculations without understanding what they mean. Learning to apply complex programs involves concurrently setting up common problems you may not understand, and learning to understand those problems.

On teaching hand calculations v. software solutions:

• The teaching of software may best be left to higher-level undergraduates -- students of have at least *some* background in the calculations they're performing. It's not just for helping them recognize garbage -- whenever we teach students software, we're gambling that the package they're learning is the one they'll *use* out in the field. If we lose the bet, the student becomes the big loser.
• Students, and new hires, will use the conventions they see us using. Perhaps without a second thought given to how those conventions contribute to the correctness of what we do. We have to be careful about precision for that reason: too many significant digits and the student will get hung up on that level of detail.
• Instructors and experienced engineers might as well recognize that younger engineers will exceed us at some point in their software skill. We mustn't penalize them for it, but instead remind them to be critical.

Finite element analysis is a highly specialized type of engineering calculation, difficult (if not impossible) to verify by hand. Still, we can understand principles:

• Create a stiffness matrix for a simple structure. If it can be verified by hand, so much the better. :-)
• Point out the risk of numerical problems (e.g. unstable structures, redundant structures, large stiffness differences in nearby parts, etc.) and how to recognize them.
• Understand degrees of freedom and boundary conditions. Those are the most fundamental aspects of insight into structures.
• Be critical of outputs. Even guessing what the answer should look like in advance is an exercise that develops judgment.

Here's the difference between the engineer and the ordinary person:

Try being caught on a job site with only a borrowed four-function calculator (yours is in your briefcase which is still in your office). The contractor has asked you to resize a beam on the spot because he needs to order the material in the next 10 minutes and he has an expensive crew standing by waiting for an answer. If you don't know how to do hand methods then you cost your client lots of money. One more thing: your prestige among the construction crew will be enhanced if you can give an answer on the spot. They will think you a magician!

Shortcuts

People are naturally inclined to look for shortcuts in mathematical processes, especially repeated processes. One such example is the solution to a polynomial equation:

y = a₀ + a₁*x + a₂*x² + ... + a_n*xⁿ

can be restated as

y = a₀ + x*(a₁ + x*(a₂ + x*(... (a_n + x) ...)))

with a fraction of the calculational cost, depending on the length of the polynomial. Typical shortcuts may be covered in a course on analysis of algorithms, sometimes available in a computer science curriculum.

Example from Feynman: to square an integer near 50,

1. Find the difference between that integer and 50. Call it the "residual." (50 - 46 = 4)
2. Subtract the residual from 25. This gives you the first two digits of your final solution. (25 - 4 = 21)
3. Square the residual. This gives you the last two digits. (4^2 = 16)

Answer: 46^2 = 2116.

There are probably as many types of shortcuts as there are people to care about finding them. Charles Babbage proposed a mechanical computer that would accurately compute tables using the "method of differences" shown above.

Nowadays computational tools are so powerful that anyone can use them, sometimes without understanding what they're being used for! If engineers don't understand what they're doing they can quickly get tied up in a morass of calculations on even a standard scientific calculator that only does simple roots, logs and trig functions.

The computer is important as a precise calculating tool -- again, as long as we know what we're doing! The best way to ensure this is to work a known (and preferably simple) problem by hand before setting out to program a complex one on a computer; then perform a sanity check afterwards. The computer will otherwise draw you away from shortcuts and simplifying assumptions with its speed. Hand calculations are valuable if for no other reason than to prevent excessive dependence on a computer. Computers are themselves not always a shortcut; dependence on them can provide opportunities for defects.

The effects of computers on the way we work include

• Productivity in appropriate contexts. Unfortunately, we can run into unreasonable dependence and expense in others. Particularly contexts where we don't back our computer skills up with physical understanding.
• Efficiency in computation and filing. Unfortunately, not all tasks can be effectively reduced to computation and filing. Finite element mesh generation requires some skill above a button click, for instance.

Algorithms

An algorithm is the sequence of logical steps required to solve a specific problem. Good algorithms

1. Have deterministic steps. Two users following the same steps with the same numbers should get the same answer.
2. End after a finite number of steps.
3. Handle various inputs.

References

Feynman, C & M. The Pleasure of Finding Things Out. Cambridge, MA: Perseus Books, 1999. ISBN 0-73820-108-1

Contributors

Jon G. Amsberry, Jonathan Barnes, Dick Brewster, Jim Buch, LeAnne Davis, "engdisease," Glen Hadley, Wolfgang Hees, "Hephaestus," Richard Kowalczuk, Bob Kluck, Charles Madewell, Ed McBride, Doug Milliken, Bob Morrison, Rob Munach, Harley Myler, John Nichols, Timothy Parsons, stef pillaert, Andrei P. Popovici, Tony Prentakis, "scgatorfan," S. Joseph Spigolon, and "Steve"