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.

Goofing off and Meeting expectations

  1. 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

  2. many of my peers didn’t seem particularly motivated in their majors of choice.

  3. 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)

  4. Randal SchwartzĀ used to work at Intel. He surely knows more about it than both of us together

  5. 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

  6. ImageMagick is likely not known to engineers who havn’t done much photography, but the rest of my argument will not suffer from this

  7. much of what they do, like the pistons in some of their sneakers are actually quite difficult to produce

  8. I believe Intel’s internal IT software installer can include cygwin if desired

3 thoughts on “Goofing off and Meeting expectations

  • June 11, 2015 at 9:40 pm

    This post struck a chord in my mind (or to be more accurate, it did so more so than previous ones :-). My brand of goofing-off tends to take the form of writing code to customize my work env – either by writing various extensions to Emacs (where I spend most of my active work life), or by tailoring my shell or window manager to get rid of some annoying quirk that I find myself repeatedly working around. Along the lines of the comment that, “Most people I worked with at Intel didnā€™t spend nearly enough time goofing off”, I find that most people I worked with – Intel and otherwise – spent practically NO time optimizing their own work flows. This has always been a puzzle for me – how can a programmer (whose very existence is focused on replacing boring, repetitive steps with significantly fewer, more efficient steps) put up with boring, repetitive steps in their own lives?
    Just my own $0.02 rant…

  • June 12, 2015 at 8:33 pm

    I don’t know what the right proportion of time is, but the idea that one can spend all week just doing what he’s “supposed” to do is a farce.
    Frequently I find myself agreeing to do what I’m told to do, even though I know that I won’t. At some point in your career, I think you become experienced enough to make those judgement calls. Once in a while you might be wrong, but more often than not I’ve found that whatever deadline trickles down is arbitrary, and things end up getting done when they need to get done.
    Re: goofing off; the tools that I’ve written that have had the broadest impact, and ended up being used many years after their “best by” date, are those that I wrote because I was interested or curious about them. Three specific ones that I can think of are now used in some capacity by every major project across the company, and many of the small projects.
    Meanwhile, I’ve sunk thousands of hours into top-down initiatives that went nowhere. Precisely because they were top-down. In my experience, an good engineer who can also twiddle bits in perl can make a much bigger impact by solving real problems than a second level manager assigning a bunch of engineers to solve an imagined problem.

  • June 17, 2015 at 5:03 pm

    I’ve been away from Intel for 8 years, so who knows how much it’s changed since then. But my experience there, and my experience with interviewing MECOP candidates leads me to agree with the assessment that the horrible inefficiency of processes is rampant everywhere.
    I’d say that about half of the interns I interviewed who had worked at other places (Intel included) worked on automating tasks as their primary activity. HALF.
    I think it’s a worthy to accomplish that, but it’s a sad sign that so many core activities for these groups are not already automated.
    I, too, cannot understand how any self-respecting software person could sit by and NOT automate those repetitive tasks. Hell, it bugs me when I see colleagues type $ENVVAR/bin/executable -just make an alias for that!!! You type it 50 times a day at the least.
    I also recall a colleague at Intel telling me that about 50% of the design process was spent converting one file format to another. I’m sure that’s somewhat inflated, but there certainly was a LOT of that at Intel. Thankfully, at Mentor, very little of my job involves that – I do not miss it.
    Goofing off is important, as is promoting bottom-up ideas. Heck, my division was a bottom-up idea at Mentor and is now the largest and most profitable division.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Miles's thoughts