 What's next? Yeah. Next we have Radovan Bast with a talk called When and How to Ask for Help. So, yeah. Radovan is a, what's research engineer? Is that your title? At the University of Tromso. Yes, and so nice to see you all. I'm joining here. The kickstart from Northern Norway. The sun came out five minutes ago. It's a beautiful day. And I will take over the screen. Share my slides. You can find the slides also in Indian HackMD. You can also find them on the website. And in the next 25 minutes, I will be watching HackMD for your questions. So please keep them coming. And I will talk about asking for help and answering questions or answering help with supercomputers, but not only with supercomputers, also with computers, with computing, with programming. Yeah. Okay. Don't wait, don't wait for the end task. So I know you're rather packed here, but as a starting point, would you rather more people ask for help or less people to ask for help? More people to ask for help and wait less or with asking for help. So let's ask more for help. Okay. And I understand your presentation will talk about how to ask for help in the most useful way to get the best answer fastest. But I'll also talk about the other side also, like how can we actually answer and encourage more questions. And I'm really passionate about this topic, but I'm also joining this kickstart from Norway because I really, really like to hang out with my colleagues from Aalto and CSC. It's every time a lot of fun. Yeah. So I want to hear the outline is that to list some of the, like where we can ask for help, what kinds of help is available for different levels of work, when, and the short answer here, well, sooner, always. And there will be a bit of focus on support requests so that you get quick and useful answers. And depending on how the time goes, I might also discuss how to create reproducible examples, how to grow calculations. I may not have time, but then you find this in the slides. And really the goal is to improve our experience when solving issues. And I think we should also create some guides for staff on how to answer questions and provide training for how to answer to support requests. And there is a lot of recruitment needed. So super briefly about me. I collaborate with with colleagues in Aalto and CSC through the Code Refinery Project. We have been collaborating in a couple of contexts. I started doing programming and computing during my PhD, 2004. And I've been on both sides. So I've been, I've been on the side of asking for help. I've been on the side of answering these questions. And I'm part of, I'm working in Norway within a center for high-performance computing. And many good suggestions came into these slides. So here they are listed. So thanks, thanks for these. And there you also find some more resources. So maybe let's first talk about where to ask for help. And here I listed some places where I could ask a question if I have a question about computing or programming. So I could ask my colleagues in the hallway or in a Zoom call. There is the Aalto Scientific Computing Garage. In Norway we have Q&A sessions. It's the same idea. So people can pop in and talk about their ideas or issues. There is the search engine. There are different chats. I will have some, I will focus a bit on issue trackers. Where you send an email and it opens up a ticket. I guess the main point there is that it's asynchronous somehow, like you send and yeah. Good point. So there's asynchronous. There are also resources for my engineers around you and among you. And they are good to ask for problems that is with the code you are writing or want to write or want to rewrite. And there are mailing lists and fora and stuck exchange. And more, I try to sort them a little bit also in terms of, I don't know, scariness. I think I would first start asking questions here before I would write a question on stuck exchange and many people would. And I think the one reason is that the places here on the bottom, they create kind of a permanent record of a question which can be scary, but it can also be very useful because then other people having the same question, they can find my question and they can find the answer. Yeah, like in Alto, we try to make sure that make as many questions be asked in public as possible, like internal, not public public. So that way people can learn from each other. But yeah, that's the big advantage of these, these down here because the other ones can be a little bit one-to-one. And there can be also different levels. So I can be asking for an advice. Should I do A or should I do B? I can also maybe be asking for actually having something done for me. Please can you install this? Can you help me with scaling? Can you help me programming or reprogramming? So there are different levels. Yeah, okay. Okay. I think before, before I focus here a little bit on more on the issue tracker, because I think this is the place where we very often interact with, with cluster support. I want to remind us, I think it's good to be reminded that who is on the other side of the question or the other side of the answer and there is a human being. I think it's good not to forget about it. And I have to remind myself from time to time that when I'm answering questions on behalf of the cluster support, it's good to remember that it is not easy to ask for help. The person asking for help has maybe 20 years less experience with, I don't know, Linux or command line or the Fortran or Python. Also the person on the other side has perhaps spent weeks already on this problem and is frustrated and is waiting for my answer. So I have to be really respectful. I think it's good to remind myself about it. For those asking through a ticketing system, and I should maybe also clarify what it is and I will, is that it's good to know that when you ask a question, it may not be always the same person on the other side. There might be a rotation system that this week it's, I don't know, and we go on and the week after it's Richard and the week after it's somebody else. And when I get, when people ask questions through the support line, I don't know everything. So I'm also often searching for the answer. And I'm sometimes spending less time on a supercomputer than the person asking. Also, I often don't know the person who is asking me the question. And I might not have the context. I will come back to these points. I actually remember the first technical question that I asked and the answer that is 2004 or five that was before Git and GitHub, I think they didn't exist. So I wrote a very long email, a novel paragraphs and paragraphs motivating to a researcher. I was asking, I wanted to have access to a code. And I wrote these paragraphs and paragraphs and motivated them. I was praising their work and motivating how I would use it and very polite and respectful. And after a few days later, I got all this answer that I think the person was really confused what did I really want because it wasn't very clear. And the answer was, well, I guess what I meant among all these paragraphs was, can I get please access to the code X and here it is. And this is, there's nothing wrong about this answer. So I don't show it because it's impolite. And I think this is perfectly fine. But I felt, I felt like, okay, I didn't find the right tone of asking. I was happy I got the code, everything was fine. But it made an impact on me. And 20 years later, I still remember it. So what I want to say here is that when the answer helps, it matters. It can make an impact on the person. And there's something like I've noticed, like there's a balance between being long and trying to be very polite and being short and getting the answer as quickly as possible. And I think sometimes maybe I'm too on the side of being long and polite. Yeah. Yes. So I spent half a day writing the email. And I think the other person spent half a day thinking about what does the, what do I really want? And also today, when I get such a long email at some place, I've got another novel. But good to remember, like there is another person there and they really care. Yeah. Yeah. So I wanted to say something about the ticketing system issue tracker. This is my understanding is that this is how it is work, how it works at auto scientific computing. This is, this is, this is how it works in Norway and also in Sweden where I used to work is that you send an email and a couple of hours later or minutes or days, somebody will answer and solve the problem. But what happens really is that the email opens up an issue or a ticket and the ticket gets a number. And I mean, in Norway, we get 10 to 13 new requests every day. And I don't know how much is, how much it is at auto. But each ticket is then filed under a number. Each ticket is an owner. And that's typically the person writing back to you. But it's good to know that the owners can change if it takes very long to resolve. Or maybe the person answering doesn't have the solution but needs to involve other people in solving it. And the first thing that the other person sees is the email subject. That's why it's really, really useful if the subject is descriptive. So this is a better subject than this one problem. Because if I see a subject email with the subject problem, I have to open it up. I have to read everything to find out what it is about. Here I get a little bit of a better idea. And if you include keywords like a software with software use or the research field, it's maybe even easier to root the request to the right person without reading everything. And if you have two issues on the same cluster or two issues that you would like to get help with, but they are unrelated, it's better to send two separate emails. So not to package them into the one, into the same email, because the person answering may be able to solve one but not the other. So it can speed things up if you send two emails instead of one. And it goes also the other way. I mean, if you talk about the same problem, then it's better to actually reply to the email and stay on the thread and not open up a new email which will open a completely new ticket, a new issue. So if we talk about the same thing, it's good if we stay in the same email. Yeah. Like if it's not linked or whatever, that can take a lot longer to deal with. Yeah, like the subject, like if I get a message and the subject seems vague, then I'll think, okay, I have no idea what to do. And it's like more resistant to looking at it. But if it's clear, like my Python job is crashing, or my Python job has import error, then suddenly it's much more clear. Yes. So that already helps a lot. And thanks also for the comments on the PMD. I'm watching them. Yeah. So it's good to provide context username if you are on a cluster with many, many users, because the person answering, they can find out who you are, but it takes a few minutes and it's not the most exciting work. So it helps already if I write my username. Explicit path is better than implicit path. Like this is in my home, but then the person needs to find out where is my home? Well, it's here. So this is helpful. Which machine it is? In our way, we have several clusters. So what cluster is this about? Which software is this about? Which research field? Also, if you use any customized environment, then you can mention it because this can make it easier to reproduce the problem. And sometimes text is better than a screenshot because I can maybe copy-paste out of a text, but also screenshot is better than nothing. Or you can send an attachment. Here's my input script. And here's the problem output. Yeah, I think this is probably one of the most important things here. So getting an issue without the context needed to know what's actually going on, there's almost nothing to do. And then it takes time making a long, nice sounding thing saying, please let us know where you are and what you're trying to run. Which I think Radhavi will mention shortly. And I may not be able to solve the problem and I may need to involve a colleague of mine. And then it's nice if there is some context already. So the colleague can read up on the context. So that helps a lot. Here are some tips on how to formulate a question that already it will again avoid a lot of back and forth. So has it never worked or has it ever worked? So has this worked last week, but has it stopped yesterday or has it never worked? I mean, this is already useful to know. Also, what are you trying to accomplish? So not just this current technical obstacle, but even to go to and I will come back to this. What did you try? What do you do? And try to be specific enough to be reproducible. So copy paste the exact commands you run, the exact output messages so that I can try to get the same problem because then it will be easier for me to work on it. Also, what do you need? Do you need a complete solution? Or do you just need like a advice pointer on how to get started? That can also help us to help. And now coming back to the question, so when to ask for help. That was the first question that also Richard asked me. So don't hesitate to ask for help and in doubt ask. Nevertheless, if I'm on the answering side, I do appreciate if I see that you spent more than two minutes on the problem before asking. So spend two minutes, but don't spend hours. I guess that means like if you say, oh, I found these pages, but it didn't work. That's appreciated. And again, let's also change the role, those helping. Don't forget that the person asking may not know yet how to look for solutions before asking. So help them showing how. Also, instead of just sending a link to a documentation, which can maybe feel a little bit rude or a checklist, which can also sound a bit annoyed. It's nice to package it into a empathy sandwich. So start with empathy and work together through the checklist. Show them what you have tried and what you have found so that we really solve it together. We are not, we are not around in this. And I think this like when to ask for help relates to the last question or last question of what to include. So like, are you just starting? So are you saying, okay, like I'm trying to do X, I can keep looking more, but do you know a quick solution? If you don't know something, then let me know and I'll try for another week and then ask for more help. So for example, I think some of this context is often missing and that means people want to wait too long or the people answering get annoyed that they're being asked too soon. So like. Tell us also what you have tried. What do you have tried to isolate or simplify the problem? Also check the documentation in the web, but again, do not hesitate to ask. Nevertheless, the documentation could be outdated. The XY problem is something that happens often is that I want to do something X and I think I do some searching and I have some reading and I think that this is a good way to solve my problem. But then I struggle with this and I hit a problem and then I write to the support and then then there is a lot of back and forth and three weeks later, 30 emails later, we realized that my approach to solve the problem that I have was not the best approach, but nobody knew because I never told anybody, but I really had in mind. So it's really useful to communicate in my request. Also, where do I want to get to? Because there may be a much better way than what I'm trying to solve right now. This goes also the other round. The other way round is that we as support staff, it's good if we try to read a little bit between the lines and not only try to close the tickets and close the issues as fast as possible, but try to go deeper if we have a feeling that there is something different that can be done, which might be better for the person asking for the research group or the students. And I would like to show you two example requests. And we can also think about what you like about these requests and I can tell you what I like about these requests. So in this example request, okay, I'm user John Doe on the cluster, so that's some cluster in no way. Since this morning, I can't log in anymore. I have tried to log in to some other clusters and this works. And the way I try to log in is I use the ZHKies, whatever that is, and the error that I get since this morning is, this is the error that I see. Thank you in advance for help advice on how to solve this. This is a very nice request. Yeah, like it shows things. And like if I see this, I immediately think, okay, so the person is probably not doing something wrong. And maybe there is a problem with the cluster. And that means it becomes top priority because it has all the information there right away. But it has everything here. I know which user, I know which machine it is. I also know that it's probably something with the machine or with the setup on the machine because it works with other machines. I also can see here that this is something that used to work. It's not the first time that the person tries ZHKies, but it's something that stopped working this morning. And then also I get an error message so I can try to search for it myself or try to reproduce myself. So very nice, very nice request. I wanted to show you another one, which is actually, it's a little bit paraphrased, but a real request. Okay, I'm not sure I wrote the right support, but what I am looking for is a virtual machine where we can install a PHP web server with a MySQL database behind it. It doesn't matter so much what these really are. What we have in mind, that's very good. What we really want to have is we want to have a service where we can share our data from our recent study. The data can be fully public. It's about 2,000 records so it's not much data and we would like to create a web front end where people can search through and plot our data. And looking forward to hear more and what you think about our approach. What is really nice about what I really like about this approach is that this request is that it's not only asking, please give me a virtual machine because I want to have a PHP server and MySQL, but also writing what they want to do with it. And this is actually a real request and it turned out in this case that there was a better way than PHP server and MySQL database. We ended up putting everything on GitHub. We didn't need any virtual machine. We didn't need any server. Everybody was happy and actually right now the collaboration with that group is paying 10% of my position. So it was really, really good to include also what they have in mind. There might be a better way. So XY problem. And I have two minutes left. So what I will skip here, I will skip this how to scale a problem and how to create a reproducible problem. But it's very useful. I still encourage you to please check out these slides. I think this is incredibly useful. I just want to go to, I want to jump to the last slide and remind that, well, you are not alone. There are resource software engineers near you. Go to Altogarache or pop in into a Q&A help session. Say hi. It doesn't have to be a problem. It can be an idea that you want to bounce off other people. You are probably not alone experiencing the issue that you are experiencing. No question is a stupid question. Many people actually really like, enjoy, they really enjoy helping. And here we talk a lot about problems and issues and tickets, but it's actually also nice to just write when something is working and when there is no problem. So every two years we get this email that somebody is actually really happy and things are working well. And this can be also really motivating to hear. So you can also write about stuff that has worked very well. So my time is, I think, almost up. Let's see whether we have any questions that we didn't answer. So XY problem case. Yeah. So this second request that I showed would be, that was the danger of being an XY problem that asking for something very specific, if the research group didn't include what they want to get to, they would have gotten the virtual machine. I think they would not have been very happy five years later. Yeah. There's also this question about chat. Okay. I'm switching to the HackMD. There's also this question about chat for things. So it's something at Alto we're trying to use a little bit more. So the problem with chat is that someone has to be watching it all the time. And it's really easy to be asked something to ask something, and then it gets forgotten and sort of scrolls off. And then there's never an answer. But for small things like, oh, I can't connect to the cluster, is this something? Then maybe we can more immediately answer that. Or I'm interested in such and such. Is this a good idea? And you can get like some of these things. And also users can help each other because again, our chat is internal, not private. And I think I have one more answer to the question of XY problem that I see often. But I will type it there is that somebody asking for more memory. My job rents out of memory. Can you please buy more RAM or can you show me how I can use more gigabytes of memory? And that can sometimes mean that it can be useful to actually look at the code. It can be a one line change in a Python code. And suddenly something that used to consume 10 gigabytes doesn't need to be about anymore. So I have seen also XY problems like that, something that can be solved with programming instead of throwing more memory on it. Yeah, okay. So I guess next is, well, thanks for everyone who listened and answered.