Non-academic science career information aggregator

I was recently pointed to a collection of links that many science and engineering grad students may find useful: The Prodigal Academic: Non-academic science career information aggregator

Non-academic science career information aggregator

Below is a list of websites that may be helpful.of interest to scientists looking outside of academia. This is by no means a complete list, so if you know of other useful sites, let me know, and I will add them in!

Blog posts about non-academic careers: …

CV vs resume: …

Possibly interesting career guidance: …

Interesting non-academic science online discussion: …

I’ve not copied the actual links, just the headers, as I don’t want to steal content from The Prodigal Academic, but just point to the web page as a useful resource. Most grad students in the sciences have to seek jobs outside academia, but their mentors are, for the most part, clueless about life outside academia (me included).

In engineering, the working degree is the MS, not the PhD (which is primarily for those seeking academic positions, or with a few small industrial or government research labs). Most engineering faculty are aware of the MS (“real” job) vs PhD (academic job) distinction, but still advise their students towards the path they themselves took.  Since many engineering faculty did some time in industry before turning to academia, there are often mentors around who can suggest different career paths.

In science fields. most faculty have been in academia their whole lives and can’t provide any useful information about other choices.  (Although I’m an engineering faculty member, I’ve also been in academia my whole life, so I can identify with the science faculty here.)

One major distinction between science and engineering is that in most science fields, the PhD is a requirement even for entry-level jobs, because of the huge over-production of PhDs in those fields. Biomedical research is probably the worst, in that several years of postdoc “training” are expected, so that many do not get jobs with any security of  employment until they are in their 40s.  (And by “security of employment”, I don’t mean tenure—I mean a job that doesn’t have defined end date before you even start work.) Huge numbers of scientists work on short-term contracts (2 years is common for a postdoc contract) with little expectation of the contracts turning into longer-term jobs.

So students need to be looking beyond their faculty advisers for advice about what to do with their degrees, and The Prodigal Academic has collected a number of useful posts with advice that many faculty members can’t give.  I plan to send the link to mailing lists of students, who might benefit from more knowledge of alternatives to the academic careers of their faculty advisers.

Critical thinking

In a comment exchange on the Cost of College post Trying to teach the enigmatic and increasingly popular skill of critical thinking, CSProfMom and I were discussing the relationship between critical thinking and the various modes of thinking used in CS and engineering.  I’ll pull out some of the highlights of the discussion to set the stage for this post, but I’m leaving some things out, so go read the original post and comments.

Grace, the author of the post, presented some of the definitions of critical thinking she had found, and CSProfMom replied with

I do not like these definitions of critical thinking because they are only based on verbal reasoning. Mathematical and computational problem solving are utterly ignored; yet I think more critical thinking goes on in those areas than in fields like literary analysis.

Grace defended the definitions, and CSProfMom responded with CMU’s definition of computational thinking:

Computational thinking means creating and making use of different levels of abstraction, to understand and solve problems more effectively.

Computational thinking means thinking algorithmically and with the ability to apply mathematical concepts such as induction to develop more efficient, fair, and secure solutions.

Computational thinking means understanding the consequences of scale, not only for reasons of efficiency but also for economic and social reasons.

http://www.cs.cmu.edu/~CompThink/

I weighed in with

I think that CSProfMom’s point is that “critical thinking” is generally defined rather narrowly and generically, and so misses the important thinking styles that are crucial to some fields. “Computational thinking” is one that is missing. One I see students not getting in most of their college classes is “engineering thinking” or “systems thinking”—dividing difficult problems into simpler subproblems with clearly defined interactions between the subproblems. Although one can argue that these specific modes of thinking are somehow subsumed in “critical thinking”, classes that purport to develop critical thinking skills don’t generally develop these important modes of thinking.

CSProfMom responded with

I think there is a lot of overlap between “computational thinking”, “mathematical thinking”, and “systems thinking”. Abstraction and decomposition are key skills in all three. Your description “dividing difficult problems into simpler subproblems with clearly defined interactions” is absolutely critical in computer science. Maybe computational thinking is simply systems thinking + algorithms?

In any case, because the “critical thinking” term does not include this idea of systems thinking, we see students arrive into our engineering/CS programs utterly unable to think in this manner. I believe that is a major reason why we see the terrible attrition rates in these programs.

