11  Academic Practice

The final chapter of this book summarizes miscellaneous practical topics related to academia, namely presenting our findings, financing research, and academic career.

11.1 Presenting

There are many opportunities to present our research, including conferences, thesis defenses, and project summaries for various committees. Similar to writing a paper, where we empathized with our readers, we have to ask one important question before preparing a presentation: Who is my audience? Then we need to design our presentation on a level appropriate for the audience: explaining that Haskell is a functional language at a functional programming conference might seem condescending, while a grant committee including non-computer engineers would require a longer explanation of the context.

Two common forms of presentation are talks, usually accompanied by slides, and posters.

Posters often appear at conferences, where they are typically used either to present early-stage research or to complement a full-paper talk. An ideal poster should present main points, visible from a greater distance, and explain some details, but not as much as the whole paper. The presenter can provide further details when asked by other attendees. Perhaps the most important rule about posters is to prefer graphical content over text. For more ideas, we can refer to the tips for a good poster.

In the next subsections, we provide guidelines for talks with slides, mainly inspired by Zobel (2014) and the author’s own experience.

11.1.1 Content

In a relatively short presentation, it is best to present only one main idea and its prerequisites, i.e., facts necessary for the understanding of this idea. A presentation should include at least motivation, possibly with an example, the designed approach (if any), a brief but clear overview of methods, main results, and conclusion. We can mention the most important related works directly motivating our research, not listing them extensively.

Generally, it is difficult for the audience to be focused during the whole presentation. The audience will quickly lose track if we include non-essential technical details, such as long listings of auxiliary algorithms or proofs of too many lemmas. For a similar reason, we should minimize the amount of content that the audience must remember from previous slides.

A common beginners’ mistake is to allocate too much time for context, motivation, or some other specific part of the presentation. The individual parts should be balanced unless there is a specific reason not to do so.

11.1.2 Form

A general guideline is to prefer figures over text where possible, as they are generally easier to process by quick glances while the speaker talks. Not everyone has perfect sight, so we should use a large enough font, not trying to squeeze everything on one slide. Screenshots of tables from the paper tend to be particularly unreadable, so it is best to rewrite them using the presentation’s style and simplify them if desirable.

Unless we deliver an hour-long keynote, starting with a Table of Contents slide is not necessary because it consumes valuable time from our presentation. Similarly, ending a presentation with an empty “Thank you. Questions?” wastes space and leaves the attendees without context. Instead, we can show a slide with a summary of the main points to spark a conversation.

11.1.3 Delivery

Presentations usually have a strictly allocated time that needs to be respected. As a safe estimate, we can plan about one slide per minute. In the case of shorter slides, the tempo can be increased up to two slides per minute. Ideally, we can rehearse the whole presentation and measure time. If we do not have this possibility, we can put less important stuff at the end of the presentation if it makes sense.

At the very least, we should imagine in our minds what we will talk about each slide. After conference talks and thesis defenses, questions tend to follow, so it is helpful to prepare for the most probable questions.

11.1.4 Tools

The whole look and feel of the presentation is shaped by the tool that we select to create it. For instance, if we create our presentation in a text editor using an HTML- or Markdown-based framework, we can be tempted to use more text and fewer images. As an opposite extreme, a vector graphical editor will tempt us to draw a lot.

The selection of the best tool thus depends on the specific situation and our goals. As a default choice, for a presentation that neither impresses nor disappoints, we recommend using standard slide-based tools, such as LibreOffice Impress or PowerPoint. They also come in handy for tight deadlines because we do not have to learn a new tool with unexpected glitches. Presentations heavy on math or containing LaTeX-produced diagrams benefit from the LaTeX’s beamer package. To grab attendees’ attention, we can try some of the alternative applications, e.g., Canva or Prezi if we have a time and desire to experiment. Finally, for interactive content embedding and custom scripting, frameworks such as reveal.js or Slidev are the best fit.

11.2 Financing Research

Research has its expenses, which include the staff salaries and students’ stipends, material (hardware, software, books, etc.), travel to conferences, open access fees, and others. The primary sources of research funding are regular public funding of universities and research institutes, public grants, private donations and grants, and tuition fees. The next two sections discuss grant applications and research evaluation, which is often used to allocate public funding.

11.2.1 Grants

A research grant is a financial award, usually bound to a certain topic and time frame, given to a researcher or a group of researchers by a grant agency or other organization. To try receiving a grant, we need to choose an appropriate call and submit a grant proposal. Each grant call specifies exact requirements, but generally the grant proposal contains:

  • a context, problem statement, and literature overview,
  • a sketch of our proposed solutions,
  • a budget listing the expected expenses,
  • information about a principal investigator and other members of the research team,
  • and the investigators’ past achievements: publications and past grants.

