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 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 “spring” semester to be
exactly 6 months (Feb17-Aug17 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 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
nothing serious, so I am not really including this in the
discussion.
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 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 reduced workload, or if the volume of work will
simply grow to fill the void.
Teaching and advising
Advising
and reviewing bachelor and master theses (~260h)
I interacted with 20 students as thesis advisor or, in two cases, as
the “main” technical consultant. Out of these 20 students, 13 defended
their thesis 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 “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 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 the state of flux” due
to some recent personnel changes. PB111 is mostly well prepared and
running smoothly, safe 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 lectures
(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 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 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, 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 / master 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 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 am “intermittently managing” with respect to teaching,
about ~15 people associated to thesis advising or student lab projects,
and ~10 actual scientific collaborators I have to keep in touch with on
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
setup a password manager if you don’t have one yet), popOS (support your local linux
distro) and blender (I have a 3D
printer, ok?). For purely professional reasons, I am paying for apple developer account (you
have got to sign your apps somehow), lucidchart
(a nice diagram is half the work), and slides.com (its 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 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 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, 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”.