top of page

Welcome to the lab!

There are a few things you’ll need in order to get started; the lab manager should be able to help you with these. It’s best if you contact them some time in advance so everything is ready by the time you start. Particularly, they’ll need to know whether you plan to work on a PC in the lab or your own laptop, to make sure we have enough computers.

  1. The lab manager will add you to the HR system as a member of the lab (if you are on a student position, they will explain how you report the hours you work).

  2. They will add you to relevant mailing lists (of all ELSC students/postdocs and all ELSC).

  3. You’ll need a chip to enter the lab (which you should remember to return when you finish the position)

  4. People in the lab work on PCs and connect to the lab linux for more computational work. To connect to the linux, a user must be opened (check the how-to section on how to connect to the linux). This will also create a home for you on the lab storage and give you access to the lab’s shared directories. It is best to do this as soon as possible, so you have access to the lab storage and linux straight away.

  5. Send the lab manager your picture, so they can add you to the lab website.

  6. Join the lab slack and Zotero (first join slack and Zotero in general, then send Aya the email you used to join and to ask to be added to the lab slack workspace and lab zotero).

  7. In terms of seating – feel free to pick any place you’d like that is currently vacant. But bear in mind postdocs and PhD students have priority, followed by MSc students. This means if someone joins the lab, you may have to move to a different room. The main rooms are the two connected rooms by the windows and the aquarium (behind the big screen). Other rooms can be used when needed, but they are considered multifunctional rooms and may be needed for other purposes, so do not plan on working there long-term.

  8. There’s a lab whatsapp group – ask the lab manager to add you to it.

  9. Whenever possible, all the data related to the lab should be saved in the lab storage. Initially usually in your home directory and when a project/stimulus set is complete, it should be transferred to shared directory.

  10. You can find useful resources to help you get started on the lab website (abymemlab.om). Ask the lab manager for the password for the internal section.

  11. Contact for help: For admin issues please contact the lab manager (abymemlab@gmail.com) and for IT issues please contact the IT team (elscit@mail.huji.ac.il).

Leaving the lab

  1. We’re sorry to see you go!

  2. There are a few things that we ask you to take care of before you leave:

  3. Well in advance, start organizing the data you have in your personal directory. Move everything relevant to the appropriate directories in Lab-Shared, along with detailed READMEs, and delete any files that won’t be needed. When you leave, your home directory should be empty. When organizing the data – give your project a name and within each relevant directory (project documentation, analysis code, etc.) create a sub-directory with the project name and your initials appended at the end. Your full name (and, if possible, a non-huji email) should be in the README so we know who to contact if needed.

  4. Leave the lab Slack and Zotero (ask Aya about this).

  5. If you have an adobe license in your name – transfer it to someone else in the lab (ask the lab manager about this)

  6. Return the chip to the administration

  7. Ask the lab manager to remove you from the lab on the HR system (this may require signing some forms)

  8. If you are on the ERC budget, make sure you have properly filled all the ERC timesheets (if you are unsure how to verify you have done this, check with the lab manager).

Joining the lab

Joining the lab

Meetings and communication

  1. Meeting frequency: As a thumb rule, there will be weekly meetings with PhD students, biweekly meetings (once every two weeks) with MSc students. For BSc students – schedule a meeting whenever you reach a point in the project where you would like guidance on how to proceed / have results to share. For postdocs – when you arrive, we will jointly decide on the format that works best. This is a thumb rule but can be adapted depending on the stage of the project, how busy your current schedule is, etc. In addition – schedule ad hoc meetings whenever needed.

  2. Meeting summaries: Please keep a meeting summary file we can both access, and add a summary after each meeting, including decisions we reached regarding the project (and the rationale) and the action points until the next meeting. Your future self will thank you.

  3. How to schedule meetings: You have access to my calendar where you can see when I am free. You can send an invite for a meeting in free slots. I prefer, when possible, to hold meetings after lunch, 12:30-16:00. There is no need to email me in advance to ask if it’s ok to schedule a meeting, it’s always ok. In the meeting invite please add your name to the title. If you need to cancel a meeting, please let me know sufficiently in advance when possible.

  4. Popping in: If you have something you’d like to discuss before the next meeting, feel free to pop in when the door is open. But it’s best to only come by when you have something you’d like to discuss (for example, there’s no need to pop in to ask whether it’s ok to schedule a meeting – just send me a meeting invite). When coming in for an impromptu meeting, please give me a moment to close any windows that could potentially include lab members’ personal information before coming up to the screen. If the door is closed, it’s likely that I’m busy, but you can still knock to check whether I’m available. But please do not knock and immediately open then door without

  5. Contacting me: The default preferred method of communication is email, especially for figures/results. It is fine to call/whatsapp when there is something urgent (or to share results we’ve been waiting for!), but regular communication should be over email.

  6. Emails: When you are replying to an email sent to a group of people, please make sure to reply all when relevant. If you email me and I don’t respond within a couple of days it is fine (and even desirable) to send a reminder.

  7. Slack: The lab is aiming to use slack more. For messages, especially to a group from the lab with shared interests, it’s best to use slack. Same for sharing papers and conferences you encounter. For documents that we may need in the long term (and in general for things we may want to search for in the future), it’s better to use email.