After receiving a grant, we are usually expected to submit annual or final reports with achieved results. Most grants also require us to mention their number in the Acknowledgment section of each paper that was supported by them.

If we have a paper accepted at a high-quality conference but do not have sufficient funds to travel there, as a last resort we can sometimes apply for a corresponding ACM SIG fund, e.g., SIGSOFT CAPS for software engineering conferences.

11.2.2 Research Evaluation

Research funding is often allocated according to the researchers’ achievements, either directly by dividing a fixed sum of money according to some quantitative criteria or indirectly by preferring high-performing researchers in grant applications. However, how to quantitatively measure the quality of research?

Perhaps the most obvious way to measure a researcher’s output is to simply count the total number of publications. Of course, this favors many low-quality publications, so other metrics are necessary. The total number of citations of a researcher can give us some indication of quality, assuming high-quality works get more citations. A metric called h-index was devised to combine both publication and citation counts. A researcher having an h-index of \(h\) has \(h\) publications that have at least \(h\) citations each. Relying on citations is, in turn, susceptible to unethical citing by unrelated colleagues’ papers.

A commonly used evaluation criterion is the number of the researcher’s publications weighted by the quality of their publication venue. Some of the possible (but often flawed) proxies of the venue’s quality are:

  • its type: a journal or conference proceedings,
  • whether it is indexed in databases such as Web of Science or Scopus,
  • an impact factor for year \(Y\) of the journal (often calculated in the summer of \(Y+1\)), which is the total number of citations in year \(Y\) to the journal’s papers from years \(Y-1\) and \(Y-2\) divided by the number of journal’s papers published in \(Y-1\) and \(Y-2\) (Dong et al., 2005),
  • and its quartile in the list of journals on a given topic indexed by a given citation database, ordered by an impact factor or another metric.

11.3 Academic Career

In this final section, we outline the practical aspects of pursuing PhD studies in computer science and possible further steps.

11.3.1 PhD Studies

The main goal of PhD studies is to learn how to become a researcher and, at the same time, do real research. According to the illustrated guide to a Ph.D., it is about getting to the boundary of human knowledge and pushing until it gives way.

The typical length of a PhD program in Europe is three to four years. Specifically, in Slovakia, it is officially considered study instead of employment for many purposes, e.g., students receive a tax-exempt monthly stipend instead of a salary, but from a practical standpoint, it is an equivalent of a full-time job.

As Feamster claims in his essay Do You Need a Ph.D.?, the main point is that people do not actually need a PhD. The journey is more important than the destination; intrinsic motivation plays a central role. The main reasons why someone should decide to do a PhD and the corresponding questions are:

  • Discovery: Do I like to work on uncertain (ill‑defined) problems?
  • Expertise: Would I like to get a very deep understanding of one area and awareness about a wide range of other areas?
  • Transferable skills: Would I like to strengthen my skills such as problem structuring, critical thinking, communication, teaching and mentoring, or independent work?
  • Autonomy: Do I like to decide what to work on and how?

On the other hand, bad reasons to pursue PhD studies are:

  • Financial status: Obviously, PhD is not a way to get rich quickly. (However, if money is the only problem, it should not discourage potential applicants.)
  • Career status: Being called a “doctor” is cool but not a good main reason to do a PhD.
  • To take more classes: There are usually almost no classes.
  • As a fallback: It does not make sense to do a PhD only because someone is not ready for a real job.

Typical activities during PhD studies in computer science include reading research papers and books, discussing ideas with peers, implementing ideas and evaluating them, writing and submitting papers, traveling, presenting, teaching a few hours a week, supervising bachelor students, and writing a PhD thesis. A great activity to engage PhD students, especially in their beginnings, are reading seminars, where members of a research group read, present, and discuss a few relevant papers every week or two.

11.3.2 Further Steps

After finishing a PhD, it is possible to continue in industry or take the academic path. Possible academic career paths differ between countries and institutions. A postdoc is typically a temporary research-only position, while assistant professors tend to mix teaching and research. The two final steps are usually an associate professor and a full professor.

Exercises

  1. Which of the mentioned tips for presenting will help you the most? Or did you already know all of them?
  2. When deciding who gets a grant, a list of the investigators’ past grants has a certain weight. This seems recursive: to get a grant, you need to have already received another grant. How do you think this is solved in practice? Do you suggest any modifications of such rules?
  3. High-value grants are very competitive, and a fair selection of recipients difficult. Because some researchers have spent considerable time writing grant proposals without success, random grant allocation was even proposed (Barlösius & Philipps, 2022). Do you consider this a viable alternative? Why or why not?
  4. What alternative ways of research evaluation not mentioned in this chapter exist?
  5. Do you consider applying for PhD? What are your main reasons to apply and not to apply?