Thursday, February 20, 2014

My new webpage

As some of you have probably noticed, I haven't written here for a while.

The reason for this is two-fold: I don't write as much as I used to and I have a new website that I created on GitHub. The new website allows me to post notes and documentation on various projects, which is something I had wanted for a long time but was lacking in blogger.

Go check out the new site and let me know what you think: http://kmdouglass.github.io

-Kyle

Wednesday, December 11, 2013

Beginning a post-doc abroad

As you may know, I recently accepted a position as a post-doc at EPFL in Lausanne, Switzerland. Just about two weeks ago, my wife and I moved to Lausanne and I began my new work.

This is my first actual "job" that I've had. Sure, it carries many simularities to graduate school, but my responsibilities are greater and, on top of that, I'm now living in a new culture. All of these aspects taken together have made for a very exciting two weeks.

By moving to a new country, I hope to experience a little bit of what so many students and researchers experience when they move to the US from abroad. Working in scientific research is tough, but I could only imagine what it was like for many of my colleagues to adapt to a new lifestyle as well. I was, in a sense, jealous of this great experience they were having and of the worldliness they obtained as a consequence.

Of course, there have been difficulties with the move. Language is one such difficulty. I'm learning French, but my skills still remain atrocious. And little things, like the idea that one never gets on at the front of a bus in Lausanne, have led to embarrassing moments with bus drivers and the public.

Overall, though, I'm quite satisfied with my new location and even more so with my work. I have switched my research to biophysics and can feel the excitement of a field that still has quite a bit of knowledge remaining to discover. My lab environment is fantastic and the EPFL campus is energetic and knowledge-driven, which is similar to my undergraduate institution, Rose-Hulman.

To my mind, Academia is special because it not only drives discovery, but also encourages a global-attitude and feeling of trust amongst people from all nations.

Wednesday, November 6, 2013

Tips on communicating science to a class

Yes, I am still alive.

My wife and I just returned from a long hiking and climbing trip out in the western states. It's tough readjusting to normal life after having been on the road for a month, but I've managed to slowly get back into the world of science while I wait out the visa application process for Switzerland.

