Making Terrorism Rare

Following the events of the Boston Marathon bombing, I would like to bring everyone's attention to the fact that terrorism in the United States is so rare that this has become national news, and by extension, international news. Three people were killed in the bombing.

Was the bomb that killed fifteen people in Syria a week ago international news? No. Was the bomb that killed seven people in Afghanistan two days ago international news? Nope. Or how about the one that killed nine the week before that? This is because these are common occurrences.

I'm not saying you should feel bad about it or something. I'm just saying to remember, terrorism in the United States of America is extremely rare. Many folks, upon hearing this assertion, will say that we should be thankful we live in such a safe country and that we should care more about the situation in other countries. Yes, one of the takeaways from this is that we might relate better to foreigners when we consider how different their situation is. But I want us to think even beyond that.

I want you to wonder, "Hey, yeah, what does set us apart? Why is terrorism so rare here?" Certainly terrorism is easy, no? I could find instructions online and have a small bomb within weeks. So why don't I? Why doesn't this happen every day?

I also want us to wonder, "Hang on... if terrorism is so damn rare, why do I have to walk in my socks like an idiot at airport security?" What is this really doing? Is it making me safer?

I want us to be asking really critical questions about why terrorism is rare, and I want that to lead us to ways to make it more rare. Where should we be investing our resources? What kind of security is the most effective?1 And can these strategies be exported to our brethren in other countries, where violence is much more common?

I don't have all the answers; I only have the right questions.


  1. I think a good start is by putting our reliance in good old-fashioned police work, instead of new technologies. And I think it's important for us to realize that as a group, terrorists are dumb, and they make dumb mistakes.

Write a Winning Statement of Purpose

If you are applying to graduate school, you probably already know the four major points you are expected to cover in your statement of purpose:1

  • Your specific area of academic interest (research topic you want to work on or scientific question you want to answer).
  • How your past education and other experiences have prepared you to be successful in the graduate program.
  • What you hope to achieve in the graduate program.
  • Why that particular school is the best place for you to pursue your interests.

Here, then, are the more subtle elements of writing a winning personal statement. These are the boxes the reviewer is looking to tick:

  • Good communications skills (esp. writing skills) — Whether you're in liberal arts or science, grad school will have you writing a whole lot. A lot of science majors underestimate how much these skills will help their application. Plus, there's a good chance you'll be expected to teach at some point, so if you have any prior teaching or tutoring experience you should mention it.
  • Hard working and motivated — You can't just say you're "self-motivated" like every other boob writes on their resumé. You have to offer an anecdote or evidence that demonstrates your motivation. For me, this was an anecdote about the DARPA Grand Challenge where we lost due to our reliance on GPS sensors. This motivated me to want to solve the problem of robot navigation without GPS.
  • Understanding of the field — If you don't have this, spend a week reading whitepapers and Wikipedia articles. This will give you enough keywords to let you talk conversationally in terms that an insider will recognize. It will make a big difference. Google Scholar and CiteCeerX are your friends.
  • Reasonable expectations about what you will achieve — Don't tell them you're hell bent on being the next President of the United States. That's childish and unrealistic. Present a balanced perspective that shows ambition, optimism, and hopefulness, but also restraint.
  • A focus on research — This will differ from field to field, but in most fields what they really want to hear about is research. Like teaching, if you have any research experience it should feature prominently in your essay. In addition to the research you've already done, they'll want to hear about the research you plan to do in grad school. Show that your plans are focused by being specific, but also show that you are open to other possibilities. Ideally, you should already know the scientific question you want to answer. If you don't know this, then you should be able to present some ideas to show that you're already thinking about problems (though this is less important for an MS). If you haven't done any research at all, you're in serious trouble unless you have impeccable grades to make up for it. So dig deep. Find anything that remotely resembles research. You need to prove to them that you can do research on your own, without guidance.
  • Finally: How are you going to stand out?? — How are you going to stand out in the admissions officer's mind?? What will they call you to remember you by? "Oh, that's the librarian who's interested in accessibility of information," or "that's the guy who went backpacking in Europe," or "the guy who competed in the DARPA Grand Challenge." This doesn't have to be something academic. It just has to be the one thing that is really, truly unique, interesting, and memorable about your essay. It doesn't even have to be a significant moment in your life. It just has to be something that the mind of the reviewer can latch onto, something so they will still remember and identify you after reading hundreds of essays just like yours (no problem, right?).

One last tip: Try to write your essay so that it still reads the same if a reviewer reads only the first sentence of each paragraph—sometimes this is all they will have time to read! (In case you didn't notice, that is how I've written this post!)

Finally, you should read the following books. Whereas I've only tried to give you the overall themes you should strike upon, these books will give you the in-depth view. Try to find them at your local library.


  1. Taken from this page in UBC's well-written FAQ for applicants.

