CRA-W Grad Cohort: Tips For Finishing Your PhD

What does finishing a PhD mean and what will it take? Prof. Padma Raghavan, Pennsylvania State University, gave us a fun and informative session on taking it from proposal to thesis to defence in as pain-free a way as possible.

First, a note on the thesis. Remember to never throw away writing. Let's say you wrote a really nice background section for a conference paper that you later have to shorten due to page count constraints. Don't just delete text - save the old version! You might be able to use it later in your actual thesis. Also, even though you might write your introduction chapter last, be sure to always keep a general vision for it in the back of your mind. Finally, plan for around 3-5 major ideas, which will likely be individual chapters in your thesis.

On to the ten tips for finishing...

1. Take Charge

• Be self-motivated. It's just you and your thesis.
• Make things move along, be active, take charge - don't wait on others.
• Program yourself to do the tedious things, and reward yourself afterwards.
• Figure out what your motivation is for getting a PhD. Get excited about what comes next.
• Don't compare yourself to others - just because your lab mate finished in three years doesn't mean your topic is conducive to doing so as well.
• Think in active language. Tell yourself "I will finish my thesis by...." instead of "My thesis will be done by..."

2. Balance Life and Work

• Remember: there are only 24 hours in a day!
• Know the point at which you are too frustrated or tired to be doing your best work.
• Know your body rhythms (sleep, etc) and work with them instead of against them.
• Stay physically active.
• Take time to do other things that make you feel creative, entertained, happy.
• You are balanced when you (usually) feel happy about all parts of the day, from school to personal life.
• Be sure to make time for other things.
• Don't be half-hearted about time off. Stay focused on enjoying it.
• Don't hesitate to seek help.

3. Leverage Your Proposal

• When working on the actual thesis, start with the results of your proposal.
• Incorporate feedback from your proposal defence, where you should assign a scribe to take notes so you can fully engage in conversation.
• Think about whether the proposal reflects a viable plan of work.
• What are the sub-problems of your research? How many of them have you solved?
• Should you do the easiest sub-problem first, or the one with best results so far? If something doesn't work out as planned, do you have alternatives?

4. Leverage Your Committee

• Committee members can offer different perspectives on your research.
• Be on the look-out for any misfits and try to work around it.
• If an advisor leaves or is otherwise no longer able to work with you, one of your committee members might be able to take over (or co-supervise as the case may be).

5. Set a Target Date, Work Backwards

• Start with a deadline and then work back to figure out what you have to do to meet it.
• For example, if you set a graduation date, you have motivation. You can set milestones for each semester leading up to it, including defence dates. (This isn't always possible, such as when you want to have a baby during the PhD.)
  
• Be sure to allow time for committee reviews and job searching.
• Don't pack your last year with too many activities since job searching can take a lot longer than you might think.
• Allow time for delays and setbacks.
• Keep a game plan posted at your desk: a one page list of major activities and their time line. Writing it down makes it more important.

6. Manage Your Time

• Use your game plan from above to prepare tasks and goals for the week.
• Include internal deadlines (i.e. your own soft ones) that are based on (hard) external deadlines.
• Assess and adapt as needed.
• Check: are you making progress? Are you off on your semester plan, and if so, why?

7. Start Writing!

• Most don't budget enough time for writing.
• Don't need to write thesis from scratch - reuse writing from conference papers, etc.
• You may need 2-3 major revisions to the overall structure before it's accepted.

8. Engage in Your Career Search

• Which career path is right for you?
• Your grades don't really matter (they're in the past). Your vision for the future matters!
• Tune your interviews to the place you are applying to.
• Keep working on your thesis!

9. Prepare for the Next Step

• Take a leadership role in your research group.
• Travel to conferences, engage in lots of professional networking.
• Seek out and take advantage of resources available to you.

10. Prepare for Your Defence

• Sit in on other defences.
• Practice.
• Communicate with committee members, address serious concerns early.
• Defend, but don't be on offence.
• Be rested and refreshed.
• Defend on a Friday - apparently that helps. ;)
  

