Are you a scientist, or an engineer? This question does not seem to occur to most engineers, but it does seem science has “taken the lead role” in recent history, with engineers being sometimes (or perhaps often) seen as “the folks who figure out how to make use of what scientists are discovering.” There are few fields where this seems closer to the truth than computing. Peter Denning has written an insightful article over at the ACM on this topic; a few reactions are in order.
Denning separates engineers from scientists by saying:
The first concerns the nature of their work. Engineers design and build technologies that serve useful purposes, whereas scientists search for laws explaining phenomena.
While this does seem like a useful starting point, I’m not at all certain the two fields can be cleanly separated in this way. The reality is there is probably a continuum starting from what might be called “meta-engineers,” those who’s primary goal is to implement a technology designed by someone else by mentally reverse engineering what this “someone else” has done, to the deeply focused “pure scientist,” who really does not care about the practical application, but is rather simply searching out the causal chain. Along this continuum, there are any number (probably as close as Zeno will allow to an actual infinite) series of steps. Some further quotes from Denning will be helpful in understanding this a bit more. For instance:
Science emphasizes models, and engineering machines.
In this section, Denning spends a lot of time talking about how scientists work with abstractions, while engineers work with the details. For the engineer who is mostly dealing with implementing something someone else has designed, is mostly dealing with implementation details. What has been abstracted from this view is the theoretical underpinnings of why things work they way they do—sometimes even the end user’s goals are abstracted out, from this view. At the opposite end, the scientist has abstracted out the bits of reality that mask any sort of pattern, or cover up the causal chain.
So it is not a matter of abstraction versus details, but rather a matter of what is being abstracted out, and which details are being attended to. This is an important point because as you move up the engineering stack, away from the meta-engineering level, and towards a “more scientific” or “more mathematical” view, you must learn how to intentionally choose the abstraction you want to view a problem through. Part of the art of becoming a good engineer, or a good scientist, is learning to intentionally choose the abstraction you will use to find a solution to the problem at hand. The kinds of abstractions are probably different, but the use of abstractions, at the most skilled level, is probably very similar.
The strongest point Denning makes in this article is:
The result is curricula that encapsulate computing inside a boundary of math-science-theory and diminish crucial engineering aspects in architecture and design. This is unhealthy because most of the jobs for which our graduates are aiming are much more strongly oriented around engineering than science.
This is a major failing of both engineering and computer science education today. In the computer science department, network design is taught from the perspective of algorithms and causal chains. Over in the engineering department, network design is taught from the perspective of stringing together vendor provided bits of equipment. The two never seem to meet.
And yet, they should meet. Because it is when you learn both sides of the equation that you can truly learn how to be a great scientist or a great engineer, and how to reach across the research to application divide in useful ways.
The final point Denning makes is well worth repeating here:
Science and engineering need each other. Neither is the application or fulfillment of the other. Science emphasizes the discovery of recurrences. Engineering seeks to harness effects before the recurrences are fully known. Science moves in when the effect has proved useful and we seek to understand it better, optimize it, make it more reliable, and exploit its recurrences for prediction. Science takes care of abstractions, engineering the details that enable abstractions to work. The marriage of science and engineering in computing is critical for the continued health of the field.
It’s well worth reading the entire article.