Before I get too deeply into the Is computer science a science? series, ScienceMama suggested that I give my non-computer scientist readers an idea of what computer scientists actually do on a daily basis.
I'm going to focus on what I do as a research scientist. Hopefully some of my readers who are working as computer scientists in industry/government will chime in in the comments with a snapshot of what they do as well.
So, what does a typical research-focused day in my life look like?
MORNING:
First thing: check email, very briefly, just to make sure I don't have to put out any fires or talk students off a metaphorical ledge.
I then spend the next 30-60 minutes working on my most important project. If there's a deadline approaching, this means writing/editing a conference or journal article or grant proposal. If there are no deadlines coming up, I'll tackle my most difficult research problem. Often I'll choose one that requires some thinking/planning/analysis. So I'll sketch out, on paper or on my board, a system design, or some coding diagrams or outlines, or an algorithm (a recipe for solving a problem). I'll occasionally work through some equations or work on mathematically modeling some aspect of a system. If I'm in the midst of some really tricky data analysis, I'll fire up Matlab and slice and dice the data in various ways to see if I can find some pattern I missed before. Whatever requires the most brain power and attention.
(By the way, I do this on teaching days as well. That way, even if the rest of the day gets away from me, I've spent at least a half hour working on research.)
I often have office hours later in the mornings on my research days, or meetings with research students, and this is also when colleagues tend to want to drop by and chat. So I'll spend this time working on stuff that's interruptible: debugging code, setting up and running experiments to collect data, data analysis, writing some easier code (scripts to process/analyze data, for instance, or automate experiments). I can sometimes get some writing done, too, particularly if I'm making tables of data or writing up results.
Right before lunch, I'll try to wrap up whatever it is I'm working on, and make some notes as to next steps. (I keep a pretty detailed lab notebook, and I'd say almost half of it is to-do lists.)
LUNCHTIME:
If I'm lucky, I'll actually get to eat lunch away from my office with Real Live Colleagues. People love to schedule meetings during lunch, so that's what I'll often do. Often, though, it's me and the computer, catching up on the news (real, tech, and sports).
AFTERNOON:
Afternoons, especially early afternoons, are my low-energy times. Deep thinking is out, but for some reason, afternoons are the best time for me to write programs. Maybe because it's a task that engages me enough that I forget that I'm tired? So I'll often do the bulk of my coding in the afternoons. Some days, this could mean I'm writing simulation programs in Matlab. Other days, I could be working on a prototype or proof-of-concept for a system or a piece of a system, or implementing a particular algorithm. I will sometimes map out experiments, and sometimes run experiments in the background while I'm programming. If I need to troubleshoot a piece of equipment or one of my testbeds (a group of computers set up to accomplish or test out a particular task or idea), or crawl around rewiring things in my lab, afternoons are a good time to do that.
If I have to do any class prep on a research day, I'll often work on it in the afternoon, too.
I write notes to myself in my lab notebook as I go along. At the end of the day, I finish summarizing what I did, what the big issues/roadblocks are currently, and list next steps. The last thing I do before heading home is write out a to-do list for the next day.
EVENING:
I often have to work an hour or two in the evenings, but this is usually dedicated to class prep. Sometimes I will troubleshoot something that didn't work during the day that is really bugging me; sometimes I will bounce ideas off Mr. Jane (who knows enough about my subfield to be helpful).
So that's a glimpse into a research day in my life as a computer scientist.
- Log in to post comments
Thanks, Jane, for posting this summary of a typical day! My son is a programmer in Germany, but I was just a bit too old to enter that world, although it fascinates me.
You're so organized... I'm totally jealous.
I really need to work on putting to does and random thoughts in my notebook - instead of just what I did.
Interesting to hear how you spend your days. I agree with the others, I'm impressed by how organized you are. I tend to jump around a lot which isn't really the best strategy.
Nice description and useful too. I'm impressed by the lab book strategy and how organized you are.
I *have* to be organized, otherwise I'd never get anything done!
Plus it's saved me a few times---I will sometimes put aside a project for months, and when I go back to it it's nice to have a record of where I left off. (I've had the experience of having a Fabulous Idea! as to what to do next on a project, only to go back to my notebook and find that I already tried the idea.) And it was invaluable when I had the baby and didn't work for a few months.
Just out of curiosity, is your lab notebook a "real" notebook, or do you have it in some e-format?
You consider debugging an interruptible task? You surely mean debugging small scripts, don't you? You don't really write complex programs if you consider debugging an easy task that doesn't require larga amounts of deep concentration.
Steve, it's a real, paper notebook. I've tried electronic versions and they just don't work for me---there's something about the act of writing notes down that imprints them on my brain, or something. I guess when it comes to big ideas, I think better on paper than on the screen.
Alex, it depends on the scope of the bug, but yeah, I find it hard to sit there for long stretches of time debugging. Even with tricky bugs, I find that I can't concentrate for, say, more than 20 minutes. And I guess I've developed a method of debugging that lends itself to interruption. So it works for me, surprisingly.
this was really usefull infromation and it really helped me out on my project THANK YOU!!!!!