The rest of this post will be an expansion on the comment I left in response to this.

There are several different terms floating around in our discussion, and I’d like to pull them out for closer examination:

critical thinking

This seems to be a subset of the medieval trivium (grammar, logic, and rhetoric), leaving out the grammar and being a bit light on the rhetoric. It doesn’t even cover modern mathematical logic, but only the simplest Aristotelian logic. The Wikipedia article on the trivium even points to the critical thinking article, which collects nine conflicting definitions of critical thinking, none of which include the other concepts that I list below, except in the vaguest ways.

mathematical thinking

Mathematical thinking is about setting up formal systems of rules and examining their properties very closely. Proofs are a major component of mathematical thinking, which has a much more formal and unforgiving definition of proof than other fields. Computation has created a lot of new formal systems to study, and has been a fruitful area recently for mathematicians, just as physics was in previous centuries. Theoretical computer science is basically a branch of mathematics, involving primarily mathematical thinking.

scientific thinking

Scientific thinking studies the real world, constructing models of how it functions and testing the models empirically.  Different branches of science differ in how much they are model-driven and how much they are data-driven. Physics is highly model-driven, with the models often coming out 40 or 50 years in advance of the data (see Higgs boson).  Biology is highly data-driven often with non-quantitative  verbal stories as the models.  The key concept throughout science is empirical validation of predictive models.

engineering thinking

Engineering is about designing new things.  An engineering question is more of the form “how can I make this work?” rather than the science question “how does this work?”  I’ve talked about the distinction between science and engineering in one of my early blog posts, so I won’t belabor the point here.  Although scientists and engineers often wander back and forth between scientific and engineering thinking, the two are really distinctly different modes of thought.

systems thinking

Systems thinking is an important component of engineering thinking, consisting of dividing difficult problems into simpler subproblems with clearly defined interactions between the subproblems.  But systems thinking cuts across many fields, including mathematical thinking and scientific thinking. 

Computer programming is one of the best subjects to teach systems thinking in, because computer languages provide formal (though still inadequate) ways of representing the modules that encapsulate the subproblems and the interactions between them.  Electrical engineers try to do the same thing with their block diagrams, but these formalize a little less of the interactions, relying on English-language descriptions that are often omitted or poorly written. 

Unfortunately, many of the lower-level computer science classes have the faculty or textbook authors do all the systems thinking for the students, so that the students never learn to do it themselves. The scaffolding put in place to help the students find good solutions is where all the systems thinking happened, and descaffolding so that students have to learn to subdivide difficult problems into easier ones is an essential, but often missing, component of teaching programming.

The “multiple levels of abstraction” mentioned in the CMU definition of computational thinking is really about systems thinking, as each subproblem gets broken down into still smaller problems. 

algorithmic thinking

Algorithmic thinking is coming up with very precise recipes for doing things—not just flailing around trying things, but having very specific methods that can be shown to work (and work efficiently). Algorithmic thinking is really a branch of mathematical thinking, interested in provably correct manipulations in formal rule systems.  Originally it was applied to computing numerical functions, first manually and later by machine, but now has been expanded to cover many different types of data that can be represented in computers.  This is the second part of the CMU definition of computational thinking.

computational thinking

I don’t like the CMU definition of computational thinking, as they seem to have picked up definitions of mathematical, systems, and algorithmic thinking, and missed the computational part entirely. Computational thinking, to me, involves using computation to solve problems (data analysis, algorithmic solution of symbolic problems, numerical simulation, …) and may not involve much systems thinking or algorithmic thinking—someone else may have done that for you to enable you to use a computational tool.  Using Google to search for information is computational thinking, albeit at a rather low level.

statistical thinking

Statistical thinking is distinct from all of the above, though it is often important in scientific thinking.  Statistical thinking involves reasoning about data that comes from random processes, or that can be modeled as having been corrupted by random noise.  Notions of probability, sample size, statistical significance, multiple-hypothesis correction, correlation, and causation are all part of statistical thinking, which has applications to decision making in all aspects of life.