Meetings and communication

Expectations

The working hours are quite flexible, but I do expect lab members to work in the lab during core hours (10-15), so that there will be overlap between people. Nothing beats turning to the person sitting next to you when you need advice. Working remotely should be limited to at most once a week, but let me know if you have specific circumstances that require working remotely a larger proportion of the time. The number of weekly hours can naturally vary from week to week, especially for students taking courses. This is fine, but please aim on average for the number of pre-agreed weekly hours. Students for advanced degrees and postdoctoral fellows are expected to devote full time to the lab (aside from courses), unless there are special circumstances which do not allow you to do so, in which case please reach out to me to let me know.

Manuscripts and seminar papers

  1. Documents you send to me will often come back with a lot of comments and/or red. This is doesn’t mean I think what you wrote isn’t good, it is just part of the process to improve the text (especially for manuscripts) as much as possible. If I went over an old text of mine, I’d also have a lot of comments (you may even see I contradict myself between one round and another).

  2. If you disagree with any comments I have, tell me so. You don’t have to automatically accept any suggestions for changes I make.

  3. Please keep documents in track changes, up to a point. If you make changes based on comments I had, leave it in track changes. But if after another round we’ve decided to keep them, first accept previous changes you made and then leave the document only with the most recent changes. It makes it much easier to work on.

  4. BSc students – if you send a seminar paper, please send it as a word document, not a pdf. It is much easier to comment that way.

  5. Try to make the text as simple and easy to read as possible. Our goal is to make it easy for people to understand, not to sound smart. I often fall into this too and write text that is too complex. It can also cause us to write things that are just incorrect:
    For the love of all that is holy, stop writing “utilize” | Scientist Sees Squirrel

  6. After much too much time wasted on formatting papers according to journal guidelines, I learned that most journals are fine with first submissions that don’t match the guidelines. Keep the general structure, but don’t try to adhere to things like text limits, this can be fixed later. It is also best to always put the figures in their correct location in the submitted pdf, rather than putting them at the end (even if those are the journal guidelines) – it’s much easier for reviewers to read that way.

  7. Good practice for drafts is to add the dates of different versions in the format YYMMDD (this way it’s automatically ordered by date). In the end, save a version called final, with no comments/track changes, making it easy to find the final version.

  8. Before submitting, always use GPT (or your AI of choice) to spot typos, grammatical errors, things you may have omitted (like means, standard deviations etc.), and just give the paper one last look. Reviewers are much less forgiving in the past when people submit with typos and grammatical errors, since GPT does a great job of finding them.

  9. Figures:

  10. Put in the extra effort to make figures look aesthetic. Especially for PhD students, it is worth investing the time in learning to use illustrator (or at least use photoshop).

  11. It is usually best to add the text as additional layers rather than use the text you get from python/matlab, since it can be easily changed if you find your font size is too large/small in the final figure.

  12. Suggestions for color palettes: https://www.simplifiedsciencepublishing.com/resources/best-color-palettes-for-scientific-figures-and-data-visualizations

Expectations
Manuscripts and seminar papers

Open science and reproducibility

