What I do as an assistant professor (Spring 2025)

This document summarizes my activity and lessons learned as an assistant professor of computer science at FI MUNI during the spring semester of 2025.

Disclaimer: This report can be interpreted in many ways. If your takeaway is “wow, this guy is working too much” or “wow, this guy is not nearly working enough”, that’s not productive feedback, keep that to yourself :) Also, don’t compare yourself to other people too much. Everybody’s situation is different. With that said, if you do actually have some constructive input on how to improve my time management, I’m all ears.

Methodology and limitations

• How I track: I am trying to accurately track what I spend my time on using toggl.com. However, I quickly discovered that starting/stopping timers for every task is an unreasonable overhead and a major distraction. Consequently, most of the tracking is done manually ex-post (usually at the end of the day) and events are tracked with ~15-minute granularity.
• What I track: I do not exclude reasonable tea/bathroom/snack breaks, but I do exclude lunch unless it overlaps with some actual meeting. Due to the reporting granularity, periods which contain a lot of small tasks typically get bundled together as a single “administrative”/“infrastructure” task. Brief but disruptive actions like “replying to an urgent email” outside of work hours are typically also not recorded (because I forget to do it).
• Tracking period: I only started tracking in late February at the beginning of the semester. To make the analysis easier for future semesters, we’ll just consider the “spring” semester to be exactly 6 months (Feb 17 - Aug 17 in this case). The “fall” semester will then be whatever time is left from August to February (i.e., each semester is ~6 months). This is a bit out of sync with the actual calendar, but since the period of active teaching is always contained within one semester, it should be mostly ok.
• How much does it cost: In a few places, I will talk about the personnel cost of certain tasks. For this, I am assuming a gross salary of 80k CZK / month. This salary accounts for the highest performance bonus at my current academic position. Under the assumption of 160 work hours per month, this gives an hourly wage of ~500 CZK / hour. However, in this arrangement, any overtime is unpaid, meaning the effective hourly wage can be smaller if tasks take significantly longer than 160 hours / month.
• Work distribution: Based on my contract, I am expected to divide my time 50/50 between research and teaching. A more realistic expectation is 40/40/20, where the last component is “administrative tasks, management, and overhead”. As such, I am also splitting my reporting roughly into these categories. Under “ideal” circumstances, one semester should correspond to 960 work hours, out of which 80 are spent on vacation (2 weeks), 32 are state holidays (4 days), 340 are spent on teaching, 340 on research, and 170 on “administrative tasks”.
• Objectivity: All of this is a subjective, anecdotal account of how I perceived the semester. While it is based on actual “data”, the summary is my own interpretation of this dataset.

“Research” questions

The low-level reasons why I’m writing this document are:

• I want to know what I spend my time on.
• I want to be able to understand the effective cost of my labor.
• I want to have a written record of my activity for comparison in the future.

The, arguably more important, high-level goals are the following:

• I want to be able to reasonably estimate the “cost” of specific deliverables, and use this information to prioritize tasks.
• I want to be able to evaluate the effectiveness of my effort and to identify/improve any obvious bottlenecks.
• I want to allow others to understand my current situation and compare their experiences with mine.

Time analysis

This semester, I only spent ~6 work days “on vacation”. However, that’s because most of my summer vacation was planned for late August and is consequently not included in this report. I am still accounting for 2 weeks of vacation in my expected productivity estimates, and we’ll just have to accept that the fall semester will be a bit less productive overall. Also, I was sick for 5 days, but it was nothing serious, so I am not really including this in the discussion.

For anyone impatient, here is first a breakdown for this semester.

Administration

Note that it is quite complicated to classify specific tasks as “administrative”. My own classification mostly assumes that a task is administrative if the output is not a useful “deliverable” in the teaching or science categories.

Teaching / faculty administration (~164h)

Administrative tasks include:

• (103h) “Emails” (see below)
• (24h) Final state exams and/or thesis defense (me as examiner or thesis advisor)
• (12.5h) Faculty-wide meeting/colloquium
• (8.5h) “Peer-to-peer” meetings; typically miscellaneous planning or consults
• (6h) Hiring committee for a new academic position
• (5h) Investigation and coordination of web development courses across study programs
• (3h) Department meetings
• (2h) Course catalogue updates

Emails: This includes reading and responding to emails and messages, as well as doing “quick tasks” triggered by a message. In particular, this includes a lot of administrative tasks related to course organization, such as creating and negotiating teaching agreements or resolving questions from students and teachers. Bottom line: strictly speaking, not all of this time is spent responding to emails, but it typically corresponds to time spent on communication and miscellaneous reporting.

