## Secret Tools of the Engineering Grad Student, Part 3: JabRef

If you write academic papers, then you need to maintain a database of the references you cite. Assuming that you use LaTeX, this is typically accomplished by creating a BibTeX file that contains the needed bibliographical data. (Note that, in addition to identifying this particular data format, you may also see the term “BibTeX” being used to reference the software program that pulls information out of the BibTeX file and integrates it into a compiled LaTeX document.)

While it is possible to create a BibTeX file using nothing more than a text editor, it saves time to import such information into a program designed for this purpose. Always pleased to uncover free software, I’ve found the open source program JabRef to be a powerful citation manager. Many of the engineering article databases (Compendex, IEEEXplore, Web of Science, etc.) allow you to export bibliographical data for the papers they store. It turns out that there are many formats for exporting such data, but JabRef allows most of these formats to be imported directly into its BibTeX database.

Since JabRef runs on the Java Virtual Machine, it works with Windows, Mac OS X, and Linux. In fact, if you don’t want to be bothered downloading JabRef, you can launch the software over the web.

Alternatives to JabRef include Firefox extension Zotero, Mac program BibDesk, and commercial program Endnote.

[Update: I've been made aware of a program, SciPlore MindMapping, that takes a new approach to reference management. You can view a YouTube video about this application to learn about its features.]

Posted in Research Tools| Tagged , | Comments closed

## Secret Tools of the Engineering Grad Student, Part 2: LaTeX

If you are going to write a dissertation (or any other paper for that matter) with significant mathematical content, you will discover that the typesetting of your equations proceeds much better if you use LaTeX. While there is a steep learning curve, you will save a good bit of time down the road if you get comfortable with LaTeX (pronounced “Lay-tech”) early on. Here’s an equation for the Fourier transform rendered with this typesetting system:

This equation is created with the following code:

 F(f) = \int_{-\infty}^\infty f(t) e^{-j2\pi ft} dt

As you can probably figure out, mathematical symbols are created in LaTeX with text keywords preceded by a backslash. In addition to the improved typesetting, this means that you can quickly update many equations at once by simply searching for, and replacing, text strings. Thus, if you wanted to convert the above equation to be a function of g, instead of f, a simple text replacement would update all the equations in one fell swoop. Contrast this to the equation-by-equation corrections required if one is using MathType to typeset mathematics inside a Microsoft Word document.

While there are many benefits to using LaTeX, it does take a little getting used to. In particular, you may find yourself trying to control a lot of factors (margins, paragraph spacing, etc.) that are easy to modify in a word processor, but difficult to adjust in LaTeX. In the beginning, don’t worry about trying to control the output; focus instead on getting your equations to typeset correctly. Also, expect to spend some time searching for documentation. While most everything you will want to do has been done already, it sometimes takes a while to hunt down the correct command. (Hint: If you absolutely must play with the margins, use the geometry package.)

Significant time savings occur with LaTeX because templates for most publications types have already been defined. Thus, if I want to publish an IEEE paper, I simply drop my document into an IEEE template. Same paper in ASME format? Simply change to the appropriate ASME template. Need advanced math formatting commands? Use the AMS package. While similar templates are typically available for Microsoft Word as well, I often find myself hunting from paragraph to paragraph in Word, trying to discover why the formating has gone askew midway through the document. This is rarely a problem in LaTeX. And to produce my dissertation? Simply use the appropriate thesis style (your university may have its own format).

On my XP system (yes, I’m a dinosaur), I’ve had good luck using MikTex as my LaTeX implementation. One of the nicest features about the MikTex software (other than it being free) is that, when it encounters a package name it does not have, it goes out on the net and attempts to find the package for you. This has frequently saved me from having to install such code manually. While any text editor will work to generate LaTeX documents, I’ve always used WinEdt. Although WinEdt is not free, I’ve not regretted the \$30 it cost me for a student license, as it integrates quite nicely with MikTeX.

If you are interested in learning more about using LaTeX, there is some decent documentation on getting started available from the LaTeX project site, as well as the WikiBooks site. When you see references to “LaTeX2e,” this simply indicates the current version of the LaTeX program. Similarly, “LaTeX3″ refers to the next generation of the LaTeX software. Learning LaTex is initially frustrating, but you’re an engineering grad student. You’re not the type to choose the easy path. So download the software and give LaTeX a try. I suggest starting with a study sheet of equations for an upcoming exam. You’ll learn how to construct equations without needing to worry about paragraph formatting.

[Hint: Find an equation you like in Wikipedia? Right click on the equation and access the image properties. The associated text will be the LaTeX code used to generate the equation.]

Posted in Research Tools| Tagged , , | Comments closed

## Secret Tools of the Engineering Grad Student, Part 1: Desktop Search

Each engineering specialty makes use of certain software packages. For instance, in my area of automatic controls, just about everyone uses Matlab; those studying other disciplines make use of other topic-specific packages. However, certain tools (software and otherwise) will prove beneficial to just about any engineering grad student who must carry out research and produce a dissertation at the conclusion of their studies. However, these tools are rarely mentioned as key technologies for surviving as an engineering grad student. Over the next several posts, I will identify some tools that I had to discover on my own as I marched toward a PhD degree. Today’s category is desktop search.

You will undoubtedly collect a lot of information on your computer as a grad student. This will include papers, notes, programs, and presentations. Regardless of the software you use to produce or store such information, a good search program will help you quickly access data when you need it. During the course of my research, I have stored thousands of documents in various file formats. Often times I can remember an author’s name, or a keyword, but cannot recall which document contains a particular quote or data item. A search program allows you to quickly identify the information you need, regardless of where it is located on your computer’s hard drive.

An admitted Luddite, I still use Windows XP as my operating system, so I can’t speak to whether Linux, Mac, Vista, or Windows7 users require an external search program. I’ve had good luck with X1 Search, which I started using back in 2004, when this program was named Yahoo! Desktop Search. Then, in 2006, the association with Yahoo! was terminated, but a free version of X1 remained available as X1 Client. Sadly, the last free version (5.6.3, Build 3453) is becoming difficult to find on the web anymore. Although X1 is no longer free, there are other free options in the desktop search category that should work just as well. Regardless of which desktop search program works best for your situation, you will save significant amounts of time by being able to rapidly search through your research documents and retrieve key bits of data.

Although I wasn’t surprised at my need to search journal articles, I have been amazed at how often I need to go back to find a section of software code that I had previously written. Over the course of the past several years, I’ve created thousands of lines of Matlab code, and I occasionally realize that I’m starting to rewrite an algorithm that I’ve already sorted out. So I open up my desktop search program, limit my search to Matlab files, and start typing in relevant keywords. I’m almost always guaranteed to find the needed code within a few minutes. If you’re an engineering grad student, you’ll likely get good use out of a desktop search client.

Posted in Research Tools| Tagged , | Comments closed

## Bidirectional Translation

Happened to stumble across Mango Languages last night. It seems to be a nicely constructed site for language instruction. Once upon a time I worked for a firm headquartered in Germany, and had taken some company-sponsored language lessons, so I poked around in the first-level German module. One of the things I noticed right away was that translation was required in both directions. First, I was asked to translate from English to German. Then, after practicing a phrase, I was asked to translate from German back to English. This was easy for the first couple of phrases, but became increasingly difficult as I had to juggle more and more words in my head. I gave up halfway through the lesson as it was getting late, and my head was starting to hurt. However, someone fluent in both languages has obviously mastered the translation going in either direction.

All engineers deal at some level with the language of their particular engineering specialty, as well as the language of mathematics. Fluency in math provides magnificent tools for creating and analyzing new engineering methods. However, my recent experience as a graduate student (as well as two decades as a design engineer) leads me to believe that the emphasis is too heavily focused on the making the translation from physical reality into the language of mathematics. Once the math domain has been entered, there is little effort to move back into the physical domain. This seems to me a great oversight, as I consider engineers to be those who function primarily in the physical realm, rather than the mathematical domain. I love the beauty of mathematics, but I fear that the current generation of engineers may lack much substantive understanding of how to convert mathematical results into an enhanced understanding of physical realities. Many of my classmates fail to “see” how a problem solution relates to any real-world situation.

On the other hand, I frequently find myself struggling for hours trying to make the connection between a solution and its physical meaning. Often times the available textbooks and reference materials made it sound as though this connection should be immediately clear to the reader. It drives me crazy when technical material makes no concession for those of us who are not yet be completely fluent in the “language.” Since learning is a lifelong process, all of us should be constantly entering domains to which we have not been previously exposed. While the use of a particular method or technique may be plain-as-day to its creator, it’s often not nearly so obvious to those of us struggling to acquire an understanding of the new concept. So I suppose this post should serve as a reminder for myself to keep looking for better ways to describe technical concepts in a manner that novices can comprehend, and that experts will still find insightful. I’m not sure that it can be done at the same time, or via the same communication method, but surely there has to be a better way.

Posted in Instruction Methods| | Comments closed

## Narrative and Storytelling

While skimming through a year-old post over at edtechpost, I noticed the following reflection:

So I will forgive you if you ignore me from here on out as a perennial dimwit when I tell you that it took me this long to ‘get’ how crucial narrative and storytelling are to everything we are doing, be it learning online, connecting, weaving one’s online presence, blogging…

What really caught my eye was the phrase “narrative and storytelling.” Why are these factors not more frequently incorporated into the teaching of technical issues? While sitting through long lectures that cover intricate mathematical development, I often long to hear more about the context in which the methodology was developed.

• What problem drove the development of a new approach? These equations don’t just drop out of the heavens! Aspiring engineers need to understand that effective problem solving is within their grasp; that “correct” solutions are not just found in dusty old reference texts. Novel methods are driven by persistence and hard work—this reality is rarely emphasized.
• How long did it take to create, prove, and document the approach? It’s easy to get frustrated when the development of a new method hits repeated roadblocks. There needs to be some understanding of the hundreds (or thousands) of hours that are often spent in developing a new solution. Even though a proof can be sketched out in two minutes, the path from problem statement to solution is usually not intuitively obvious.
• Finally, a pet peeve of mine: All contributions are made by real people with real lives, not mystical figures existing beyond the earthly realm. Even if there is no time for biographical sketches of these individuals, what is the correct pronunciation of their names? Most engineers finally figure out that “Euler” is “oy-ler,” not “you-ler.” However, I’ve sat through many lectures where a theorem author is identified on the overhead slide, but their name is never mentioned aloud. And rarely have I heard any emphasis on correct pronunciation. This small detail seems central to allowing engineers to properly communicate with others in the language of mathematics, as well as providing some sense of human involvement. By the way, I often refer to the Mathematics Pronunciation Guide. How else would I learn that “Stieltjes” is pronounced “steel-tyuhs?”

Having taught college courses many moons ago, I am well aware that trying to incorporate contextual material into lectures means even more work for already overstretched professors or lecturers. However, I’ve come to the decision that it’s better to master a few topics than to be aware of many. A good story makes any topic easier to remember, and also promotes a richer understanding of the material.

Posted in Instruction Methods| | Comments closed

## A Mother Lode of Engineering Education Information

Happened across Dr. Richard Felder’s website today. Wow! What a treasure trove of information. It’s going to take me a while to digest this information, but I’m thrilled to see that the research exists. You can view an hour-long presentation Dr. Felder recently made at Penn State University, titled “Engineering Education in Five Years (or sooner).” Too bad we can’t see his slides most of the time, but an interesting talk nonetheless. My take away quote: “The power of the interactive tutorial is huge.”

Thanks to Teaching College Math for leading me to Prof. Felder’s site!

Posted in Instruction Methods| | Comments closed

## A Narrower Focus

As I enjoyed lunch with a friend today, he described a teenager that he has been counseling. The young man that my friend has been advising wants to be engineer. When asked why, the teen replied that he wants “to build things.” That’s certainly why I wanted to be an engineer. It’s also why I was so frustrated in my first two years of college. I didn’t understand what possible connection all of the math and physics I was “learning” had to do with making things. My father ran a machine shop, so I knew what making things looked like. It usually didn’t involve a lot of calculus. In fact, I worked in industry as an engineer for twenty years without ever having to solve a single integral.

This doesn’t mean that I didn’t need to understand math and physics. On many occasions I approximated an integral using Riemann sums, because I understood the integration concept. However, the connection between my engineering studies and the shop floor certainly escaped me for my first couple of years in school. I know many talented young people who got frustrated with engineering and quit because they couldn’t see the relevance of the engineering curriculum. Their youthful passions “to build things” were quashed for a lack of clear and direct communication about what engineers do and how they complete their assigned duties.

As I think about the future of engineering education, it’s easy to get caught up in interesting conversations about college costs, classroom technologies, and alternative certification. However, the problem I need to focus on is that of curriculum relevance. What does an engineer need to know in order to go “make things?” How do you make that knowledge relevant to an eighteen year old student? What are the key points that every engineer should remember and understand a decade after graduation? All in all, I need to narrow my focus and concentrate on these issues.

Oh yeah, it wouldn’t hurt to get my dissertation finished, either.

Posted in Engineering Curriculum| Tagged , | Comments closed

## Teaching Students to Learn in 3 Easy Steps

This past week I had the opportunity to attend an excellent workshop presented by Jeffrey Karpicke, who heads up the Memory and Cognition Lab at Purdue University. He makes the case that students don’t know how to study effectively. As a result, they spend hours and hours “laboring in vain”—performing tasks that produce absolutely no learning. This is understandable, he says, as the only guideline that most college students are given is that they should spend 2 to 3 hours “studying” for every hour they spend in class. Without additional guidance, they tend to confuse comprehension with actual learning.

What constitutes studying in the minds of college students? More than 80% of the students that Dr. Karpicke and his colleagues surveyed listed “rereading notes or textbook” as a study method, and more than half identified it as their preferred strategy (see Karpicke, Butler & Roediger, Memory, 2009). Unfortunately, rereading has absolutely no benefit; time spent rereading material is wasted (see Callender & McDaniel, Contemporary Ed Psych, 2009). So students are losing precious time on ineffective study methods. Dr. Karpicke tells his students that they can substantially improve their learning by spending 45 minutes each week performing three easy steps:

Step 1: Collect and Organize — Encourage students to organize their grasp on a subject by creating their own outlines or self-study guides. This is something I have always done in my studies, but only 24% of students surveyed by Dr. Karpicke carry out this process.

Step 2: Assess Comprehension — Students often confuse familiarity with comprehension. To get beyond this, students should try explaining concepts in the absence of notes or textbooks. When presented with central topics or keywords, they should examine what comes to mind. If they are unable to produce an accurate response, or are unsure of an answer, then this is an area where they need to “study.” This step is carried out by only 13% of the students surveyed by Dr. Karpicke.

Step 3: Practice Retrieval — Long term learning requires more than comprehension; repeated retrievals of the material are required to ensure that the information is not forgotten. Have students pull out a blank sheet of paper and write down everything they can remember about the topic. Encourage students to use flash cards. Knowledge retrieval is often seen as “neutral,” a process that does not modify or alter the learning process. But Dr. Karpicke claims that the act of retrieval itself produces learning. (see Roediger & Karpicke, Psychological Science, 2006) What percentage of students carry out self-testing? Less than 11%.

Most scary is that students who utilize rereading as a study strategy are over-confident about their learning, while those that practice active retrieval are under-confident. Making a rough estimate from the graphs that Dr. Karpicke displayed, it appeared that rereaders are about 20% more confident in their “judgment of learning” than are self-testers, but perform about 35% worse when tested. Thus, it may be quite useful to discuss potential test questions during lectures, so that students begin to assess their comprehension, and have appropriate lines of thought for self-testing. One of the workshop participants stated that he has students submit potential test questions as part of their homework; this forces them into the beginning stages of self-assessment.

How much do we really remember from our college days? Some big concepts, for sure, but many of the small details are quickly lost. For a humorous look at this topic, watch Father Guido Sarducci’s Five Minute University.

Posted in Instruction Methods| Tagged , | Comments closed

## Lessons Lost to Time

Since I live more than an hour’s drive off of campus, most of my research takes place from my spare bedroom. Internet access is a wonderful thing, as I can search through vast libraries of knowledge without leaving my computer. One downside to this comfort, however, is that most of the databases I use on a regular basis do not house articles published before about 1990. In most cases, any journal issued before then has to be tracked down at the library. Of course, for me, that’s not a simple walk across campus.

My adviser noted one day that the situation isn’t much different for the grad students who live closer to the university. After commenting that nobody wants to spend time digging through the library stacks to pull out old articles, he said, “We’re going to spend the next twenty years rediscovering what was published forty years ago.”

Posted in Grad Student Life| Tagged , | Comments closed

## Adding to the Curriculum

While trying to get more informed on how engineering education can be improved, I thought I’d post my “newbie” perspective on what subject material needs to be added to the core engineering curriculum. As illustrated above, there are at least six areas that I think deserve greater attention. These are, in no particular order:

• Software Skills: As I mentioned in Programming the Physical World, I think that software skills are going to become exponentially more important in coming years. I’m not talking about knowing a particular language syntax, per se, but rather an awareness of issues such as code storage (revision control), quality assurance (unit testing), and complexity reduction (refactoring). It’s far too easy to create software that gets the job done, but leaves gaping holes with regard to access, usability, and security. Just look at the constant stream of code updates from big players like Microsoft, Apple, and Adobe—these companies have access to world-class programmers, yet there remains an unending flow of corrections to fix previously undetected errors. Just this week, Microsoft admitted to a security bug that’s been in their code for 17 years! As we start programming the physical world, it won’t just be bits and bytes that are compromised. It could conceivably be bridges and electrical stations and chemical plants that are compromised as the result of poor programming practices. As with so many things related to engineering, a small mistake can lead to disastrous results. It seems to me that an instructional program like Software Carpentry would go far in helping engineers improve their software skills.
• Individual and Group Behavior: We train engineers to be great problem solvers, yet much of the difficulty in implementing solutions is not technical, but rather social. Further, we want engineers to operate devoid of emotion, and to think in a purely rational manner. Yet a quick glance at popular books like Predictably Irrational and Sway: The Irresistible Pull of Irrational Behavior indicates that most people operate in anything but a rational manner.  At the very least engineers should be aware of:
1. Their own limitations in perceiving and evaluating the world around them.
2. Human tendencies to respond in certain ways to external inputs; for example, our innate tendency to want to reciprocate favors, to be part of the majority, to be consistent in our actions, etc.
3. Methods used by marketers and politicians to sway both personal and group decision-making.

If engineers are going to be effective in advising society about our increasingly complex world, they need to be aware of human tendencies in evaluating information, and in responding to requests for action. I’d like to see a semester-long program like Software Carpentry address these issues. Primary texts for this class would be Influence by Robert Cialdini, and Yes!, 50 Scientifically Proven Ways to Be Persuasive by Noah Goldstein, Steve Martin, and Robert Cialdini. A text on negotiation skills might also be appropriate here.

• Technical Communications: If the preceding class on human behavior provides the strategy for effectively communicating an engineering perspective, then this class would be focused on the technique of delivering a targeted message. Engineers need to have a sense of how non-engineering audiences process information if they are going to counter the emotional appeal of most marketing campaigns. An investigation of information graphics would include texts ranging from Tufte’s classic book, The Visual Display of Quantitative Information, to the more casual Back of the Napkin. The Challenger Incident could serve as a case study in the importance of clearly deliniating the important engineering issues at hand.

Methods for presenting a clear, concise message would be covered, referencing texts such as Presentation Zen and slide:ology. Also included would be a discussion of presentation styles such as the Lessig and Takahashi methods, as well as the Pecha Chua and Ignite formats. An introduction to LaTeX may be appropriate as well, as few things are uglier than presentation slides showing equations that have been typeset using Microsoft products (IMHO).

• Risk Management: It is rare in most industrial settings to find individuals who can keep up with the mathematical skills of a fresh engineering graduate. So when an engineer is asked to make a calculation, the boss rarely wants to know how the calculation is performed. Rather, the boss wants to know if a particular product or process will operate in a desired manner. However, given the variability in all materials and methods, there is never an exact answer to such a question.

For some engineering problems, such as elevator construction, there will be a safety factor that is specified by code. However, no particular safety factor is given for most industrial tasks; an engineer must determine the appropriate safety factor for each situation. To do so effectively, an engineer must be cognizant of the risks that are inherent with his or her assumptions, and know how to convey the risk of those assumptions to others, who will likely possess less technical knowledge. This is especially critical given that all of us usually make poor estimates of inherent risk. It appears that Virginia University’s Center for Risk Management of Engineering Systems is attempting to address some of these issues.

Update: A possible text for this material is Judgment under Uncertainty: Heuristics and Biases. Referenced in this post by John Cook.

• Physical Problem Solving: Engineering problems would take forever to solve if each engineer had to develop their own theory of calculus. Yet we leave engineers to come up with new designs without giving them any hint as to how the work of prior generations could help them solve their problems. If the engineer doesn’t stumble upon the connection to prior work by happenstance, then each new design effort is simply an educated guess.

Inventor Genrich Altshuller and his colleagues studied the trends found in Russian patent filings starting in 1946. They developed a theory known as TRIZ, which translates from Russian as an acronym for “the theory of solving inventor’s problems.” The TRIZ methodology offers users a means for examining “new” problems in terms of existing solutions, thus often leading to quicker results. Although much of the TRIZ theory has been extended by private firms that keep their methods close to the vest, there do exist some open-source resources for learning this approach. There are also numerous books on this subject, including one by TRIZ developer Genrich Altshuller himself. Instruction in the TRIZ method could be enormously beneficial in improving the effectiveness of tomorrow’s engineers.

• Design Thinking: If the prior class defines how to produce a technical solution, this topic seeks to identify how to successfully implement a human solution. There is usually a large disparity between what people say they want or need, and what they actually use, do, or buy. Thus design thinking, in essence, is a focus on identifying human needs. As noted in a recent post by Stanford professor Bob Sutton, design thinking was developed by engineers. It is now being incorporated into other areas of study, including medical schools and MBA programs. However, many engineering schools fail to introduce their students to even the basics of design thinking. In addition to instructional material available from Stanford’s d.school website, there a lot of information available from the website of design leader IDEO. Perhaps books like The Art of Innovation and Change by Design could serve as reference texts.

So what is going to be thrown out of the core engineering curriculum to permit these courses to be taught? My current thought is that there must be a way to more quickly bring students up-to-speed. Perhaps the “lecture, study, homework, test” cycle of traditional education can be improved upon. If so, I bet the solution will rely heavily on the six skills areas outlined above.

Posted in Engineering Curriculum| | Comments closed