Today I was thinking about how small the knowledge intersection has been between my undergraduate courses and my jobs. I made a list of all the classes I found directly useful at either of my two jobs, and it was shockingly small.
Classes I found useful at my previous, finance job (in order of usefulness):
1. 6.111 - Digital Design Lab / FPGA-based design lab
2. 6.001 - Intro to ComSci with LISP
Classes I've found useful at my current, graduate school job (in order of usefulness):
1. 6.111 - Digital Design Lab, or FPGA-based design lab
2. 6.004 - Computation Structures, or Build a CPU
3. 6.002 - Intro to Circuit Design
4. 17.477 - Technology and Policy of Weapons Systems
5. 6.001 - Intro to ComSci with LISP
6. 6.041 - Intro Probability
I think a lot of the other classes I took, such as the math classes and signal processing courses, have had a large impact on how I think and approach problems, but I haven't used this knowledge directly in my day to day life. I was shocked that 6.046, my algorithms course, isn't on the list. I haven't used any of the important concepts from 6.046 in either of my jobs. Just the other day I wrote a one-liner for bubble sort when I needed to sort data.
I'm not sure why there are so few classes on the lists, but I was thinking yesterday about why my design class, 6.111, was so high on both lists. I think it has to do with the design project, which was the first "real" design project I ever had. In 6.001, the programming introduction course, there was also a design project, but 6.001 worked on the principle of building up proven components. You wrote something and checked that it worked. Building bigger things meant building up the system one proven component at a time. When you were handed code, you read through and tested the code to check that it worked.
Unfortunately real life is more messy than this. Components are usually too complex to verify for yourself, and sometimes you have to work around interfaces that were designed for another task. My 6.111 project had to deal with these issues, along with the issues found in building up a proven and known system. My team created an electronic version of Labyrinth, the old tilting maze game wherein one tilts a board to guide a ball through a maze to a goal, avoiding hole traps along the way. Not only did we create a pretty big custom system, we also had to interface our system with a lot of 3rd party components, including tilt sensors, circuits that converted the tilt sensors into something understandable, a VGA controller and an LCD.
This was the first time that something I created had to work with sloppy, complex components. The components we interfaced with included complex but standard interfaces, like the LCD, and sloppy and non-standard ones, like the components written by the teaching assistants for the course. I still remember, four years on, that the tilt sensors could enter an error state during the read-out. This error state required a lot of hand-holding to work correctly. I also remember fighting for a week with the start-up sequence because of nuances with the timing.
It makes me sad that none of the theory courses I took actually have anything to do with my job, but the theory courses that I took don't really have much to do with anything. I indirectly use this theoretical knowledge every know and then, but rarely directly. Whenever I do digital circuit design, for example, my tools use the graph algorithms that I learned in 6.046, but this is abstracted away from me. I don't think I've used a single academic thing I learned in my senior year. What a waste of money. Sigh.
