Project Lab Guidelines
Read this before choosing any of my research/semester/thesis topic. This includes requirements from my side, and also what you can expect if you work with me.
Goal
In English this course is called "Project Lab." In Hungarian it is "Önálló Labor": independent lab work. The Hungarian framing is closer to what I am hoping for.
Ideally, I should be regarded as your compass, not your manager. I can point you in a direction, explain a paper you are stuck on, suggest when an approach seems unlikely to work. What I cannot do, and should not have to do in my opinion, is provide your motivation from scratch. I don't want to be your source of motivation in any sense.
Self-motivation here means arriving with a true interest in the topic before we even meet. For example: if you want to work on deepfake detection, I do not expect you to already know why detectors fail under distribution shift or why they are easy to evade. But I do expect you to know why the problem matters: legally, technically, socially. You should have formed a view before asking me to help you refine it.
Many students find this harder than it seems at first glance due to many cultural reasons. In any case, be enthusiastic! It makes the work better for both of us.
Working style
There are two main categories of working cultures. One treats a plan as a contract: deviating from it feels like failure. The other treats a plan as a starting hypothesis: useful at the outset, but subject to revision and change as results come in and the conversation evolves. I tend to belong to the second camp. For example, you can make a project plan if it helps you, but I will not require it. The reason is that I don't always know the solution to the problem I'm proposing, or whether it can be solved at all. Next steps usually depend on the results of the previous steps.
This mode of working is usually messier, and that is not tolerated by everybody. Directions change, priorities shift, which can cause some frustration for people who are less comfortable with uncertainty. I don't say either culture is better than the other, hence the existence of both. If you find it very frustrating, I am not the right advisor for you.
Topics can change
This flexibility has another benefit: if the project direction does not feel right for you but you want to work with me, we can still change the whole topic in the first few weeks of a semester.
The deadline for a topic change is the end of the first month of the semester under my supervision. The goal is for you to work on something you find interesting. Do not stay on a topic just because you think it is what I want.
Problem solving: KISS
Keep It Simple and Stupid. This is a design philosophy and, in practice, the most reliable way to make progress without losing motivation. Begin with the most stripped-down version of your idea that still does something meaningful. This is the quick and dirty solution driven by desire rather than rational, careful thinking. Get that working and understand it completely. Then, and only then, add the next layer of complexity.
Use AI, but own what it produces
You are encouraged to use AI tools for coding, writing, and exploration. That's the present and the future. But using AI without understanding its output can be a trap.
If you show up to a meeting with code you generated an hour before and cannot explain what it does, that is a problem. The first time I notice this, you will not need to come to the next meeting; it is a clear signal that the project does not matter enough to you. University should be about learning and understanding, not about results in the first place. When you use a generated snippet, make sure you can answer: What does this do? Why does it work? What happens if the input changes?
Meeting notes are your responsibility
After each meeting, you have to write a short set of notes and share them in our common folder as a single Markdown file, named by date if you like, or just kept as a running log.
The things I need are (1) the current status of the project including project goals, assumptions, and main techniques (this only needs to be written once at the very beginning, but updated continuously as the project evolves), (2) what you have done since the last meeting (how you progressed with the last TODOs) and (3) a list of the next steps we agreed on. I supervise multiple students and will not reliably remember what we decided unless it is written down.
Keep it brief, a few bullet points is enough. The point is alignment, not documentation for its own sake. For that, you will have the report at the end of the project.
I do not debug your code
I have debugged enough code in my life. During the meeting, I usually focus on concepts rather than code.
More importantly: you will not learn anything without struggling through it yourself. The time you spend confused, trying things that do not work, and eventually figuring out why, is the most precious. You will not appreciate this struggle while it is happening, but you will later.
AI makes this easier than it used to be, and you should use it. But "easier" does not mean "free." You still need to understand the output and be able to explain it. The debugging skill that matters now is knowing how to work with AI tools effectively, and that still requires you to engage, not just accept whatever is generated.
I ask a lot of questions
Asking questions is how I engage, and it is also how I learn. That said, questions become uncomfortable when you come unprepared with code you cannot explain, with nothing new to show, or with a vague sense that things are "going okay." Expect to be asked why, what happens if, what did you try, and what is the meaning of the formula (you) implemented. Have answers ready, or be honest about what you do not yet know.
Communication and meetings
- You can write me any time when you get stuck with your project. I reply as soon as I can.
- I expect weekly meetings; tolerable cancellations include midterms, sick leave, and occasional personal issues. We can have meetings online if that fits better for either of us.
- If you have not made progress on your project by the end of the day before a meeting (EOB), please cancel it on time. I will also try to respect you by not canceling a few hours before; I expect the same from you.
- Don't use AI to write me messages or emails; I won't either. Typos and stylistic problems are part of being human and will not affect your final grade.
- I'm not a professor, and my first name is Gergely [ˈɡɛrɡɛj] (Gregory in English).
Grading
I evaluate your (1) midterm work, (2) final written report, and (3) final presentation talk given during the supplementary week together. I will send you a short written evaluation at the end of that week. You can find some guidelines how to give a talk or how to write your report.
I grade effort, not results. Negative results are also results! If you put serious work into a direction that ultimately did not work out, that is fine. What is not fine is having results built on shallow understanding. Make sure I can see the work behind what you show me during meetings, in your report, and in your final talk.
Changing advisor is always an option
At the end of any semester, you are free to move to a different advisor. No explanation is required, no hard feelings will follow. You are not obliged to continue any project. If the collaboration is not working - either because the topic does not fit, or the working style is wrong for you, or you simply want a new experience - that are all legitimate reasons to change.