A lot could be said on the topic of engineers and programming and what a baseline level of computing proficiency should look like. Almost no engineers I know receive even close to this during their undergraduate education.
Today, though, I want to point out how inadequate the curriculum was when I went through it (not that long ago). What follows is the grand sum of my formal (if you can call it that) computer science training during undergrad.
Exhibit A: Introduction to Computing (year 1)
This was the introductory computer science course everyone takes at Georgia Tech. For engineers, it’s the only required computer science course. You and two thousand of your closest friends suffer through a semester of standardized lectures and a weekly lab.
In this course, we programmed exclusively in pseudocode1. I think it is now taught using Scheme, but for my generation, we didn’t write executable code THE ENTIRE SEMESTER, perhaps with exception to a single Java lab the final week. We would write algorithms with hundreds of lines of code, yet never enjoy the satisfaction of watching it compile and run, the thrill of actually doing something!
I understand the debate about decoupling computer science theory from programming mechanics, but this was a clinical exposure to an area I’ve learned to love and found vibrant. I have a hard time accepting that I walked away from my only official CS class without knowing enough of a real language to whip up an algorithm to solve a problem when needed.
Exhibit B: Computational Modeling (year 2)
Here we have a basic numerical methods course featuring Matlab, taught within civil engineering. The instructor of the course actually said the following during the first lecture:
“Honestly, this class will only help you if you go into research.”
Real talk—this professor had an opportunity to paint a picture of the value of programming over software like Excel, but he discouraged us from engaging. What a lack of imagination. So I learned my way around Matlab in this course, but the message from the prof was clear: do the bare minimum to get by because this class is a waste of your time.
And perhaps the bigger issue? While Matlab is great, I think there are better tools for the practicing engineer (much more to come on that). I don’t know a single engineering firm using Matlab2—why become proficient in a very expensive tool that isn’t even used in general engineering practice?
The result?
A generation of engineers who:
- don’t have a working knowledge of a real programming language, and therefore…
- can’t develop even simple programs that would multiply productivity
- don’t apply algorithmic thinking in problem solving
- repeat manual processes ad infinitum that could be automated
- use computational software (Excel/Mathcad) basically as Paper v2.03
-
I get that a course set up like this is valuable for CS majors who will graduate with exposure to multiple languages and paradigms. I think the point is lost, though, on engineers who aren’t required to take further programming courses. ↩
-
Engineering firms I know primarily rely on two tools: Excel and Mathcad. I think the only (at least civil) engineering firms which license Matlab are serious consulting practices with research arms. ↩
-
What I mean by that is that engineers use Excel or MathCad like a sheet of paper in that it’s a sequential set of calculations that is ultimately printed and filed in project reports. The only reason it’s electronic is that you can change inputs and copy and paste. Logic and algorithms aren’t leveraged, and nothing is optimized for efficiency or reusability. ↩