Since this is a rather high number, I wanted to add context to it and I started tracking the number of emails I interact with per month (this does not cover direct messages). Overall, these numbers are shockingly consistent month to month (with a minor decrease in the summer, and a spike at the beginning of the semester). What I learned is that in a typical month, I delete 1000-1500 emails and I save or reply to 250-300 conversations.

The emails I delete are often notification emails (“you have a meeting tomorrow”, “someone blew up this continuous integration pipeline”), newsletters, and promotions. Overall, this means they are deleted pretty quickly. My expectation is that these typically need 1-5 seconds per email. The emails that I keep or respond to are typically more diverse. Some can take 30s to read and prompt no interaction, some may need 20 minutes to write a coherent reply (also, I am only counting active conversations; if the conversation contains 10 messages per month, that still counts as “one email”).

On average, this means I spend ~17h/month on “communication and reporting”. If we assume that the deleted emails require ~2 hours of work (2-3s to identify and remove each email), then we get 3-4 minutes to process each “actual” conversation. This result strikes me as quite reasonable in terms of “efficiency”, especially compared to how unproductive and inefficient these tasks feel in retrospect.

Research group administration (~76h)

These tasks mostly cover things related to infrastructure and administration within our research group. I’m not putting these in the “science” category because they do not contribute directly to papers/grants. You can view the “administrative tasks” mostly as teaching-related overhead and this category as science-related overhead.

• (16h) Maintaining lab codebase
• (14h) Lab seminar
• (11.5h) Helping to organize and run the Bioinformatics retreat
• (11h) Bioinformatics-related meetings or lunches with other group(s)
• (10h) Plenary lab meeting / social gathering
• (7.5h) Maintaining lab infrastructure
• (6h) Planning meetings for lab projects

A large portion of this time is spent maintaining existing code or infrastructure and planning future development (~30 hours). These are typically tasks where you need someone who has the knowledge of the whole codebase and/or sufficiently high privileges. Mainly, this includes tasks like reviewing pull requests in core repositories, keeping dependencies and releases up to date, installing and maintaining software running on the lab server, or adding “mission critical” and “exploratory” features that cannot be easily delegated to junior team members.

Another large group of activities are effectively social gatherings and networking events (plenary lab meetings, lab seminars, lunches/meetings with other groups, …). While the “ROI” on these in terms of raw numbers is somewhat questionable, they are necessary for fostering a good community :)

Summary

Overall, I spent 240 hours performing administrative tasks compared to 170 “planned” hours. This corresponds to 1.41x “overtime”, meaning my “effective hourly wage” for these tasks is not 500 CZK, but 350 CZK (or 56k / month).

Emails and communication are a major category here (~103h). I don’t think this part can be significantly simplified without addressing specific systemic and process bottlenecks. However, I do also expect that certain streamlining will occur over time as new tasks become routine. It is hard to estimate if this will actually lead to a reduced workload, or if the volume of work will simply grow to fill the void.

Teaching and advising

Advising and reviewing bachelor's and master's theses (~260h)

I interacted with 20 students as a thesis advisor or, in two cases, as the “main” technical consultant. Out of these 20 students, 13 defended their theses this semester and 2 seem to have abandoned their topics. I also reviewed 7 other theses (6 at FI and one at PrF). However, I also accepted ~6 new students, so for the fall semester, I expect to interact actively with 11 supervised students.

I was also the consultant for one PhD student. Ideally, I would count this as research, but our evaluation scheme considers this to be teaching, so I included it here :)

I currently don’t have enough data to estimate the true cost of being a thesis advisor, only that the differences between students are significant. Hopefully, we can get a better picture over the next few semesters.

• (200h) Consulting and reviewing the work of students submitting this semester.
• (33h) Preparing final thesis topics (4h) and official thesis assessments/reviews (29h).
• (13h) Consulting and reviewing the work of students not submitting this semester.
• (11h) Consulting with the PhD student.
• (3h) Preparation of “universal materials” about thesis writing.

Note that this activity also has an “indirect cost” in the form of state exams participation, i.e., each successful student “costs” ~0.5h in thesis defense time. Obviously, this was a significant portion of my teaching duties this semester.

Courses and teaching materials (~197h)

In the spring semester, I was involved in the organization of the following courses:

• PV247 (Modern Development of User Interfaces), ~50 students, 2 seminar groups. I am the faculty member responsible for this course, but the actual materials are prepared and taught by external contractors.
• PV256 (Introduction to Android Development), ~30 students, 1 seminar group. I am the faculty member responsible for this course, but the actual materials are prepared and taught by external contractors.
• PV260 (Software Quality), ~50 students, 2 seminar groups. I was responsible for a new seminar group created this semester, which is based on the materials originally prepared for the NetSuite/Oracle group, where I also helped to run the seminar.
• PB111 (Principles of Low-level Programming), ~20 students, 1 seminar group. I was running one seminar in this course, but I am otherwise not involved in its organization.
• PV239 (Mobile Application Development), ~60 students, 3 seminar groups. I am the main lecturer and I help with some of the seminars.