Recursive Programming Aphorisms

  • Premature optimization is the root of all evil is the root of all evil.
  • Go To Statement Considered Harmful Considered Harmful
  • You Ain't Gonna Need You Ain't Gonna Need It (YAGN-YAGNI)
  • No code is faster than no code.
  • Why Why Functional Programming Matters Matters (via Reginald Braithwaite)
  • Another level of indirection solves most problems in computer science, except the problem of indirection. (via Matt Might)

Have another one to add? Email me!

Don't Become a Scientist?

Becoming a scientist is scary. In fact, it may not even be worth it.

Now that I am applying to graduate school, I've been reading about what to expect. I've been reading a lot. Books about essay writing, books about the application process, books about being a scientist, memoirs, essays, student blogs, professor blogs, and forum postings (whew!). And you know what I've found out? Becoming a scientist is possibly the economically worst decision a person can ever make.

I'll try to condense the main idea of what I've read, and link you to more reading if you're interested. These "facts" are largely anecdotal, but the opinion is held by many, so I believe there's something to it.


To summarize, a person who studies science as an undergraduate can follow two paths: industry/engineering or academia/research. Under one path, they begin earning good wages right away, and always have good job security and a fair amount of free time. By comparison, the researcher puts their life on hold for 15 years, working twice as hard, with no free time and no good wage until they're 40. And they almost never earn as much as an engineer.

More Detail

To further explain, a person bent on doing research for a living will need to stay in school until age 30 to 34. They'll be required to work post-docs for the following 3 to 5 years at paltry wages (much less than the wage required for happiness). When they do finally land permanent jobs, they're around 40 years old, earning the same wage that their engineering peers have been earning since they were 25. They won't have control over where they live, because their jobs are limited to universities or research labs and are extremely competitive. So it's no wonder that Philip Greenspun asserts that "Adjusted for IQ, quantitative skills, and working hours, jobs in science are the lowest paid in the United States."

Just for the purpose of a rough estimate, let's assume that there are about 3.7 million 30-year-olds in the U.S. (based on birth rates in the early 80s). This is round about the age of the average PhD graduate. If there are about 69,000 PhD graduates every year, this means you already have to be in the top 2% to get that far.

So, in the top 2% of your generation, your timeline looks like this:

  • age 22–28: earn your PhD, subsisting on perhaps $20k–$30k per year.
  • age 28–32: work as a post-doc for $30k–$50k
  • age 32–38: (<50% chance) work as assistant professor at $50k–$65k
  • age 38–??: (<20% chance) achieve tenure and earn ~$85k as associate professor
  • age ??: (<15% chance) achieve full professor, maybe earn ~$100k

So the very cream of the crop, the 0.3% (the top 15% of the top 2%), just barely manage to crest the 6-figure mark. And this doesn't happen until they're nearly 50. Until they're 38, they will be living below the level required for happiness (which is ~$60k).

Meanwhile, their other friends who graduated in the top of their undergraduate science programs, but who did not pursue graduate degrees, look like this:

  • age 22–26: work as technician or engineer earning $65k–$75k
  • age 26–30: maybe get married, maybe travel a bit, get exciting new job at $80k
  • age 30–35: move where they like, start a family, or pursue hobbies
  • age 35–??: probably become a senior engineer or manager at $100k–$125k

Some Choice Scare-Quotes

"Adjusted for IQ, quantitative skills, and working hours, jobs in science are the lowest paid in the United States." —Philip Greenspun

"I have known more people whose lives have been ruined by getting a Ph.D. in physics than by drugs." —Jonathan Katz

"Eventually, you will probably be squeezed out of science entirely. You can get a fine job as a computer programmer, but why not do this at 22, rather than putting up with a decade of misery in the scientific job market first?" —Jonathan Katz

"Leave graduate school to people from India and China, for whom the prospects at home are even worse." —Jonathan Katz

"Science is a wonderful thing if one does not have to earn one's living at it." — Albert Einstein

"A man of science may earn great distinction, but not bread." — Thomas Henry Huxley

Further Reading

There have been many who warn of the dangers of a career in science. Prof. Jonathan Katz implores, "Don't Become a Scientist!" Engineer Philip Greenspun posits that women don't enter science because they know what a terrible idea it is. Of course, these are scare pieces, and there are some counter-arguments. But it is widely agreed that the U.S. trains far more PhDs than there are jobs available. This Quora question has some great opinions and links to further information.

Some of these warnings do make exceptions for my own field of computer science, where research is booming, so maybe it won't be so bad for me. But it does give me pause.

The Carpenter and the Engineer

This is the script of a lightning talk I developed for the Boston Software Craftsmanship group. It sparked some great discussion around craftsmanship, good programmers vs. bad programmers, and computer science education. There were too many ideas to put to paper, really, but I'll reproduce the original talk here and let you draw your own conclusions.


So, I think I just had a revelation. Most software developers—myself included—are basically just labor. Skilled labor, yes, but basically similar to construction workers. We always talk about crafting things. Often those things aren’t very difficult to craft, logically or mathematically. “When someone checks this box, disable this field; when the database is full, show a warning message,” and so on. We often talk about “plumbing” or “wiring things through” as if we’re plumbers and electricians. There’s just a lot of parts of programming that aren’t hard, they’re just tedious and they take time.