CRA-W Grad Cohort: Finding a Research Topic

What makes a topic appropriate for a PhD dissertation? What is and isn't computer science research? What should you do when you're stuck? All these questions and more were answered by Prof. Lori Pollock from University of Delaware in the CRA-W Grad Cohort talk on choosing a research topic.

What is computer science research?

• Research is the systemic investigation to establish facts and reach new conclusions.
• We don't know the answer or how to get it.
  
• Experimental research involves:
• observing a problem
• generating a hypothesis
• developing a strategy to solve the problem
• performing experiments, demonstrating evidence
• interpreting results
• Theoretical research involves:
• identifying an open problem
• proofs, analysis of hypothesis
• a possible combination with experimental research

What isn't PhD research?

These ideas were generated from audience discussion. I suspect some of these are probably worthy of a Masters dissertation, but be sure to ask the experts before assuming as much!

• Figuring out how existing software applications work (though this might be part of the observation stage of research).
• Implementing an existing algorithm or solution (again, might be a step toward completing the overall research).
• Comparing various solutions against a benchmark.
• Developing new metrics for comparison, unless you can show why the new benchmarks are useful or give new information.
• Putting together software components in a new way, unless you can show that you are solving the problem in a better way by doing so.

How do I choose a topic area to research?

• Make sure the area grabs the interest of you, your supervisor, and your research community.
• Gain breadth (say, in your courses) to broaden your options.
• Love your topic! You will be spending 2-3 years on it, and it may be defining your post-grad options.
  
• Think about your strengths and weaknesses. Are you good or bad at programming, design, data analysis, or proofs?
• What drives you? What bores you? Technology, puzzles, applications, interdisciplinary work?
• Check how much funding there is in your area.
• Did you find an advisor before your area? This is fine, but know that it may limit your choice of area.
• Make sure you find an advisor that in knowledgeable in the area you will work in, and that is compatible with you in terms of working/mentoring style.

Moving from an area to a specific topic

• An 'area' is too broad for a thesis - must narrow down to a specific topic.
• A topic is a set of open questions, or a well-defined problem.
• Characteristics of a PhD topic (from audience discussion):
  • novel, open problem
  • high impact
  • non-incremental solution
    
  • community is interested
    
  • can measure success

Seven ways to identify a good research problem

1. Flash of brilliance: You wake up one morning with a brilliant idea. This is rare, and you will have a hard time selling the idea to your supervisor.
   
   
2. The apprentice: Pick something from a list of topics your advisor has. Be careful that you are not picking something boring, fruitless, or that other students might also choose.
   
   
3. Extended course project: Take a project course that leads to a new perspective. You may get lucky and be able to extend it to a thesis topic, but if not, you may get distracted from your topic search.
   
   
4. Redo, reinvent: Identify improvement to an algorithm or proof, discover a new topic. This may lead you to be without a topic for a long period of time, and you run the risk of it not being dissertation worthy.
   
   
5. Analyze data: Help a senior student with their project, potentially leading to new open challenges and a new topic. Be sure to agree which of you will actually get to work on the open problem.
   
   
6. The stapler: Weave together a number of small topics (such as those from various conference papers). Finding the tie might be challenging.
   
   
7. Synthesis model: Read papers, make connections, get insights. The downside is you may spend lots of time reading papers without a topic.

These seven ideas were credited to someone else, but I can't remember who. It's also worth considering how they might be combined together.

General tips (and what to do when stuck)