Courses PV239 and PV260 are to some extent “in a state of flux” due to some recent personnel changes. PB111 is mostly well prepared and running smoothly, save for some incomplete study materials towards the end of the semester. PV256 underwent a significant “rewrite” last year and is still settling down, but mostly runs as expected. PV247 seems to be prepared and working well at this point.

Since I don’t do any active teaching in courses PV247 and PV256, all work related to these courses is already accounted for in the “administrative tasks”. Within the remaining courses this semester, my main contributions were the following:

• [PB111] (24h) Teaching at the PB111 seminar.

• [PB111] (12.5h) Reviewing student homework assignments and preparing discussion topics for the seminar.

• [PV260] (24h) Teaching at the existing NetSuite/Oracle seminar.

• [PV260] (22h) Teaching at the new “FI-MUNI” seminar.

• [PV260] (22h) Reviewing homework assignments in my seminar group.

• [PV260] (8h) Designing a completely new seminar for both groups about performance and benchmarking.

• [PV260] (6.5h) Other material preparation and seminar tutor meetings.

• [PV260] (2h) Exam interviews.

• [PV239] (26h) Preparation of 6 completely new lectures and other minor updates to course materials.

• [PV239] (22h) Main lectures. Out of these, 12 hours are my newly prepared lectures, and 10 hours are taught by external lecturers (however, I attended all lectures to review the content for future semesters).

• [PV239] (16h) Active participation in iOS seminars and organizational help.

• [PV239] (5h) Exam organization and participation.

I also spent 7h on a retrospective and planning for the course PV252, which runs during the fall semester.

Note that for the NetSuite/Oracle seminar, I was always joined by a more senior seminar tutor. While I did actively participate in teaching, this mostly substituted the need to prepare for the subsequent FI-MUNI seminar on my own. The homework reviews for PV260 are something that could be hopefully optimized or delegated in the future. In the current setup, it results in a lot of repetitive feedback and is another source of regular distractions.

Summary

Overall, I spent 457 hours performing teaching duties compared to 340 “planned” hours. This corresponds to 1.34x “overtime”, meaning my “effective hourly wage” for these tasks is not 500 CZK, but 370 CZK (or 59k / month).

Science (~352h)

Here, task classification is also somewhat complicated, because we can split the tasks either by project or by the type of activity (meeting/discussion, writing, coding/experiments, …). First, let’s list tasks that don’t belong to any specific “project”:

• (45.5h) Writing a grant proposal. This was complicated by the fact that I was trying to submit both a “junior” and “standard” grant, so I had to do a lot of the work twice.
• (45h) Attending and presenting at the SAT/CP conference.
• (19h) I reviewed 7 papers for various journals and conferences (however, some were short papers, otherwise this would take much longer).

Now let’s list the other “project-oriented” tasks, with the caveat that some recent stuff is not published yet, so I’ll need to be a bit vague about it. Another issue is that for these tasks, I often don’t have a clear distinction between meetings and focused work, so we will again need to accept some reasonable estimates. Also note that most of the larger projects already started before this semester, so (similar to the bachelor/master students), we can’t get a complete “cost” of any project based on these numbers.

• (62.5h) “Upcoming project A”, meetings likely took only 8h.
• (29.5h) “Upcoming project B”, meetings likely took 8h.
• (22h) “Upcoming project C”, meetings likely took 13h.
• (32.5h) Managing and improving Biodivine Boolean Models, meetings likely took 12h.
• (25.5h) Finishing the trap space approximate counting paper, meetings likely took 8h.
• (19.5h) Exploratory meetings and discussions with various other research groups.
• (16h) Writing, reviewing, and consulting on the AEON 2025 tool paper, meetings likely took 4h.
• (14h) Meetings and coordination for an Erasmus research internship of one of our lab members.
• (8h) Final revision of the motif-avoidant attractors paper.
• (7h) Other “exploratory experiments”.
• (6h) Final revision of the Biobalm paper.

Summary

In this category, the planned and actual hours almost match (352 vs. 340), meaning the theoretical and effective salaries are more or less aligned. Importantly, 45h was spent on writing grants, 45h on attending conferences, and approximately 87h on various types of meetings and discussions. This means that out of 352 hours, only 175 (or ~50%) are actually spent “doing research”. The rest isn’t necessarily “overhead” (e.g., discussions are also a way to advance our projects), but I do wish this amount was slightly lower in the future.

