Comments from some user interviews

[rkdarst]

A ux/service designer working for our IT services is doing interviews with our users to see what they think about our services. Some of the feedback is useful to HoSC:

• Some people didn't look at our training because they think it's too low level, bachelors/masters level. Thus: emphasize this is for transitioning to productive researcher whatever level you are at
• Some people say they want to learn themselves because of their curiosity. Thus: emphasize that our material doesn't solve problems, it gives background needed to solve it yourself.
• Having a certificate, or something to show beyond the knowledge, would motivate some researchers. Not necessarily credits since not everyone needs it, but perhaps certificate or some such. With enough marketing it could be useful both inside the university (becoming a research assistant) and to companies.
• We have training modules, but but the problems of the researchers are very specific - workshops too big. "Problems are too unpredictable" - why learn about other problems? And the goals are not that big.
• Some people wanted to know how to manage their files/data, but didn't get training in that before their proposals. (My suggestion: two modules, one on the flie and storage level, one on the management/opening level. Two modules can be one CR lesson). (Related: no one ever checks up on this)

Notes for me mainly:

• Advertisements about our training are not spread out well enough. To do: advertise on student mailing lists for our major trainings.
• Many interviewees say that they rarely contact the central services, they first ask their friends and then department support.
• Users want more availability of supporters.
• Better interfaces for scicomp/wikis. Easier to find data than long lists.

[bast]

Very interesting findings which I think are transferable also to our center.

[rkdarst]

Equality. It's something we all care about, but promoting it beyond surface gestures is so abstract. In the end, our whole goal with HoSC, proper support staff, research software engineers, and so on is to promote equality. As one of our recent links said, computing is like an apprenticeship more than an academic study. That means if you have the right friends when you are young, you get good. If you don't, all your work suffers later, both computing and science that uses computing. This is what I've learned from my own user interviews and know from my own experience. HoSC, research software engineers, and our related work needs to be done not just to improve research skills, but for equality of researchers.

Above is something I started thinking a year or so ago as I was asking people about our training courses, and someone pointed out the vast differences in students and incoming researchers. I think that we could form an entire marketing strategy to administrators based on that, since most people deciding on "research support" are a bit too far away to realize what is helpful. But everyone wants to support equality.

Thoughts?

[rkdarst]

Comment from new professor: the automation of workflows and tasks is something that I've heard people have problems with.

Comment from summer researcher (in data sci) whose undergraduate degree is in computer science: programming, etc was useful and not that hard, but knowing how to arrange files and set up the pipeline isn't trivial. But not being good at the programming and not knowing how to set things up is really hard.

Junior researcher: knowing a little about hardware is important once you get to mid-level programming. How to make things modular and avoiding copy and paste. shell scripting.

[rkdarst]

Interview with recently graduated data scientist/current bioinformation (really great info here!):

• Matlab has one IDE, Python has many. Hard to know which one to start with (the answer was spyder)
• How to install Python packages. Many ways, always copied stuff from websites and hoped it worked
• Tried to learn version control several times, always ended up being too complex. So I've always skipped it and still don't use it. Also I only work for myself
• If there was someone downstairs to talk to, that would be more approachable than CSC. We don't have our own cluster.
• How to share code. How to manage projects. I've always worked alone so far.
• I had a programming background, but not matlab. Learning matlab not too bad, but the doing projects part was a completely new thing.
• Already knew about moduler code and functions and that helped me. But in order to use module code, you have to know debugging! Two main ways: how to debug line by line and how to change variables while in the debugging.
• It's important to learn how to google things, what terms to use, what concepts, etc.
• If you have many scripts that need to be called in a certain order, how do people manage that? Managing these is another prerequisite for modular code.

[rkdarst]

For anyone who wants to do their own interviews and contribute here

The interview is not very structured and there is not much, but I roughly:

• First ask "what do you wish you had know when you started as a researcher"
• Usually answers are very broad, so I explain that the context is tools of scientific computing, and see if their answers get more specific
• Depending on if they get it yet, I'll show them https://handsonscicomp.readthedocs.io and see what they think. By now they usually get the type of work we are trying to improve (because they know me) and have plenty of ideas.
• Where did you learn these skills? How?
• What kept you from learning more?
• What kind of teaching would have helped you back then?
• What can make our outline useful?

Does anyone know a better way to do this? I would be happy if other people could interview users and post their feedback.

[bast]

Thanks for sharing this. I plan to ask these questions at http://hpc.uit.no/en/latest/help/hpc-cafe.html.

[rkdarst]

Student who just graduated with a masters in bioinformatics, previously another computational masters:

• Learning not to program everything yourself, because a lot of stuff already exists. (Includes being too excited about doing it yourself). How to find these existing libraries.
• Carrying on from above... how/when to use others' code. Not being ashamed to do so.
• How to write codes in a reusable manner, otherwise when I come back I can't use them again.
• How to store my codes so I can find them later. How to document them, where to put them. When I'm under stress I don't think about these things
• I've learned from trial and error, I haven't tried searching online myself yet.
• How to teach, as soon as possible. Even in high school where they are teaching programming now.
  • [interviewer note: this seems related to academic vs hands distinction, these are the kind of skills you don't learn in carefully orchestrated classes that set everything up for you]
• An online course would be best, because I never have time to go to an in-person course, there is always something overlapping. Or maybe try courses in the summer when there is less possibility for overlap.
• Bachelors students from our university are very good at programming, so I am already behind them.

[rkdarst]

Senior professor, hasn't been coding in a while but did long ago:

• 5 years back at my technical university (physics students), the students had some introductory courses on computer systems and so on. But these courses had no practical element. When they started doing their actual physics problems, the students had to learn from each other, also partly because they were more advanced than the teachers (because the tools change so fast!).
• Then they had physics courses
• What I think they should have is a course to teach them how to develop a code for how to solve a physics problem in the environment we have now. After a few classes they could learn all kinds of tricks, like how to find an appropriate library, use github, and so on.
• They have no practice on visualization... physics students are often behind in this topics. Doing it and selling results. They learn it from each other... or not.

[rkdarst]

University lecturer of applied math:

• Know that there is so much stuff available. In the old days, there was the assumption that whatever you need has to be made yourself (or is written in fortran and using it is complicated). Now it's more about knowing what the right tools to use are.
• Prototype in high-level language, when you need to be fast you can implement in another. This saves a lot of time overall: prototype and production environments.

[rkdarst]

Assistant professor of computational social science/network science

• being exploratory is OK, but you often start using the same code for multilpe papers this is important
• it's OK to use just the most basic features of each complicated tool. That may be more appropriate. These tools are designed for massive projects so you have to balance things properly.
• jupyter noteboks useful, you can start really quickly and it is like a report already. nbviewer, binder, etc. It's a bit antiquated to think that the only output ofa project is the paper.
• Leaders need to say "you are not done when the paper comes out, it is done when there is the notebook, code in git, (bad) website that shows basic results.
• Most of these tools are really difficult to use but they aren't really
• It's good when these are provided as university services so that you can immediately use them.
• Younger people use these tools already more compared to five years ago.

Recently-gradutaed PhD student of math/computer science

• testing is important, it can be emphasized more. Often have code, get new idea, old stuff breaks. It's also important even for small things. To make code testable, need to be able to make small examples with known results. Testing is a good example of the balance above.

[rkdarst]

PhD in computational science, now working for a bioinformatics project at a hospital:

• I would have taken some classes to properly learn how to code, instead of figuring it out myself.
• Do more small projects where you mainly learn new things and end up with some git repo. This can be used to practice, learn support skills which may not be immediately needed. And you have something concrete that you can show when applying for jobs to show that you can accomplish something (instead of only having papers as your output). You can ask your supervisor for ideas, and this is better than jumping directly into a giant long-term project.