Now, there are some programmers who are engineers, who do hard math to develop the core algorithms. But the rest of us just polish up those algorithms and build a harness for them, build an interface for people to interact with them. Often times the “houses” these algorithms live in are the builder's own design, so they are often as skilled as an architect, but the majority of their time is spent doing things I would more closely associate with carpentry or woodworking (to borrow an analogy from The Pragmatic Programmer). And anything really complex can only be handled by the engineer.

That's how it is at my company; my team builds the interface for the visualizations created by our statisticians (sometimes we create the whole visualization, and they only write the algorithm that spits out the p-values, but the analogy holds). Maybe at your company it works a bit differently. Maybe you work for a startup, where you wear both hats. But I still think that most developers work in a labor capacity. And this is interesting, because we often like to think of ourselves as pretty intelligent people; we went to school alongside all the other engineering students; we see ourselves as problem solvers; we see ourselves as nerds. But as for myself, at my current stage I would rate myself a laborer — maybe an architect (on a good day).

So there seem to be two distinct domains here. Now how might that change the way we think of ourselves?

I’ll give you an example from an algorithms class I recently took. We had to write a program to process a graph with 875,000 nodes: this involved two very different, very distinct subproblems.

One was coming up with the algorithm itself, to efficiently process the graph and solve the problem. A purely mathematical problem, minimizing time complexity while proving correctness. This part was given to us by the professor.

The other part—my part of the problem, since I had chosen to do all my homework in Python—was how to get Python to handle the damn data. As it turned out, this was a harder problem than I had expected, since Python isn’t particularly performant. It took minutes to run, so you had to come up with some really good test data instead. Not only that, but once you ran it on the full dataset, it would overflow the stack immediately, so you had to either learn how to increase Python’s stack size and recursion limit, or you had to turn it into an iterative algorithm (which in essence just means that you maintain the stack yourself instead of hijacking the program stack).

So this was a completely distinct problem, and is more of an practical problem than a math problem... somehow it’s just a bit “softer.” It doesn’t necessarily need to be solved with equations (maybe we can throw more hardware at it, or switch to C instead; you know, come up with some practical workaround). Whereas the other problem definitely does require equations and proofs and deep analysis.

An aside: I’ve met a lot of programmers who shrug off mathematical problem-solving as being outside their realm, or impractical, or overkill, or premature optimization. They don’t seem to appreciate the fact that the only reason our programs can run with any kind of reasonable limit is because of all the hard work already done for us in the languages that we use, the compilers that build them, the libraries that support them. You can’t just parrot “optimization is evil” and pretend it doesn’t exist! But I digress.

Point is, both these kinds of computer science were necessary to solve the problem of the 875,000-node graph. And both were a big pain in the butt, believe you me. But the algorithm was already done for me. And I bet it took a lot more work than the afternoon I spent on turning it into an iterative implementation. But then again, maybe some of these practical engineering problems really do take just as long to solve well.

Take all the recent obsession over “big data” and scalability for instance. There are some seriously hard problems there. Many of them are operational problems, the realm of sysadmins. Many of Google’s problems involve machine learning, heuristic-based searches, etc. Many of Facebook’s problems involve very efficient graph traversal and storage. But are these problems that are solved by the same programmers who create the user interface for Gmail? I honestly don’t think so. I suspect that these companies have a separation between their scientists on the one hand, and their construction workers on the other.

You might take our meetup for example. What do we discuss here? We discuss best practices. We discuss design, and aesthetics, and agile methodology. We discuss soft things, subjective things. How many programming meetups do you know of that go over novel data structures; or where the attendees solve math problems, or discuss algorithmic complexity. I’ve yet to find a meetup like that. A meetup where I can actually learn hard things.

It begs a lot of questions. Are we really as skilled as we think we are, or is it just that not many other people enjoy doing what we do? Are we in demand because we’re skilled, or because the “construction” business is booming? Should universities be separating these two types of students, and teaching them different things? Should they have bothered to teach me all that linear algebra, if I was just gonna forget it anyway?

I think this also ties into recent efforts to get kids and others interested in programming: the FIRST Lego League, Google App Inventor, Code Academy, and the like. I think I’m not the first person to realize how easy programming really is, and how much demand there is for it, and that maybe if we can just get people to try it they’ll discover how easy it is, too. It might be the first time that a labor job was so plentiful and yet so understaffed, because people associate it with higher-order thought.

And speaking of higher-order thought, I still have more questions. At what point does a problem become complex enough to enter into this “mathematical” category? Are there really two distinct categories of programming problem? Or is it perhaps a linear progression, a gradient running from easy to hard to NP-hard? … I dunno.

What kind of computer scientist are you? Are you the mathematician? Or are you the carpenter? Or perhaps a bit of both? Is one more “elite” than the other? I dunno... but I think at least the mathematician in all of us deserves a little bit more respect.