Lessons learned

• Most of the time consulting bachelor's / master's theses is spent on reviewing writing. Students are on average fairly competent software engineers, but writing text that is readable, to the point, and well sourced seems to be quite challenging. The same goes for creating diagrams / figures or writing an actual specification that describes what a piece of software should be doing.
• There are no teams, structure, or organization. This is a fairly common observation about academic institutions, but the fact that the workload is so diverse means that over the course of the year, I have ~20 people that I intermittently manage with respect to teaching, about ~15 people associated with thesis advising or student lab projects, and ~10 actual scientific collaborators I have to keep in touch with on a regular basis. That’s an incredible amount of “context switching” compared to managing, say, 10 full-time employees.
• People can’t seem to agree on a single communication platform. Emails work the best, but ultimately most students don’t read them every day. This semester, I set up my own matrix server with bridges to Discord, Messenger, WhatsApp, Telegram, Slack, and Signal. This means I can have a single app with all the conversations in it. It only has two issues: I haven’t found a working MS Teams bridge yet, and certain platform-specific tasks are often not supported (e.g., creating a new group chat on WhatsApp, or a new Discord channel).
• If you find software that helps you significantly with some task, it is probably wise to invest in it. Currently, for both personal and professional reasons, I am paying for Kagi (search that works), 1Password (seriously, stop reading and set up a password manager if you don’t have one yet), Pop!_OS (support your local Linux distro), and Blender (I have a 3D printer, ok?). For purely professional reasons, I am paying for an Apple Developer account (you have got to sign your apps somehow), Lucidchart (a nice diagram is half the work), and Slides.com (it's online PowerPoint, but with useful code formatting and LaTeX math). Finally, I recently started paying for Cursor (I will be evaluating it for one year) and the Gemini API (some irregular task automation). I would also eventually like to pay for Proxmox and Tailscale because I use them extensively, but the free tiers are just too good right now. So far, none of this is reimbursed by my employer (and some of it is legitimately for personal use), but I should probably start figuring out ways to reimburse it :)
• On large language models:
  • Same as everyone else, I’ve been trying to use “AI” for some things, with varying degrees of success.
  • Coding: The ways an LLM introduces issues in a large codebase significantly differ from human engineers. An LLM will often effortlessly create complex, actually useful code, but at the same time, completely misunderstands “basic” issues, such as “comparing by value or by reference”. Not saying a human can’t make those mistakes, but when the LLM makes them, it usually makes them very confidently and instead of stopping to re-evaluate, the LLM “solution” is typically to add more and more code of increasing complexity that does not actually address the problem.
  • Coding: Continuing the previous point, the notion of “latest version” or any sort of “connection to reality” just isn’t there at the moment. Asking to create a continuous integration pipeline or just a sample project with non-trivial dependencies will often lead to a situation where all the versions are severely outdated/incompatible out of the box.
  • Coding: If you can, instruct LLMs to do test-driven development. Give them a task, but first require that the LLM prepares a test suite that verifies the task works once it is implemented. Only then let it generate the implementation. At that point, the agent has the input from tests passing/failing and can fine-tune the implementation. This is not bulletproof, but it helps a lot.
  • Coding: The “pro” models are actually notably better. I can’t quantify it, but using the free vs. paid tier is a night-and-day difference.
  • Code review: LLMs seem genuinely useful here. While the LLM often lacks the “general vibe” of the repository (e.g., “this is an internal tool, so…”), it often uncovers issues that are common in human-generated code. I have seen LLMs point out (a) typos that would cause subtle bugs later on; (b) rare out-of-bounds access errors; (c) complex logic issues (e.g., “this parser does not implement operator priority correctly”). I believe the actual “success rate” for the identified issues is roughly 10/40/50, where 10% are critical, 40% are good points, and 50% are misunderstandings, nitpicks, or just wrong. On the surface, that sounds rather bad, but in practice the “price” of addressing a bug grows significantly as it gets integrated into the project and released. The same way I expect people to run a linter before they send code to production / human review, I now expect people to check their code with an LLM.
  • Text review: Meanwhile, having an LLM review a paper or a thesis turns out to be a complete waste of time. So far, even with explicit instructions to be thorough, strict, etc., the LLM is comically agreeable and uncritical towards anything that is written in the document. It cannot judge if conclusions are actually based on the presented analysis/data, it cannot seem to identify sections that are useless / unrelated to the overall topic, and it always only reports “problems” that are already mentioned in the text. Overall, I tried giving it several theses that either failed, or almost failed to be defended, and the worst grade awarded by the LLM was always “B”.