Obviously, there are overlaps and intersections between these different modes of thought (proofs done with the aid of a computer are a combination of mathematical and computational thinking, for example), but there are important differences also.  For example, Engineering thinking is not just systems thinking, but includes attention to fine details in the edge conditions (a hallmark of mathematical thinking), making allowances for variations in manufacturing (statistical thinking), testing how the device works in the real world (scientific thinking), and, very often these days, figuring out how to use cheap microcontrollers to do tasks that traditionally were done with more expensive analog devices (computational thinking).

The UCSC general education requirements (see my blog post on general education) recognize mathematical reasoning, scientific inquiry, and statistical reasoning as distinct parts of general education, adding textual analysis and cross-cultural analysis to cover what is often lumped under “critical thinking”.  They did not include anything that guarantees exposure to systems thinking, and they tossed in a few other things, some of which seem to me to be more politically expedient choices or fashion following than fundamental modes of thinking, but a general education system is always a compromise between different beliefs about what a university education should mean.  I think they did a better job of defining the basis for their general education system than most universities manage.

There have been a lot of calls for more education in “critical thinking” lately.  I’m not really happy with these calls, because teaching only a weakened version of the medieval trivium instead of more powerful modern forms of thinking does not educate students properly.

 

 

Teaching engineering thinking

Yesterday I wrote

Maybe I should recommend some generic problem-solving books, like Polya’s How to Solve It, since it seems that the class has not been taught many problem-solving skills. I keep feeling that I’m teaching stuff that they should have had much earlier, but clearly haven’t, as if every teacher they’ve ever had has pushed off teaching the important stuff in order to cram in more factoids. There are times when I’m tempted to kick the can down the road myself, but these are all seniors, and it seems almost criminal to let them graduate as engineers without ever having been taught to think like engineers. I’m going to end up working them pretty hard, trying to get them up to speed in circuits, writing design reports, and how-to-think-like-an-engineer in just 7 more weeks.

I’ve been trying to pin down just what I mean by “how to think like an engineer”—something I’ll need to have at least some handle on before I can teach students how to do it.  I have a few vague ideas of what it means, but not anything crisp and clear enough to serve as a design guideline for planning my teaching.  Here are a few random thoughts:

• Engineers pay attention to details.  It isn’t enough to have the right general idea—the execution has to be right also.
• Engineering is about solving new problems, not memorizing solutions to old ones. It is better to have a few general principles that can be used over and over in different contexts than an encyclopedia full of formulas and protocols for every known situation.  If the problem has already been solved, it isn’t really an engineering problem.
• Design is often about a tradeoff between conflicting goals, or between goals and constraints that limit what can be done.
• Sanity checks are essential.  Every schematic, every wiring connection, every computation should be subjected to quick checks for consistency.  Some of the checks are easy: Does every 2-terminal component on the schematic have two connections to it? Is every pin on the chip accounted for—either wired up or labeled as not connected? Do the units for the computation match (ΩF=seconds, not Hz)? Does replacing the ammeter with a short-circuit change the expected behavior of the circuit?  …
• Design is not a process of randomly trying things until something happens to work, but of carefully planning how things should behave.
  Don’t get me wrong—I’m not denying the role that chance and luck can play in engineering. There are occasional serendipitous events, where something works despite mistaken thinking, but that is rare. My first patent, the plucked-string algorithm that Alex Strong and I developed, resulted from just such a serendipity—Alex had been attempting to implement something and had mistakenly added an averaging of two adjacent samples. My main contribution was to figure out why that mistake produced much more interesting results than what he had originally set out to do.  But even with that initial serendipity, we spent a couple of years doing careful design—coming up with different software and hardware implementations for the plucked-string algorithm (which we called the Digitar algorithm, but is now more commonly called the Karplus-Strong algorithm).  I even took a  VLSI design course so that we could implement the algorithm as a custom chip—a course that shaped my career for the next 15 years.
• Debugging is a process of thinking carefully about why the circuit, program, device, system, … is not doing what you want, and what modifications to it should change it in the desired manner. It is even less random than design—one has to build useful mental models of the failing system that explain the cause of the failure, then determine modifications that would fix that mental model, before trying fixes in the real world.
• There are no right models, just useful models and useless ones.  (Even that’s wrong: there are more useful and less useful models, where the usefulness depends on what questions you need to ask of the model.)
• Quick estimates from rules of thumb and extreme cases are handy.  A capacitor is an open circuit at DC and a short circuit at ∞ Hz, so low-frequency and high-frequency behavior of RC circuits is easy to estimate without much computation.
• Empiricism rules: the answer to the question “Is this right?” is almost always “Try it and see!”

