![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Edumacation
Oct. 30th, 2007 11:29 amSo, anyone who has known me for a long term has probably heard at least one rant about the University of Michigan. I'm going to soften that, by some microscopic amount, because I can point to at least one class I took there that has really furthered my career.
My first semester at Umich (incidentally, the only semester with a C average or better), I had a class named EECS 270: Introduction to Logic Design. We learned boolean algebra, what different logic gates there were, two-level logic, Karnaugh maps and all of that good stuff. Along the labs were infuriating, when the Asian grad assistant would rip all the wires out of your breadboard and tell you to "just try again," this seemingly inane material has been very helpful.
I work in computers. Logic design seems compatible, right? Keep in mind, I learned to build light flashers and counters on breadboards. That has about as much relationship to a modern computer as a bicycle has to a Maserati. However, I've discovered that between learning two-level logic and the set theory of SQL, I naturally tend to divide problems into really small bits that can be aggregated into a solution.
My wife will tell you: the projects that scare me are the big monolithic ones. If I can't figure out how to break it down into small enough pieces, I start looking for a place to hide. At the same time, every now and then, I will take a stupid simple thing, and complicate the hell out of it for no apparent reason. Here's the explanation of how, even if there still isn't any explanation of why.
I think it's sticking in my mind right now because I'm working with some guys that just don't break down their problems well. They will pick something and run with it, no matter how backwards it may be. The fact that I can see how stupid it is doesn't help anyone: I have to develop a process that keeps them from making this type of mistake again. Or, at the very least, I hope to dramatically reduce the incidence rate of this type of institutional stupidity.
Make sense? Probably not. It did in my head though.
My first semester at Umich (incidentally, the only semester with a C average or better), I had a class named EECS 270: Introduction to Logic Design. We learned boolean algebra, what different logic gates there were, two-level logic, Karnaugh maps and all of that good stuff. Along the labs were infuriating, when the Asian grad assistant would rip all the wires out of your breadboard and tell you to "just try again," this seemingly inane material has been very helpful.
I work in computers. Logic design seems compatible, right? Keep in mind, I learned to build light flashers and counters on breadboards. That has about as much relationship to a modern computer as a bicycle has to a Maserati. However, I've discovered that between learning two-level logic and the set theory of SQL, I naturally tend to divide problems into really small bits that can be aggregated into a solution.
My wife will tell you: the projects that scare me are the big monolithic ones. If I can't figure out how to break it down into small enough pieces, I start looking for a place to hide. At the same time, every now and then, I will take a stupid simple thing, and complicate the hell out of it for no apparent reason. Here's the explanation of how, even if there still isn't any explanation of why.
I think it's sticking in my mind right now because I'm working with some guys that just don't break down their problems well. They will pick something and run with it, no matter how backwards it may be. The fact that I can see how stupid it is doesn't help anyone: I have to develop a process that keeps them from making this type of mistake again. Or, at the very least, I hope to dramatically reduce the incidence rate of this type of institutional stupidity.
Make sense? Probably not. It did in my head though.