A core value of the lab is to conduct open and reproducible science. It is helpful to have this principle guide you from the very start of the project, as it will help you keep things organized and documented in a way that will support later sharing of the materials both within and outside the lab. A general rule of thumb is to conduct research as though someone (potentially you) is going to try and replicate your findings. Before publishing something, you want to be reasonably confident that they have a good chance of replicating the results.

  1. When writing code: Comment, comment and then comment some more. Others you share your code with, as well as your future self, will thank you. Aim for code that is modular and easily understandable for people who are unfamiliar with the project. I find that it is helpful to have the bulk of the code in python modules which are called by a top level heavily-documented jupyter notebook. The jupyter notebook can be used by someone who isn’t interested in the small details to replicate all the results of the paper. You can see an example in https://github.com/ayaby/stopmotion

  2. Organizing stimuli and data: Decide in advance how to organize the stimuli and data (in terms of directories and filenames) in a way that will facilitate sharing. Behavioral data should also be anonymized (replacing prolific IDs with a project-specific participant ID) before uploading to a data sharing platform. It is best practice to anonymize the data as a first step and then write the analysis code such that it runs on the anonymized data.

  3. Preregistration: All studies in the lab (aside from a few exceptions) are either preregistered or submitted as registered reports (see the lab resources page for more details).

  4. Data and code sharing: All code should be uploaded as a separate repository in the lab github, along with a detailed readme and the recipe for the environment you used for the project. If you use the fMRI pipeline, make sure you link to the specific version of the files you used for analysis. Behavioral data is shared on OSF and neuroimaging data on openneuro. Currently our ethics approval does not allow sharing of intracranial data.
    To facilitate code sharing within the lab – make sure you update the general code as soon as you’ve checked any changes you’ve made to it. Try and keep the code backwards compatible, and in any case update all other users when you’ve committed a change. It is best practice in general (and especially for shared code) to use version control – git can be used in any local directory, not only with github.

  5. Sharing information: When you find an interesting paper, hear of an interesting conference, find a useful resource or write yourself a howto file on something – think who may also benefit. Papers and conferences can be shared on the relevant slack channels, and papers should also be uploaded to the lab Zotero. Add them to the relevant directory there, and if there is none – create a new one. Useful resources can be added to the lab resources page (ask the lab manager to do this) and howto files can be added to the website and/or the documentation directory on the lab storage.

Open science and reproducibility

Wellbeing

Science can be very rewarding but also very challenging. When you feel you’re stuck, especially those points when you’re in a loop inside your mind, try to reach out. It often helps to talk to someone who can remind you how common it is. Ideally, reach out to me, and if not – reach out to a colleague. There are also online resources that can be helpful, such as:

  1. A TED-X talk by Uri Alon about getting lost in “the cloud”:
    https://www.youtube.com/watch?v=F1U26PLiXjM

  2. Phdcomics (has some very accurate comics!):
    https://phdcomics.com/

  3. Resources about imposter syndrome, here is one example:
    https://www.psychologytoday.com/us/blog/neuroscience-in-everyday-life/202308/overcoming-imposter-syndrome-6-evidence-based-strategies

  4. Enneagram:
    https://www.enneagraminstitute.com/type-descriptions/
    This is a division of people into nine personality types. I wouldn’t treat this as an exact science, but it can be helpful to read about the different types and see which of them you identify with (can be more than one). In research it is especially important to identify what it is that drives us and motivates us. This can differ between people and understanding what drives you can sometimes help understand how to get through the rough patches. One doesn’t necessarily need enneagram types for this, it just organizes different motivators in a nice way.

  5. If you feel something isn’t working (in the project, in how we work together, with a co-worker, in the lab) - my door is always open. I may not always be able to solve or change the issues you raise, but will do my best to try. And sometimes just discussing them is important.

  6. There may be times where you work less than usual due to illness, personal issues or any other reason. This is fine, science is not a 9-17 job, and typically there will be other periods of time when you find yourself working extra hours. But if you see this goes on for a while, talk to me and we can think of ways to improve matters.

Wellbeing

Working environment

Our aim is to have a fun, collegial working environment. A few things that can contribute to this:

  1. Suggesting ideas you have for things to improve or organizing lab events is always welcome.

  2. Remember that people may come from different backgrounds, religions, political views and countries. Especially in the current climate, people may feel ostracized if they have different political views. We should all do our best to make the lab a place where everyone feels welcome. Do your best to avoid saying things that may be offensive to someone else, and come to me if you feel someone has been offensive to you. It is fine to express opinions, hold different political views, argue – but we should aim to never makes someone feel less worthy because of it.

  3. Lab members from different countries – living in a different country, with a different culture, can be challenging. A prime example is that Israelis (including myself) tend to be more direct than people in other countries, or add less pleasantries to emails, and this can come off as insulting at times. If you feel the styles of myself or others in the lab is too direct, please let me know and together we can think how to make you feel more comfortable.

  4. Try to make sure people take part equally in organizing events, buying going-away gifts, and other non-science-related tasks. Some people may be happy taking on more than others, in which case it is fine, but it is important not to leave these things to the same people who always volunteer out of team spirit and would rather have them divided more equally.

  5. If you’re calling participants for an experiment, try to do so in a separate room with a closed door. If you’ve given them the lab phone as the contact number and you’re expecting numerous calls, make sure to answer the lab phone.

  6. Please avoid coming in when you’re sick. If you are mildly sick and do come in – please let people in the same office know, as well as people you have meetings with so they can decide whether to postpone.

Working environment
bottom of page