How can you tell if someone thinks like an engineer (or will learn to think like one)?

Some people point to kids who like to take things apart to see how they work, and say that they are budding engineers.  While taking things apart to see how they work is sometimes done by engineers, it isn’t the normal mode (they even call it “reverse engineering”, because it is backwards from what engineers usually do).  Scientists take things apart to see how they work—engineers put things together to make them work.

I posted about science vs. engineering 2½ years ago. In looking over that post, I see that even then I was thinking about the differences in training:

There is a distinct difference in the training one should give a student who is planning to be a scientist and one who is planning to be an engineer.  Sure, the basics are the same at the beginning (basic science, math, lab technique, computer programming, statistics, and so forth), but the engineer has to be taught how to design and debug, while the scientist has to be taught how to question dogma and discover new ideas.  These are not the same skills at all and both need substantial practice before people are competent at them.

For scientists, the tradition has been to devote the undergraduate years to acquiring basic knowledge, but not to practice being a scientist at all.  As a result it takes 5–7 years of grad school (and often several years of post doctoral training) to turn science undergrads into scientists. For engineers, the tradition has been to do 2–3 years of basic training, followed by 2–3 years of project work of gradually increasing complexity, culminating in either a B.S. or an M.S. degree.

The shorter training time for engineers means that it must be much more focused—you can’t hope that the students will pick up skills they need gradually as a by-product of years of doing something else (the way that scientists are trained). Instead, the specific design skills and group management skills need to be explicitly taught and practiced while the students are still undergrads.  This has a lot of consequences for curriculum design, as almost all junior and senior courses have to include design practice, and there needs to be at least one big project (preferably one too big for a single engineer to handle).  Explaining these curricular needs to faculty trained as scientists can be difficult—they want to leave all that to the grad curriculum or one-on-one training of postdocs.

I’m afraid that the bioengineering students in my circuits class have all been trained like scientists, with a huge number of courses in basic scientific knowledge, but almost no training in debugging or design practice. Hmm, that’s not quite fair.  Several of them have worked pretty intensively on debugging wet-lab protocols, though mostly in senior thesis projects, not in regular courses.

I can’t teach everything about “thinking like an engineer” in one course, even if I could articulate exacly what I meant by it.  I will try to give them problems that are puzzles, rather than rote application of formulas, and that emphasize design goals rather than analysis of what is already designed.  Since the traditional circuits course is almost all analysis with very little design, this makes the crafting of this course into an engineering design challenge: I need to create something new, not just copy exercises and lesson plans from elsewhere.

Unfortunately, I’m still wrestling with the precise design goals of the course and the constraints imposed by the time available and the prior training of the students. I had taken “thinking like an engineer” for granted earlier, for example, and not thought of it as a pedagogical goal for the course.  Now I need to rethink how I present material and how I get students to wrestle with it so that their lifelong habits of thought are shifted.  I was thinking I would be adding a couple of new tools (from circuit design) to their toolbox of mental models, rather than having them build a whole new toolbox.

Having to debug a course design is a lot like other engineering design challenges, except that I need to debug the course while it is running—I can’t turn it off, restructure it, and turn it back on again.  The problem I have right now is that my mental model of the material and how the students would interact with it is not quite right (I get too many surprises), and I’m trying to decide if it is a good enough model to continue with, or whether I need to find a substantially different mental model in order to debug the course.

Perhaps my new view of needing to teach “thinking like an engineer” is wrong—maybe the problems I’m seeing are not that fundamental, but are just unfamiliarity with the material, and that a little more practice to get comfortable with it is all they need.  The pedagogical interventions I’d need to do are quite different in these two views of the problem, and I’m not sure how to tell which mental model is more useful.

Does anyone who got this far in my post-midnight rambling have any suggestions for me?

Engineering vs. Science

