For students: thoughts, hints, projects

Advisors have typically lots of different things to do and to care about, and sometimes it is just hard for them to find the necessary time to provide good feedback to your inquires, emails, projects or paper drafts. Yet, it is in your interest to get the most out of your advisor! So: optimize your input, and help your advisor give you the best feedback possible :-)

The considerations below aim to help you make the most out of the collaboration you have with your advisor - indpendently of the level of your carreer - and to improve the quality of your scientific production. Another very good resource with lots of thoughts on research and teamwork I share you can find on Fabio Casati's personal website.

Should you have any feedback after reading this page, suggestions, corrections, or complaints, just drop me an email, and I will be happy to answer.

About attitude

I think there are some simple attitudes toward work that, if followed, can make the difference (and people happy, including you):

Be interested: If you are not interested in what you are doing, why would your advisor be interested in helping you? Be aware that low interest or passion is hard to hide, and it is easy to guess how excited a student is about his work. Luckily, this is easy to solve: simply choose a topic you are interested in! If you don't feel comfortable with your PhD topic or other work, consider changing it. It's better to "throw away" the time it took you to understand that you don't like that topic than insisting and suffering for your whole PhD or thesis project.
Take notes: One of the simplest instruments to show interest, for example during a meeting, is to take notes. Bring your laptop with you or - even better - a plain old paper notebook and a pen and write down what is being said and action points, especially if they are yours. It's simply a pity if what is being said is lost immediately after the meeting and no progress happens till the next meeting.
Be serious: Taking notes also shows that you are taking work seriously. This is good. But don't be lousy or sloppy, neither with the notes you take, nor with whatever you hand over to your advisor. Sloppy, superficially done work leaves a very bad impression, not to mention that it might backfire: if something is not well done, the risk is hight that the reader won't understand. That's a failure.
Work hard: Doing things right and putting the right care into them takes time. There is not much we can do about it (at least I did not yet find the magic recipe). This means you need to work hard to obtain good results and to present them in such a way that you are also proud of them. Being proud of what you produce is good and desirable.
Be honest: One key ingredient to be able to be proud of your work is not to cheat or trick. If your advisor gets only the smallest feeling of dishonesty, trust is over and very likely so is your collaboration. This is a very sensible issue!

Of course, it is not always possible to be interested in everything, it may happen that someone forgets the notebook, that he/she fell so in love with someone else that some work could not be done properly, or that it could not be done at all. As long as the last point is satisfied, things always work out well.

Basic writing

I know, I am working on IT, that is, information science and technology, and am therefore not supposed to care about this apparently non-technical aspect. However, working with students from all over the world at Bachelor, Master and PhD level, alas, their writing skills make me increasingly puzzled. That is, the absence of writing skills.

Here my point: If you are doing a PhD or Bachelor/Masters thesis, forget about your IT skills. If you are doing it, let's give those for granted. All that counts now is whether you are able to communicate your idea or not. It is a common convention that communication happens in natural language, not in HTML or Java. That language is typically English. So, you must be able to write decently in English.

More and more, I consider this point important. Sometimes, I even go as far as to say that, when interviewing a candidate for a new PhD position or an internship, it would be a good idea to tell the candidate just to sit down and write a short essay about some random topic. In English. Perhaps a topic related to the open position, but not mantatorily. The topic is not important, but the quality of the writing. It just happens so often that, when trying to give feedback to a paper draft by a student, I get distracted by language issues and forget about the actual content of the draft. Therefore, you must strive for a good and fluent English!

Three hints on how to improve your English:

Be aware of the problem: The first step of learning is recognizing the problem. Listen to feedback, compare with others, self-assess your skills. If you identify some lacks, don't be upset. Just learn.
Use dictionaries: Mastering the right vocabulary is one step. How do you learn it? By reading papers and, of course, by using dictionaries. Don't use only bi-lingual dictionaries that translate words from one language into another. They usually don't tell you how to use the new words you just learned. Look for "advanced learners" dictionaries. These tell you how to use terms and provide good examples. I personally use dictionaries on an everyday basis. If you just want, you can find them everywhere nowadays: in book shops, in the Intenet, on your computer (if you have a Mac, use the built-in dictionary!), on your mobile phone, etc. Here some links: Macmillan Dictionary, Oxford Dictionary.

Check this out: I just started reading the book The Pyramid Principle by Barbara Minto (2010) (thanks to Martin Gaedke for pointing me to it). It explains how to bring structure into text and how to effectively communicate your thoughts - the second step of writing. I'm still reading, but I can already tell that this should be a mandatory reading for every student. I know, there are also critiques about that book (e.g., about Minto coming from the area of consultancy and not research), but I think everybdy with a minimum flexibility of mind will find lots of good hints in that book, which only need to be applied to the context of research or technical writing.

I know this may seem far away from programming and research, and I admit it somehow is, but it is in your own interest that your work is also properly understood by your audience. If they don't get it, they don't buy it.

Scientific writing

This is somehow a story in itself, but it starts from giving for granted the previous point. That is, we assume the right vocabulary is there and it is clear how to structure text. The problem now is how to write a scientific paper. Hard to say. Each paper is different, each scientific community has different conventions and styles, each topic may require own approaches, etc. Again, I don't have a solution, just some ideas of how to approach the problem that worked for me in the past (at least, I like to believe so).