Today I came across an interesting article in Wired called "A Media Guide for Physics" by Rhett Allain. In the article, Rhett gives a few tips for producers of science TV shows that would help them communicate science better. His tips are
  1. don't be wrong;
  2. it's better to say nothing than to be wrong;
  3. don't be misleading;
  4. [don't focus] on comparisons and numbers;
  5. don't get out of control crazy.
I agree with Allain on all these points, especially the last one. Though this example is not from TV, I've noticed that graduate students (myself included) will tend to describe the minutiae of their research to lay people because they don't want to be wrong and because they've been so immersed in it that they forget what other people know and don't know.

The article also got me thinking about what tips teachers and educators should use when communicating science to their students. The list must necessarily be different because the audience is different. What follows is my own list of tips that I think are valuable to college professors when communicating concepts to a class.
  1. Don't assume that students are well-grounded in the "background" material and concepts.
  2. Don't gesture too much while lecturing. When you gesture, you're referring to an image in your head that only you can see. At least put that image on the board.
  3. Present ideas visually and verbally before going into derivations.
  4. Include a little history behind the concept you're about to teach if there's time. The reasons for why a concept is important are often found in the history of the development of the idea. For example, Newton's laws seem obvious now, but philosophers had some very muddy ideas about motion before Newton formulated them. And all of thermodynamics arose out of a need to understand how newly invented engines and devices worked. If you start a class by talking about molecules in a box, the relevance is lost.
The list is obviously not exhaustive, but I've seen many professors violate one or more of these to the detriment of their students' understanding. What other tips might be included?

Thursday, September 5, 2013

How much time should be spent on coding?

Probably any scientist that went through college starting sometime in the early 2000's knows how to program to some degree. They may have learned how to write computer code to do data analysis, to implement simulations, or simply for fun. In my own case, I had been interested in computer programming since middle school when I first taught myself Visual Basic and HTML (I know, I know, HTML is not a programming language, but it did get me interested in programming).

Now, as a researcher, I often have to temper my enthusiasm for writing programs. It's true that creating scripts to automate data analysis and processing will save me a lot of time in the long run, but I also think that tweaking my code too much or trying to engineer it to do too many things may be counter-productive. After all, code is a means to an end, and my goal is not to write as many programs as possible.

So what's the right amount of time that should be invested into writing code to help with usual laboratory tasks? This is a tough but important question that scientists should ask themselves, since it putting in just the right amount of time should maximize their productivity.

And beyond maximizing productivity, scientists should also dedicate time to writing code that makes it easier to document and reproduce what they did. For example, I have recently written scripts to take the output of a curve fit routine and write a report that includes the fitting bounds, initial guesses, fit functions, and other data that is relevant to reproducing a fit. Hopefully, a future grad student can read my automatically-generated reports and figure out exactly what was done.

So in the end, enough time should be invested in coding when it significantly cuts down on the amount of time taken to do repetitive tasks and when it streamlines documentation and note taking, which may not happen otherwise.

Saturday, August 24, 2013

Onward to the future...

One week ago from yesterday I successfully defended my dissertation, "Mesoscale light-matter interactions," which means that I am effectively finished with my graduate school career (woot woot!). I would offer my dissertation for viewing here on the web, but due to publication restraints associated with UCF, I have to wait one year before disseminating the work publicly. This is too bad, but the decision to do this was largely out of my control.

I'm excited to be moving on to a slightly new line of work. Later this year, I'll be moving to EPFL in Lausanne, Switzerland to work on STORM microscopes and problems in single molecule biophysics.

I'm particularly excited about this work because now I'll be able to apply my knowledge of optics to biology problems. Most of my PhD work was focused on designing new optics-based techniques and then looking for a problem to solve; I hope to become immersed enough in the biophysics community that I can identify unknowns in biology first and then design measurements to address these unknowns afterward. I think a problem-driven route is a more appropriate for the design of optical sensing techniques and I just can't wait to begin.

During my last year at graduate school, I've also begun several endeavors that I believe make me a much better researcher and contributor to science. Some of these new practices include:
  1. Following a paradigm that makes my research as open as possible. This includes making easily reproducible code and sharing data openly. (I'm exploring the use of Figshare and following @openscience on Twitter. Looking at these resources are great starting points).
  2. Related to the first point, I'm writing a Python package for processing dynamic light scattering data and simulating experiments that I intend to release freely and open sourced. I think that my expertise in this area would serve many others extremely well, since DLS is often treated like a "black box" technique by a lot of people who use it for macromolecular studies.
  3. Though my writing has waned since I began serious work on my defense, I want to begin writing again as a means of exploring more topics in research and academia.
  4. I'm structuring my own research around simple questions. I think simple questions, such as "how do cells respond to light" form great, long term questions in science. More complicated questions often lead to short term research goals.
I'll expound on this last point in a later post. Overall, though, I'm beginning to see how I can contribute to my field beyond just publishing.

I won't get started in my new position until November or December. In the mean time, my wife and I are going on a long climbing and hiking trip out West, so you may have to be patient if you're waiting for posts between September and November.

And if you're still working on your PhD or Masters degree, keep up the hard work. It will pay off :)

Friday, August 9, 2013

Making presentation slides flow

Today I gave the first practice talk for my defense presentation to my research group. Prior to today I had been dragging my feet with working on it because making a presentation is fairly boring. It also requires a lot of work, so yesterday I put together quite a few, rather dense slides without taking the time to ensure that the content on each side had a certain "flow," that is,  a logical spatial order to the information presented on them. Now, the slides made sense in the order that they came in, but the information on each individual slide was not so well ordered with respect to other text and figures on the same slide.

Of course, being the first practice, it was a bit rough. But one thing in particular struck me as insightful. I had attempted to tell a story for each slide based on the information that the slides contained. However, since the information was mixed up on any given slide, I often stumbled with the explanations because my attention would jump randomly from one region of the slide to the next.

In prior presentations I took the time to add animations such that graphs or illustrations would appear on a slide as I talked about them. This was a good thing since it automatically gave some nice order to each slide. More importantly, it kept my speech coherent because I wouldn't get confused about what point to talk about.

The downside to making slides like these is that it takes a lot more time. For example, if I have one plot with three curves on it and I want to make the curves appear one at a time as I click the mouse, then I have to in reality make three separate plots!

In the end, though, I think it's worth it. It keeps me talking coherently, it makes the slides aesthetically pleasing, and it enforces a flow with which information is communicated to the audience.


Monday, August 5, 2013

Why we should just say no

Well, it's certainly been a while since I last wrote a post. I have a good reason for it, though. My defense is in less than two weeks and life has been crazy. I'm a bit sorry that I haven't had the time to write lately since it's a good stress outlet, but my mental energies have been absolutely and continuously drained by other tasks.

It's perhaps ironic then that I'm writing this post because it was my lack of time to think about writing that inspired me to, well, write.

From the last few months I've learned the value of saying "no" to requests that people ask of me. It was never really necessary before and I was usually happy to oblige people who needed help with something.

These days, however, I must say "no" if I want to finish the things I need to graduate. And I've come to appreciate that saying "no" to things should apply to more people than just graduate students nearing the end of their work.

I think academics have a hard time with trying to limit the number of projects and tasks they take on. As a result, they and their lab members may become overworked and so attention to detail slips. This often leads to sloppy science, such as not checking hypotheses and assumptions, making conclusions on poorly measured data, etc. At the extreme, it might also be fatal to academic careers.

Unfortunately, I think sloppy science has become very common because, in part, people just take on too many things. I can think of a personal reason for why academics take on too much. I become excited at the start of a new project, but bored near the end, so I tend to start more than I can handle while letting others die off. I shouldn't do this, but I do.

Recognizing that this is an issue is the first step to fixing it. I am glad to see that other academics are slowly fighting back against the status quo and saying "no" to too many tasks. I realize it might be hard at times, but it is very necessary to stay happy and to do good science.