I’ve been an engineering professor for a long time (28 years now, but I still feel like a grad student).  In my current department, most of the faculty were trained as scientists, not engineers, and the differences are sometimes striking.  The public always lumps together science and engineering, and the education establishment even more so, lumping Science, Technology, Engineering, and Math together as STEM fields. But there is a difference, and it is sometimes important.

So, what is the difference between science and engineering? and does it really matter to anyone?

The difference between science and engineering is not so much in what you need to know to do them, but in what sort of questions you ask.

Science is mainly about “why?” questions: why is the sky blue? why can stem cells keep proliferating, while differentiated cells do not? The focus is on Discovery—studying phenomena and building models that explain them and enable accurate predictions about so far unobserved phenomena.  Acquiring new knowledge and understanding is the main goal.

Engineering is mainly about “how?” questions: how can I sequence DNA cheaper and more accurately? how can I kill cancer cells without killing stem cells? how can I make a cell phone that people will want to buy, even though they have  perfectly good phones in their pockets already?  The focus is on Invention—making new things or processes, on solving real-world problems, rather than on acquiring knowledge.

Take a look some time at what projects win at local and state “science” fairs.  The lists are almost always dominated by engineering projects—ones that try to solve a real-world problem using already well-known science.  The fields can be quite diverse, though lately health and environment applications have been the most successful.  At least the Intel International Science and Engineering Fair has an honest title including engineering, unlike most of the state science fairs.

Chicken or egg?

People have been taught since elementary school that science comes first, and that engineering is the application of science.  But this is a gross oversimplification of the real situation, which involves a cycle:  a phenomenon is discovered (science), an application for it is found (engineering), the application allows new things to be discovered (science), which in turn allows new applications, leading to new discoveries, … .

In the old days, this cycle was often quite slow, with generations between the discovery of a phenomenon and its application.  Nowadays, the cycle is often much shorter, with the application coming almost simultaneously with the discovery of the phenomenon. Consider, for example, RNA interference (RNAi).  The phenomenon of anti-sense RNA reducing the expression of genes in various organisms was first discovered in the  early 1980s (or perhaps late 1970s, I’ve not traced the original papers).  It was almost immediately used to control expression in genetic experiments.  A lot of both science (how does RNA control expression of genes?) and engineering (how can we reliably use RNAi to knock-down expression of genes we wish to control?) has been done since, and RNAi has become a standard tool for biotechnology, particularly for studying multi-celled creatures, where knocking out genes can be expensive or impossible.

Nowadays, the important advances in molecular biology are usually the result of a new tool becoming available (like high-throughput sequencing), so that the field is driven forward mostly by the engineering advances.  As the new tool becomes available, thousands of scientists start using it, and some interesting discoveries are made (plus a whole lot of rather boring minor ones—the trouble is, we don’t know in advance which ones will be important and interesting).

Who cares?

A single individual can do both science and engineering, discovering phenomena and applying them. So what is the point of making a distinction?

There is a distinct difference in the training one should give a student who is planning to be a scientist and one who is planning to be an engineer.  Sure, the basics are the same at the beginning (basic science, math, lab technique, computer programming, statistics, and so forth), but the engineer has to be taught how to design and debug, while the scientist has to be taught how to question dogma and discover new ideas.  These are not the same skills at all and both need substantial practice before people are competent at them.

For scientists, the tradition has been to devote the undergraduate years to acquiring basic knowledge, but not to practice being a scientist at all.  As a result it takes 5–7 years of grad school (and often several years of post doctoral training) to turn science undergrads into scientists. For engineers, the tradition has been to do 2–3 years of basic training, followed by 2–3 years of project work of gradually increasing complexity, culminating in either a B.S. or an M.S. degree.

The shorter training time for engineers means that it must be much more focused—you can’t hope that the students will pick up skills they need gradually as a by-product of years of doing something else (the way that scientists are trained). Instead, the specific design skills and group management skills need to be explicitly taught and practiced while the students are still undergrads.  This has a lot of consequences for curriculum design, as almost all junior and senior courses have to include design practice, and there needs to be at least one big project (preferably one too big for a single engineer to handle).  Explaining these curricular needs to faculty trained as scientists can be difficult—they want to leave all that to the grad curriculum or one-on-one training of postdocs.