4 Things I Learned While Spending My Summer as a Professional Scientist
I’ve written before about my…um…abrupt career change. Not a day goes by that I don’t second guess that decision because of course I’m secretly a not very smart person who has convinced very smart people that I am worth their time. Some of those very smart people I managed to bamboozle where the good physicists and astronomers at the University of Oklahoma who for some reason invited me to do research there over the summer through the university’s REU (Research Experience for Undergraduates) program.
There are a lot of these programs in various disciplines throughout the country funded in part by the National Science Foundation. They are designed to give undergraduates a taste of what it’s like to be a researcher under the caring tutelage of, you know, someone who actually knows what they are doing.
For my project, I ended up helping catalog galaxy clusters as part of a Ph.D. student’s dissertation. This is not as straight forward as it sounds. Helping with this project really cemented some things that I knew intellectually, but hadn’t really internalized.
1. Computers are your friends
I know that knowing how to program is important if you want to be an astronomer or a physicist. I know this in my brain. I did not, before this summer, know this in my heart. Now I know this in my heart. Most of the 10 weeks of this program were spent writing programs in IDL, with a text editor on one screen and Google on the other. (Also, I definitely got addicted to having two monitors. Why is my laptop screen sooooo smol?!)
At my final count I wrote about 30 programs this summer. I don’t actually know if that’s a lot, but it feels like a lot. Moreover, they were all pretty small and simple and probably shouldn’t have taken me all the time it took me write. I’ve been trying to learn how to code for a while but nothing has really stuck. But this summer I coded for basically six hours a day five days a week. I think some of the stuff started to stick, which is a relief. It’s possible for me to learn to code! Just not easy.
Lesson 1: Don’t be sad when you have to learn to code just to be a professional star-gazer. You can do it!
2. Actually, computers are more like the Soviet Union in the 1980s
Because I was hunting galaxy clusters, I had to look at a lot of images of the sky. If I had to identify every source of light in those images by eye, I probably would have packed up my bags on the first day and rode a cartoon dust cloud home. Thankfully, I didn’t have to do that. There is a popular program called Source Extractor that is widely used in astronomy circles to detect and catalog stars and galaxies in an image of the sky. It will even assign those sources a value so you can tell how likely they are to be galaxies. Great! Let’s do it!
Oh one problem. Source Extractor can’t always tell the difference between stars and galaxies. Not just a few mischaracterizations here and there, but a lot and for reasons not made clear to me. So it was with our images, which lead to more work for me.
I won’t go into what we had to do to fix this problem because it’s not terribly interesting and not relevant to the lesson. Lesson 2: You may need computers to do astronomy, but you need more of a trust but verify type of relationship with them.
3. Use Your Words
Part of the requirements for the program was giving two talks: one talk at the beginning of the summer explaining what we were researching and where we hoped to get by the end of the summer and one talk at the end of the summer explaining what we had accomplished. I mean…fine. I have a horrible fear of public speaking and would much rather have just written a couple of essays, but I get it. If we want to move on in physics and astronomy we’ll need to learn how to do presentations.
Most people did a really good job, despite being given what I consider really bad and specific advice. Like, don’t practice your presentation more than three times. LOLWUT? If you are someone who can get away with that, great. But that’s not me. I’m lucky that I’m in my 30s and know more or less what advice to ignore and rant about on Facebook.
That advice really just comes down to personal preference. But I did notice something that I consider a little more nefarious as these established Ph.D. scientists were trying to teach us how to give a talk. They didn’t really recognize who the audience was. There is no specific piece of advice they gave us that exemplifies this. In fact, we were told again and again to “know your audience.” However, when it came time to give our final presentations, it became clear that we should assume everyone has the same base of knowledge, which wasn’t true. Astrophysicists can’t assume that particle physicists have the same knowledge pool to draw from, and vice versa. And for glob’s sake, show a little personality! I know a lot of Very Serious Scientists seems to think so, but your work doesn’t become invalid because you put a little of yourself into the presentation of it. (FWIW the title of my presentation was “Mindiana Jones and the Cluster Crusades” and I have no regrets.)
I suppose that I need to remember that I’m a lawyer from a liberal arts background. Communicating perhaps comes as naturally to me as advanced mathematics comes to some of my colleagues. And since my inbox is routinely filled with emails from science communicators, perhaps I’ve thought more about this than the average person. Moreover, there may be some wisdom in erring on the side of boring professionalism before you develop the instincts to know when and where a certain style might be appropriate. Lesson 3 is not as much a lesson as a reminder to myself: Being boring and professional has it’s place, but don’t let it crush whimsy.
4. They Might Be Giants is basically the best music to code to
This is a fact.
Overall, I spent a really great summer in Oklahoma mapping galaxy clusters in the universe. In the end, I only got as far as to tentatively identify one cluster, but I helped develop the process that will lead to more being confirmed. It’s not flashy, but it’s pretty cool.
Featured image comes from the title slide of my REU 2015 Presentation at the University of Oklahoma created by Chris Tucker
Oh cool, I’ve done work with identifying clusters myself. My Master’s thesis in fact was on a cluster-identifying algorithm.
One other interesting thing I’ve noticed is that not only is programming 90% of astrophysics, but astrophysicists have a ton of (mostly friendly) snobbery over the best language to program in. I’m not immune myself – just reading the three letters “IDL” in your post had my mind going “Just use Python!” And let’s not even get started on C++ vs. Fortran.
I was familiar with Python before this summer. I think most of the astro people used some combination of Python and IDL, but for some reason I just used IDL. Which was fine with me, actually, but that meant I didn’t have to switch between languages haha.
The languages in favor depend a lot on the institution and project. For instance, I’m working on the Euclid space telescope project, and on the coding side of things, we have to get everything working in a common environment. This means limiting the languages allowed, in this case to just C++ and Python (and it was a fight to even get Python allowed). I’m currently trying to coordinate an exercise which involves getting everyone’s code into one/both of these for it, and it’s revealed to me just how many languages are in common use by astrophysicists.
In a way, it’s a shame, as it makes sharing code much harder. I’m publicly sharing code for a paper I just submitted, but since my code is in C++, someone who only knows IDL isn’t going to find much use for it. Some standardization would help there, but I don’t think we’ll ever resolve the argument of which languages to standardize to, so we’re stuck with this mess.
It’s scary how many physics departments still offer Fortran as the one course covering their coding requirements.
Sounds like a cool experience! I had a very brief collision with IDL back when I was doing summer research, and it struck me as very strange. As it turned out, it was only a weak interaction and I fell back into Matlab’s orbit pretty quickly.
I totally agree with your thoughts on giving presentations. I’ve seen a whole lot of scientific presentations over the last few years, and the reality is that even most professional scientists aren’t that great at giving good talks. Consequently, the ones who are really stand out. I got some advice early on in grad school about the whole “know your audience” thing and figuring how how much background to give, which has served me well. It’s something like, “no one ever gets annoyed at a clear explanation of the basics.” That’s a little simplistic (starting a professional physics talk about your current research with “these are Newton’s laws of motion” is probably too basic), but I realized quickly that in general, most of what you consider “common knowledge” for professionals in your field is actually much more specialized than you think. Smart people who are working on even slightly different things than you may be totally ignorant of knowledge you take for granted. And even if they have encountered it before, they may need a refresher if it’s not something they use every day. And finally, even people who are more knowledgeable about the topic than you often still enjoy a well-presented discussion of the basics, like watching a rerun of a TV show you like. The main thing to be concerned about is usually not “talking down” to your audience, but just making sure you’ve got enough time to cover all of the details of your current work.
Also completely agree with letting your personality show in your presentations. Some of the best talks I’ve seen are particularly memorable for the quirky and entertaining style of the presenter as much for the scientific content, and consequently I actually remember the scientific content much better. Of course, a good talk can’t be all style and no substance, either, but even good, important data can be easily missed if the presenter doesn’t properly contextualize it.
On a more puerile note, why oh why did they shorten that Source Extractor software to “sextractor”?
Re: sextractor
I KNOW, RIGHT?
Because it has “sex” in it! Isn’t that funny? We’re so adult, aren’t we?
/snark
There has to be a word for this type of thing: an immature use of “mature” subjects. It’s all over the place.
An invited talk about experimental tests of reactions relevant for supernovae at a Nuclear Astrophysics conference I attended had the title “Probing Horrendous Space Kablooies through Horrendous Laboratory Kablooies”, complete with the relevant Calvin and Hobbes panel on the first slide.
If you’re comfortable with it, a little humour/personality almost always adds to the presentation.
Nothing in the sciencey world will ever give me as many puerile giggles as the Proceedings of the National Academy of Sciences.
Heh. <—see? I can't help it!
As a current scientist and ex-astronomer, I completely agree with your points 1-3. (Personally I need silence to write code.)
Point 1: The web is a truly great resource for programming. I have a poor memory, and long enough career that by now I’ve programmed in about 20 different languages at various times. I’m forever using web searches (aided by those wonderful twin monitors) to look up details on the language of the day – like “What function does R use to concatenate strings?” In the old days, I needed a reference book for every language I used.
Point 2: In addition, write paranoid programs. If a function is expecting single argument which is a positive number, make it check that the argument is positive, and throw an error if it is not. Do this even though you are convinced that the rest of your code will never ever call the function with a negative argument. These “Can’t Happen” error checks find bugs surprisingly often. 20 seconds of writing the error check can save you a day of debugging later on.
Point 3: I agree, use some humour and individuality in your talks. Now here is yet more of that possibly “bad and specific advice”: If someone who did not attend your talk can look at your presentation slides and understand what you’ve done, in most circumstances this indicates a poorly constructed talk – you’re boring or overwhelming your audience by presenting the explanations both verbally and in writing. The information that can come out of your mouth should come from your mouth. The screen is mostly for pictures, plots, equations and tables of data, which you talk about. (This is not absolute – some text is OK.) Also, keep it simple – don’t use elaborate backgrounds or special animation effects. Don’t use multiple colours or fonts unless those colours/fonts carry some meaning or aid comprehension.
Figuring out how much background you need to include so your audience can follow your talk is a real problem. It can help to have contingency slides, which can be more basic than your presentation (“I think my audience will know what the Virial Theorem is, but I’ll add a slide explaining it just in case”) or more advanced than the rest of your presentation (a page full of equations, in case some annoying person asks questions about your maths.)
“If someone who did not attend your talk can look at your presentation slides and understand what you’ve done, in most circumstances this indicates a poorly constructed talk – you’re boring or overwhelming your audience by presenting the explanations both verbally and in writing.”
I *completely* agree. I put in some text slides because there wasn’t a great way to illustrate the information (i.e. what a galaxy cluster is). But yeah, I’m all for pictures and graphs and as few words as possible. I actually had one of the mentors tell me to put in more word slides because my word minimalism was “ridiculous.” Maybe it was, but I don’t think so :-)
Also, the “bad and specific advice” I was talking about was more focused on advice telling people how to prepare for a talk. Like, don’t tell me how to manage my phobia when I’ve spent a decade figuring out what makes me comfortable and enjoyable. (You didn’t do that, btw.) I just thought I’d clear that up.
Sorry for the late, late comment, but I was away at Uluru doing popular astronomy. Being edutained by very smart people.
I’m a Software Engineer/Electrical & Electronic Engineer who’s taught programming to engineers and I can’t agree with Filias Cupio point two more. Write your code to detect input errors and give useful messages. That does mean that every input is going to have 5-10 lines of checking and messages. But it also means that when someone else (or you in a few months time) tries to use it, you’re more likely to be able to. And it will make your life easier right now in two ways: first you have to think explicitly about what inputs are valid, and what aren’t; second when you use it you get useful errors rather than “something went wrong”.
Now that you have some vague ideas, it might also be worth doing an “introduction to programming” course at your uni, because some people have spent their careers working out how best to write code. You can easily learn little tricks that will make your code easier to write, easier to use and faster to develop, as well as the obvious stuff like running faster in less memory. You can pick this stuff up on your own, if you’re a genius with unlimited time, or you can “cheat” by learning from others.
I once spent some very well paid time writing a program to check the input files fed into a widely used Fortran program that normally ran on a supercomputer. It’s simple enough, the input file is 30,000-500,000 lines of text arranged in a specific way. If you get anything wrong the Fortran program says “input error”. After a month I had a GUI program that imported the file, parsed it out, gave you useful error messages and let you edit those blocks in a simple way. The guy I wrote it for was Dr Popular at the next conference when he started selling copies of that program, I can tell you.