It looks like you majored in Electrical Engineering. Why not Computer Science? (2014)
As a developer, I get a version of this question a lot. The best answer I have does not explain why I didn’t major in computer science but why I did major in electrical engineering. For other developers who are asked, and who think about similar questions, I hope this re-telling is a useful description of why I chose to major in a technical field other than computer science.
I started college in the general discipline of engineering. An older student I looked up to said engineering majors were hard to switch into, and I lacked programming experience from high school, so engineering felt like a good place to start. My first class was Calculus 3, with a professor whose teaching I understood surprisingly well, from Harvard.
Stupidly, I expected a professor coming from a strong alma mater to be hard to understand. Coming in as a freshman, I thought that professors from Harvard (or Stanford, or Caltech) would be so focused on their research that teaching would be less important to them. Looking back, my most memorable professors were all from these schools, and they treated teaching just as seriously as research. A major factor in my being able to benefit from their instruction is the fact that Vermont is known as a beautiful place to raise a family; the scenery attracts people who are turned off from employment at one of the big 4 in Silicon Valley (Apple, Facebook, Google) or Seattle (Amazon). Thanks to living in Vermont, I was able to study physics under an MIT Phd, control systems under a Berkeley Phd, and Optimal Control, System Theory, and DSP under a Cornell Phd at a reasonable cost. Topics from these five courses surface from time to time (Calculus 3, admittedly, almost never does) in the machine learning and deep learning material I read today and I am grateful to have learned about them from people smarter than me.
After a year of satisfying general requirements, it became time to choose my engineering major. Civil engineers wanted to work with people, environmental engineers wanted to work outdoors, mechanical engineers wanted to work with machines, and electrical engineers, above all, seemed to want to work on hard problems. I wanted to be challenged but had neither the interest nor aptitude to build circuits and design sensors. In search of motivation in the engineering building, I circled the electrical engineering floor until I found a research poster without any pictures of hardware.
The poster featured Maxwell’s Equations, but as I continued down the engineering floor, I noticed another poster that had both LaTeX equations and code. Looking more closely at its future work section, it appeared to have an application I could understand — it was a scheduling algorithm. Intrigued, I set up a meeting with the professor directing the research and asked him if companies paid engineers to build algorithms like those he designed and analyzed as an academic. He plainly put forward the example of his own project, which was jointly developed with engineers and funded by their employer. When I asked him If I needed a math minor to be one of those engineers, he stolidly explained, “math is a requirement and a focus, not a minor.”
In this view, an electrical engineer minoring in math is a little like an economist minoring in finance. For most, finishing electrical engineering (economics) is sufficient evidence of strength in math (finance). This was music to my ears, because I did not like proofs, and I would have had to give up a senior elective in order to take the proof class that is required for math minors. I later took Feedback and Optimal Control as that elective.
“Electrical engineers who need higher level math study control or electromagnetism,” he clarified.
DSP, it would turn out, also had its fair share of math.
I lacked experience building anything with my hands, but he said this was in no way a hard requirement for electrical engineering: “You could work in electromagnetics, control, or maybe optics and never break anything physical, but if you’re interested in algorithms, you might try control.” I submitted my major declaration on my phone as I walked out of the building. For me, the definitiveness of working on hard problems coupled with the assuredness of learning more math and being able to apply it without ordering parts (by writing something called a computer program) was necessary and sufficient to call the search over and dive in. By graduation, I had taken every control course offered by the electrical engineering department.
The nature of my thesis was then not surprising. I wanted to work quickly and to use what I learned in my courses, so I programmed a randomized routing algorithm. With 62 agents having individual utility functions and competing for a variable number of packets at each epoch, the code I wrote took 35 minutes to run on the two core processor in my MacBook Pro. When debugging during the final weeks of my degree, I would insert print statements and nap until I could read them all at once when my script finished. If I had used the four core machine I have now, I don’t think I would have ended up with such a lean program. At the very least, the algorithm might have been flawed had it been prematurely relegated from the coveted top position in my mind where ideas are allowed time to gestate.
Comprehensible results in hand I left for the engineering building to put up posters for my thesis defense — the design and analysis of a routing algorithm. I presented the material I had developed and when probed was acceptably able to explain the result of adding additional states to the finite state automaton. It got me a job. But in hindsight I would go back and do research and electrical engineering if no one was hiring. I have been told by other engineers that I have an unnaturally long attention span to technical tasks. I attribute this entirely to electrical engineering.
If I had considered electrical engineering apriori, it would have been immediately eliminated based on the stressful connotation of the word “electricity”. But I didn’t do that; I first experienced engineering. For the student whose inspiration is unsteerable, deciding on a major is (generally) an NP-complete problem; if you’ve picked the right major, it (generally) becomes trivial to show this upon graduation, but there is no sure-fire way to quickly decide on any given major. It’s realistic to consider the (at most) first three school years before having to decide on a major to be linear in the number of possible majors. Without knowing how long it will take to find a solution, approximating one is the best bet. If you start with one discipline and move downwards, e.g. with depth-first search, you might run out of time diving too deep, missing a good approximation that was right in front of you. But if you go with breadth-first search, your likelihood of exploring every discipline and having the time to drop down one level to find and explore, in linear time, one of the few nodes in the tree of all majors that is an optimal solution, goes out the window. For this reason, I would advocate for the depth-first option. Repeated branching is an inevitability of decision making under a finite lifespan.
In the case of picking a major, it becomes necessary to graduate before the money-making years are squandered, and for some, the space of choices diminishes even more as those majors that if switched into would push graduation back become infeasible. In my case, electrical engineering was not obviously an optimal solution, but having graduated and learned a great deal I can mark it as one, and as is the case with any solved NP-Complete problem, a whole class of problems becomes efficiently reducible and solvable
Efficiently solvable is taken to mean solvable in polynomial time, so again there is no guarantee of finding a solution linear in the relevant entity, but it’s much improved from having no pre-existing information.
if that knowledge — the experience of choosing and graduating in electrical engineering — is re-used.
Something that becomes clear after programming for a while is that deleting large chunks of code in order to optimize a function from scratch is generally unlikely to produce a faster or simpler function. In a similar fashion, failing to re-use old knowledge on new problems, i.e., ignoring our profound ability to learn hierarchical abstractions, to apply solutions from old problems to new ones, an ability out of reach of even advanced ML methods — including DL — very much hurts the time complexity of finding a solution. This memorylessness of failing to learn from past problems is a wasteful feature. While inherent in machines, it can with ill-advised purpose be present in the decision-making of those who fall victim to starting from scratch.
It does not have to be so.
Rather than indiscriminately feasting on the opportunities provided by a campus of diverse professionals, it is wise to remember what you liked in high school, and consider starting there. If you liked math and didn’t program in high school, you might start in engineering, and you might move into electrical engineering. If you find you like it there, you might never switch out.
To go further, if you become a developer and write a short essay about your choices, please post it on the web so I might come across it.
I am still searching for a simple answer to the title of this article.
Thanks to Hailey Heston and Mark Rosenberg for reading drafts of this essay.