• Both your topic and your advisor are important to your success.
• Keep a research ideas journal and wiki (I use private Google Docs to make notes to share only with my supervisor rather than the whole world, as would likely happen with a research blog).
• Keep an annotated bibliography. (See these posts for advice on organizing your research papers.)
• Follow your interests and passions.
• If you just aren't really getting into the topic, adapt!
• Read and present papers regularly to find open research problems (pay special attention to the future work section, often in the paper's conclusion).
• Work with a senior PhD student on their research.
• Actively participate in research meetings.
• Get feedback and ideas from others. Attend conferences, listen for open problems, talk to attendees, do internships.
• Read a PhD thesis in your area.
• Read advisor's grant proposals.
• Attend thesis and proposal defences.
• Assess your progress with your supervisor.
• Divide your project into milestones.
• Remember that change can be invigorating, but it can also slow you down.
• Also remember that you run the risk of being scooped if you are choosing a topic in a hot area.

Conclusion

Prof. Pollock recommended the ACM articles on How to Success in Graduate School (Part I and Part II), which I haven't read yet but am about to. If you are further along in your PhD, I'd love to hear which of these tips worked (and didn't) for you, and any other advice you have.

CRA-W Grad Cohort: Presentation Skills

What makes a good oral presentation? According to Prof. Sandhya Dwarkadas (University of Rochester) and Ana Pop (Princeton University), there are three main areas of concern: Content, Design, and Delivery. These come together to help disseminate what's important about your research, help you explain your ideas, and possibly even sell yourself to venture capitalists.

The content is the 'what'. Can you motivate your research with examples of previous work? What is your contribution or approach? Is the work mature? Have you tested out many corner cases? How sound are your results and analysis? Remember, you are the expert.

The design is used to drive the point home. You need to isolate the key points of your talk, simplify them, and repeat them multiple times. You must know your audience and speak to their level. Start with a meaningful outline of your talk that isn't so generic it could be applied to any other talk. Remember that it's impossible to cover all of the details of a 10 page paper in a 20 minute talk - you just want to sell the idea to encourage listeners to investigate further and read your paper.

Finally, the delivery is how you give the talk. Eye contact, volume, pacing, enunciation - it's all important, and if you need practice, join a group like Toastmasters. Contrary to popular belief, oral presentations are a skill you can learn (you don't need to have an innate talent!).

Some tips for improving your abilities:

• Tape your talk and watching it.
• Practise several times with your research group and get feedback.
• Memorize the first 5 minutes of your talk; it will calm your nerves, and the rest will flow afterwards.
• Leverage your nervous energy and adrenaline.
• Work on your flow: motivate your work, foreshadow, reiterate the main points, summarize.
• It's ok to have brief moments of silence, so try to remove unnecessary fillers ("ummm").
• Come prepared with multiple copies and formats of your slides. Test the projection system ahead of time when possible.

These are just some of the great tips given. I do want to mention, however, that I felt the speakers didn't follow some of their rules in their own slides, using far too much text and detail for example. I also disagree with their assertion that a slide with just a title and a picture is necessarily a bad thing - I am a big believer in minimalist slide design, and use my speaking abilities to engage the audience without relying on overly busy slides. Some of their "do this instead" slides were far too crowded in my opinion, and would have had me tuning out almost right away.

My tip is to leave only 3-5 points on a slide with only 3-4 words each (just the most key parts of a phrase!). Some slides can have just a diagram or photograph when appropriate. All that other text you started with? Just put it in the notes section. You can even publish your slide show as a PDF with the notes if you want people to get all the information. Practice speaking effectively with this style of slides and your audience will thank you.

Not All Women's Groups Are Harmful

After reading Hilary Mason's Stop talking, start coding article, I was thinking about writing a reaction. It slipped my mind until Terri Oda wrote her piece Women in computing groups considered harmful? She gave me the opportunity to reflect on what our Women in Science and Engineering group has been up to at Carleton University (CU-WISE), and why I think not all such groups are all that bad.

This is the part of Hilary's article that stuck out for me:

Many groups have popped up that support women in technology, like Girls in Tech, She’s Geeky, and many others (enumerated in Digiphile’s thoughtful post Why Including women matters for the future of technology and society). More often than not, these groups are the canned food drives of the women in technology movement. They make you feel better, they might do a little good, but they offer no fundamental change to the system that created the problem in the first place.

I remember sitting down with our Dean of Engineering to discuss CU-WISE budget opportunities. Dean Goubran has been incredibly supportive of CU-WISE, but said one important thing: he wanted to see less talking and more doing. He figures people have been sitting at conferences talking about the problem for at least 20 years, but the problem remains. What is it that CU-WISE will do to actually change things?

This was a tough question, especially for a group that had only been around for about a year. How would we know that we've made a real difference?

It's still hard to know for sure, but I think we're getting better and better at this all the time. For example, when I do outreach with groups of girls, I ask them hard questions about why there aren't many women in computing, and why it matters. Their insightful answers impress me and give me hope for their generation.

But we can't really measure how effective our outreach is. At least not yet. I do think it's important to get out there and make the image of computer science and engineering a more positive one, but we won't really know if our attempt is working until much later.

I do often hear a number of women attending CU-WISE events express their gratitude for the existence of such a group. I'm not sure we've saved anyone from dropping out or changing majors, but it does seem like a possibility. But this, too, is hard to measure (I suppose we should attempt to do a proper survey someday!).

So I look to the events we've been holding this past semester. Not a single one revolved around a discussion of the issues women in science and engineering face. The first was an opportunity to put our knowledge of technology to use in the IBM Extreme Blue Case Study Competition. Next, we gave our members the tools they needed to succeed in industry, teaching them skills like networking and negotiation at WISE Steps to Success. We had a smaller presentation on entrepreneurship and then held the very successful Celebration of Women in Science and Engineering.

That last one, the Celebration, had a lot to do with doing. Most talks were women simply presenting their research. As Hilary put it, we got together to "do science."

Based on all this, I think CU-WISE has done a good job of disproving Terri's theory to an extent:

Theory: The more time we spend on women in computing initiatives, the less time we have to actually get stuff done.

Naturally, some of our time must be taken away from doing if we are on the CU-WISE executive team, so we must be careful to balance the commitments properly. (This is something I didn't quite get right during my Masters but have improved thus far in my PhD.) I'm hoping that our group does a good job of encouraging our members to do the most doing possible.

And if we succeed, I think we will be far from harmful.

CRA-W Grad Cohort 2010 Next Week

I'm very fortunate to be attending my second CRA-W Grad Cohort next week. I also went last year when it was held near San Francisco. This year it will be near Seattle, and am very excited that I have a couple of school friends (and fellow CU-WISE members) to go with. We are even scheduling a bit of time in Vancouver before heading to Seattle on the train.

I wish I had known about this event during my first year of grad school. I'm not sure why, but I had never really talked about the topics covered there back at home. As a result, it wasn't until close to the end of my Masters that I truly "got" grad school. Partly because of the great insight I gained, I managed to finish my thesis and graduate, and move on to my PhD, where I've already been able to make good use of the advice.

I'll be sure to write about this year's cohort as soon as I can, but to keep you going, here are the posts from last year. There's a load of good advice in there so I definitely recommend checking it out.

• A Short Summary
• PhD Academic Career Paths
• Being a Woman in Technology
• Balancing Graduate School and Life
  

If you're attending the cohort this year or live/work in the Seattle area and want to connect, let me know! I'm also looking forward to seeing some familiar faces from last year's cohort. Seattle, here we come!

Celebration a Success!

Last week Carleton's Women in Science and Engineering hosted the very first Carleton Celebration of Women in Science and Engineering, and it was a great success!

I organized this event after being inspired by the Grace Hopper Celebration of Women in Computing. The networking opportunities, the ability to find role models, the chance to hear the latest and greatest research being done by women in my field... I wanted to bring that to Carleton, even if it would be on a smaller scale.

My main goals were to showcase what the Carleton ladies in science and engineering have been up to, and to give us an opportunity for us to network, since WISE spans so many technical and scientific disciplines. I think we succeeded on both counts!

In terms of getting the word out about what we do, I had a media advisory sent out from Carleton's external communications office and managed to get an interview with the CBC, Canada's public broadcasting company. Terri and I prerecorded an interview with the Morning Show host Kathleen Petty to be played the morning of our event. In addition to the actual event, we talked about what got us into computer science, why women are such a minority, and what to do about it. Terri's boyfriend recorded the interview as it streamed online, and you can listen to it now from the CU-WISE website.

During the event, I saw so many new connections being made. For example, there were a few talks from biologists, who many of us engineers and computer scientists would never have had the opportunity to meet otherwise; some of them are even jumping on board to help out with CU-WISE. There were also multiple people talking about their outreach efforts, some from science and some from engineering, and now they want to work together. The networking continued during the speaker's dinner (which was covered by the event's funding).

I can't tell you how happy I am with this event overall. With the help of my fellow CU-WISE executives and officers, the room looked great and the day ran perfectly smoothly. Every single speaker did an amazing job. The quality and enthusiasm was nothing less than exhilarating. Thanks to everyone involved!

Balancing the Needs of Industry and Academia

As I embark on this journey that is a PhD, I constantly remind myself of my goal of remaining useful. I want to retain practical skills that could be used in outside of academia and research labs. I never, ever want to forget how to code, and I'd preferably be able to continue to say that I can code well.

And so with the unusually good timing the universe sometimes provides, I stumbled on a great article in Communications of ACM called What Should We Teach New Software Developers? Why? by Bjarne Stroustrup. It discusses the disconnect between what industry wants from computer science graduates, and what universities aim to teach.

Industry wants computer science graduates to build software (at least initially in their careers). That software is often part of a long-lived code base and used for embedded or distributed systems with high reliability requirements. However, many graduates have essentially no education or training in software development outside their hobbyist activities. In particular, most see programming as a minimal effort to complete homework and rarely take a broader view that includes systematic testing, maintenance, documentation, and the use of their code by others. Also, many students fail to connect what they learn in one class to what they learn in another. Thus, we often see students with high grades in algorithms, data structures, and software engineering who nevertheless hack solutions in an operating systems class with total disregard for data structures, algorithms, and the structure of the software. The result is a poorly performing unmaintainable mess.

There are some amazing software developers that come out of Carleton's computer science program. Some have even gone on to start their own successful companies. But there are also a lot who don't find meaningful internship experiences, and who have rarely (or never) written large software projects in a team.

Things look even more bleak for many grad students, for whom getting something that works just well enough to prove a particular result is more important than writing good, reusable code. I know I've definitely learned how to do exactly what is needed when it comes to course projects, and though I always wish I could do more, I know it is just not possible. Once courses are done, though, there is a great opportunity to keep your skills in check. I try to choose projects that require me to write code, and lots of it. I am also considering dabbling in the world of entrepreneurship to give myself an opportunity to write real-world software that needs to work well.

For those who aren't sure what they need to do for industry, or just can't find the right job or project to practice it, it would be nice to have a bit more balance in the degree programs themselves.

Industry would prefer to hire "developers" fully trained in the latest tools and techniques whereas academia's greatest ambition is to produce more and better professors. To make progress, these ideals must become better aligned. Graduates going to industry must have a good grasp of software development and industry must develop much better mechanisms for absorbing new ideas, tools, and techniques.

I can't really speak for the industry side, but I am intrigued by the changes that faculty in Carleton's School of Computer Science are trying to make. Program streams like the upcoming option nicknamed the 'iPhone stream' are meant to provide the same core computer science as everyone else gets with a few extra classes geared towards a career in industry. Granted, these streams are focused on only a narrow portion of industry, but they are definitely a start.

This balance between academia and industry isn't going to be easy to achieve. I honestly don't know exactly how it should work. I like Stroustrup's suggestion of encouraging profs to code, but somehow that doesn't seem to be enough. It also always happens that when changes are proposed to our degree to help students be better prepared for industry, some students cry out that the program is being dumbed down, and that if you want to be so industry-ready you should go to college instead of university. Figuring out how to get the best of both worlds and make everyone happy won't be a fun job, but it's one worth talking about.