First Week Impact

My approach to engineering craft has evolved to knowing when the easy solution exists and grabbing that instead of going with a complicated solution. Sometimes that’s a hack or sometimes it’s a different perspective.  A newbie’s perspective can often provide that different perspective.

Within my first week at Intel I surprisingly contributed immediately to my groups productivity. I had joined a group that did debug test on CPUs. They had a tool suite. This tool suite was a bunch of compiled code that worked with the tester’s API (A Programming Interface). The tool suite allowed us to interface with all the debug features of our CPU products. Which was great because you have a tool suite, you make your changes, you test them and then you release them. However, the build process was really really slow.

This was back when not every laptop had four cores in every single laptop. I was new and I had an EE by background and some software background. It’s my first week. I’m learning test equipment; I’m learning debug features of the silicon. Then I look at the tools, and I see how their building. I see how they make the tools; they’re using make. The make command built all of their C code one file at a time.  Well make can parallelize this, there are a lot of dependencies (but sometimes not) So I changed the make file to use multiple cores by simply adding “-j.”

make all  to  make -j all

Suddenly the servers that we had to compile our tools could compile our tools three to four times faster. Adding those two characters enabled the build process to use all four cores on the server. This was something that I was able to do in my first week that I joined the team.

Build process was not in my qualifications, or my skill set or my background. It was just something I had learned one time and I was able to apply it. Suddenly the entire team was more efficient. Because instead of building tools and go for coffee, or come back the next day they built the tools, answered email then went back to testing the tools they just built. The build time went from about ten minutes to a couple of minutes. And it’s amazing what that does to the development process. Because you can see if it works, and if it doesn’t work you get to build it again (naturally after you make the changes). Instead of a dozen iterations in a day you get hundreds of iterations in a day. For better or worse, LOL.

Q: What did the senior engineers in the group think about your change?

You know it made total sense once you thought about it, but no one had stopped to consider it. But they weren’t worried about the build process they were worried about the tools. They were worried about the tester and the API. No one had the outside perspective to think “what are we doing and how are we doing it? And what’s the best way to do it?” You’re new- you get to ask the dumb questions. Sometimes the dumb questions aren’t so dumb. Sometimes the answers have an impact.

Have a Productive Day,

Joe FitzPatrick

Dear Reader, please share your comments and stories that are sparked by this piece. Do you have a story of how a new engineer contributed to the team? Do you have a first month on the job experience to share? See Contribute for how you can share a story at The Engineers’ Daughter.

Additional Reading

Intel started off making DRAMS and in the 1980’s switched its focus to microprocessors, in this story referred to as CPUs (Central Processing Units).  To learn more about these types of computer chips read the following links:

Wikipedia article

Intel Microprocessor evolution

“Make” is a Unix command that compiles C code.  C is a popular compiled language that began in the 1970’s.

You may have heard of the origin of the word “bug” in computer programming. Grace Hopper found a moth in the – see here for more.  In her case the “debugging” was easy- remove the moth and the computer and its program proceeded fine.  In this story hardware debugging provides the context for this story. In coding there are debug hooks to show you what’s going on.  For hardware debugging to look inside the hardware you need to deliberately design circuits that permit you to look inside the hardware as it operates.  As there are a limited number of pins on a CPU, to access the inside of a device which has 100’s of millions of devices you need to scan them out.

Leave a Reply

Your email address will not be published.

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