The things that are expected of us have a great impact on our performance. Sometimes you have to do what you’re told. Sometimes it’s better not to.
I was comparing notes with my friend Trey about college. The computer science program he went through at Cornell was similar to my college experience. In particular, the class 6.001. (videos of the lectures can be found here) 1. Some other schools offer a variation of this class but either cover it in multiple semesters or omit much of the material. My point is not that MIT is so much better 2 In fact, I’d say that much of the teaching wasn’t that good. MIT professors get tenure for research and teaching is perhaps a bonus. (note Jeremy Wolfe). The biggest benefit I got out of being an MIT student was the extremely high level of expectation. The class 6.001, which covers more material in one semester than other good schools do in multiple semesters, is the first CS class encountered by students. “We expect you to do this. Figure it out.”
A second example (I’ll have a point eventually). I took a not very good calculus class in a not very good high school. I also spent a bunch of time over the summer before college with my nose in a calculus text. The things I learned lasted a lecture and a half of my first math class in college. “This is what we expect. Figure it out”. 3. A couple weeks into the class Prof Greenspan commented that much of the class didn’t seem to have a good grasp of one of the concepts. He passed out a handout, encouraged us to seek help from the teaching assistants, and then proceeded to continue at the same pace as before. Figure it out.
I’ve tried to maintain a high level of self-expectation throughout my career. Had I gone to a different school, I may have achieved a lower level of overall success only because I may not have learned I’m capable of as much.
Although I’ve often done what is expect of me, there are also lots of times that I do my own thing and that has also served me well. In my programming work, I often came across some unexplained behavior in the compiler or interpreter I was using. Perhaps a library didn’t really behave the way I expected. There is usually a work around to this but most of the time, I found myself compelled to really understand the mystery. More often than not, this resulted in a bit of not-so-useful trivia. Perhaps I’d find a bug. Not always, however, and the totality of the useful stuff I learned served me well and I became a better, more effective programmer overall. I thought of these hunts for the explanation as goofing off. I didn’t really need to know the answer, but I wanted to. The search was fun. This was particularly true about the Perl language, which is used a lot in Intel design. I can think of one person at Intel (a reader of this blog) who is probably as familiar with the ins and outs of Perl as I am. 4
Most people I worked with at Intel didn’t spend nearly enough time goofing off.
So, an example of a contrast. Intel has the best semiconductor process technology. I’d challenge you to find anyone who thinks that some other company can do it better. Intel’s designs are good, but not clearly better that those from other companies. My brother-in-law works in lithography of one of the cutting edge process nodes. 5 He works in a part of Intel that is better than the part I belonged to.
Recently, while hanging out, he asked for help converting an image file into something that JMP could accept. To me this sounded easy. ImageMagick has several conversion possibilities that could serve as a starting point. 6 One these gives something like this:
6,0: ( 1, 1, 1) #010101 srgb(1,1,1)
I removed the # comments and sent him the result for the sample image he gave me. JMP doesn’t like this format. It really wants tabs and really doesn’t want the ()’s.
I challenge you to find anyone in my department that would require more than 2 minutes for remove the ()s and swap the other stuff for tabs. If an interview candidate struggled with this, I’d hope we wouldn’t hire. Again, my BIL is in a leading edge part of Intel in a field that Intel is clearly dominating. To be fair, my department was mostly programmers for whom this stuff is easy but manufacturing involves a lot of automation, repetition,… the stuff that benefits from a bit of code.
I think it comes down to expectations and I’m getting closer to making a point. Before I do, I have another anecdote.
A guy I worked with in design used to be a technician in Intel manufacturing. One of the assignments he was given was a fairly repetitive task. Run a bunch of experiments for a week, taking data and come back with the results. He did this and was promptly asked to do the same thing on a different set of test batches. Fearing he’d jump off or a bridge at the thought, he automated the task and produced the same results in 4 hours, much of which was spent waiting for the computer to finish. With some simple automation, he reduced a task from a week down to half a day. This was not a new task; the old way had been the way for a long time.
On a recent neighborhood camping trip, I was talking to a former Nike manufacturing related engineer 7. Somehow JMP came up and I related these stories to him. “Same thing is true at Nike”.
These are not isolated incidents in an otherwise very capable portion of an industry dominating Intel division.
Intel’s technology development divisions are very high pressure with high results expectation… potentially at the expense of long term individual productivity. I did the file manipulations using Linux based tools but those same things are available on Windows through Cygwin 8. No one in process development seems to have the time or take the time to do what I call goofing off and learning these tools. Short term, there’s usually a way that will be quicker for the task at hand. Getting comfortable with scripting, grep’ing, perl,… takes some getting used to, especially for non-programmers.
High expectations can be wonderful (though it may not feel that way at the time), but they can also bite you. Be sure to spend lots of time goofing off.
sadly, MIT no longer offers this class. I really think that’s a big loss. It was a wonderful class. I suspect that part of the reason is that electrical engineering types often struggled with it. My memory of test results is that computer science majors would score somewhere in the high 90 percents while EE types would score closer to 60%. I know a couple folks that switched to mechanical engineering in part because of this. Either way, I think it was one of the two most useful programming classes I took. Algorithms/Data Structs was the other ↩
many of my peers didn’t seem particularly motivated in their majors of choice. ↩
That second lecture of 18.011 (which I don’t see in the current catalog) was taught by Harvey Greenspan using a book he’d written and culminated with a derivation of the Taylor Series expansion of e. One of the mid-term questions expected us to derive the series for Sin-1 (inverse sine) ↩
to me, lithography is one of those things that seems like VooDoo. I think: “Really, people do that?”, when I hear about some of it ↩
ImageMagick is likely not known to engineers who havn’t done much photography, but the rest of my argument will not suffer from this ↩
much of what they do, like the pistons in some of their sneakers are actually quite difficult to produce ↩
I believe Intel’s internal IT software installer can include cygwin if desired ↩