The single most important rule here is: Read, read and read! Reading lots of papers (good papers!) by others doesn't tell you only about what these authors do; it also allows you to learn some domain-specific vocabulary and area-specific paper structure conventions. For instance, if you want to write a paper for conference X, go and leaf through lots of papers published by conference X in the past. Understand what the community X is interested in, where they usually place the state of the art, whether they like to see an explicit problem statement or not, how they describe the implementation, whether they like to see formal, mathematical proofs, performance tests, user studies, or whether a well-done case study may suffice, etc.

I call this meta-reading. You read a paper not to learn about what the authors have to say, but to understand how they say what they have to say. Look at how content is structured into sections, at how section titles are chosen, how text is strucured and given meaning by using numered or itemized lists and paragraphs, what the key messages of each section of the paper are, which the key message of the whole paper is, and so on. It's like movie actors who learn how to act: it's all about the form (gestures, expressions, accent), not the content (each movie is different, after all, just like papers).

Scientific papes vary very much from community to community. In psychology, for instance, there is typically a hypothesis the authors want to prove or disprove. So, they identify a test setting that allows them to gather the necessary evidence (the data) to make a statement about the thesis, they perform the test, analayze the collected data, and draw their conclusions, i.e., the accept or reject the hypothesis. To give you an idea of how these papers typically look like (and also to have some fun), read the paper by Bègue et al. (2013) demonstrating that people that think they are drunk also think they are more attractive (the paper is among the winners of the 2013 Ig Nobel Prize) or the paper by Cholakians et al. (2009) about the famous "beer goggles" effect. Both easy to read and understand and instructive.

A scientific paper in our context is typically more complex. Of course, there is some hypothesis to be proven. It's not always easy to indentify it, but it must be there somewhere in the paper, e.g., called "claims" or "contributions" or similar. But here is the complication: this hypothesis is usually not about some human behavior or natural phenomenon; it's about a technical artifact (e.g., software in the domain of computer science). The problem is that this technical artifact must first be constructed so that it can be studied, and it must be constructed in such a way that (i) the reader can understand it, (ii) he/she agrees that its construction is correct, and (iii) he/she can associate a real need/value to it. Attention, if your reader does not get these three points, the very acceptance of your hypothesis may by useless. This is the complication! Not only is there a hypothesis to be accepted/rejected, there is also a technical artifact that must be properly designed (which requires good technical and engineering knowledge) and motivated (which requires good knowledge of the state of the art). Since the claim here it typically that the technical artifact solves some problem, the problem statement assumes a key role. If you don't convince the reader that there is a problem, whatever solution you propose is useless. However, if you do convince the reader that there is a problem, he/she will be accommodating regarding the solution you propose.

In short, when writing a paper carefully think about the problem you want to solve and put all your effort into convincing the reader that the problem is real. To be precise, always clarify your goals, assumptions and requirements before starting with the explanation of your solution.

Here some useful references for those who want to deepen this aspect and improve their writing skills:

All the papers you can read. As said, both reading and meta-reading if well done are exceptional sources of writing knowledge.
The Elements of Style by Strunk and White (1999). Actually, I did not read this book myself yet. I just leafed through it and have been told that this book contains some very good hints of how to approach scientific writing.
Scientiﬁc Writing for Computer Science Students by Wilhelmiina Hämäläinen (2006). Very good recap of the fundamentals of scientific writing and the most recurrent errors and pitfalls. Everybody should master what is explained here!
Paper What does an Associate Editor actually do? by Graham Cormode (2013). This one I read, and enjoyed. Its actually not so much about writing itself and more about understanding the process of paper selection in scientific journals. But nevertheless it provides some very good (and nicely presented) insights, which you should not miss if you want to submit your paper to a journal. Some lessons also apply to conference submissions.

Presentations

Giving a good presentation is a hard task. I think I haven't seen perfection yet in this context, and I don't think my own skills are any better than those of the average researcher. However, I think there are some simple tricks that everybody can apply to obtain decent results:

Like for papers, also here try to learn from others. When you attend a presenation you like, try to understand why you liked it. Was it only the content or also the way things were presented?
Always think about your audience. Never give a talk without first thinking about what your audience actually wants to hear and know, what their background is, what they are interested in.
If your presentation is not longer than 30 minutes, forget about the initial "table of content" or "structure of the presenation." You already have only little time. You cannot waste precious minutes to talk about your presentation instead of giving your presentation.

Put care into the design of your slides, both in terms of language and style/layout. One rule you will often hear in this context is "less is more," meaning that you communicate better if you don't overload your slids with content that only distracts your audience. Have a look at the books Presentation Zen by Garr Raynolds (2011) or Resonate by Nancy Duarte (2010) for best practices and get inspired.

Research

Just a nice presentation by David A. Patterson on how to have a bad career in research/academia. Have a look and enjoy!

Writing a survey

Instead of developing new software, sometimes research or a M.Sc. thesis may survey the state of the art in a given domain. Writing a good survey is not easy and requires some methodology and care. Please find here a brief summary of my ideas on how to write a good survey. As usual, consider this document work in progress to be updated, e.g., also based on your feedback.