 Hello, good night, good afternoon, good morning everybody around the world. This is an informal Google Summer of Code office hour today is the 13th in April, informal because we're currently in the review and ranking of the proposal, so we're just hanging there and having interesting questions or topics to discuss and I believe Mukul had an interesting question where you wanted to have some reflections on experiences that he had. So Mukul go ahead. So my question is like so I start, for example, I start with the data report or open source present like is your open source present and for approaching that project like people say you don't have to understand the whole code base to work on a issue or something on or implementing a feature. So what I do is like I go to the source file like main dot for example if I'm working with go present like I will go to the main dot go and see what that is calling or what the main person is calling and from there I approach to the other functions call that they are calling and so but I think this is inefficient like I have to do review of the code base to understand what is going on and what I can do like for that feature like assume that I have to search for a file like for a feature for a feature implementation I want to search for a file like where I can put that feature but for this understanding itself I have to understand the code base itself to some extent. So how can I proceed with the understanding of the code base like understanding from the main person itself takes a lot of time. So how do you do this? Now it's this question is a beautiful one and I will give the word to Mark because I think he has some good experiences there. Just want to say there this is a key question and if you master this type of action so getting into a code base I think you have the key for an interesting and rewarding professional career because this will be so often that you will have to deal with this kind of things. So Mark, what are the kind of tips, advice or experience that we can share with him? So I think first the most fair thing will highlight is that's the reality of software engineering for the foreseeable future. You will spend a lot more time reading code than writing code. Some of the smartest programmers I've ever known have consistently and repeatedly told me they spend much more time reading code than writing it. So the reality is this is ahead of you for a very long time this ratio of read versus write because you've got to understand first. So no shame that's good. Now on the sneaky tricks to understand a code base sooner. Okay, I'll share a couple of sneaky tricks that I have and let other people speak up. Sneaky trick number one is run the product and see how it behaves. Watch it from a user experience to see how it behaves. After watching how it behaves as a user experience, run the product from a debugger, set breakpoints on things that you find interesting and try to hit them. And the indicator there is oh, oh, I did get it. I know how this code is behaving or I didn't. And so the debugger is my friend for code comprehension. Other people probably have different techniques, but for me, I like a debugger and looking at the code to see what it does, how it works and what my experience is using it. Inevitably I discover in the debugger that things I thought I knew, I did not in fact know or what I knew was false. That's all that I thought. Yeah, and this is basically it's like a scientist you take your, your magnifying glass and you look in and try to see how the code went through there. And when I touch this button, this then happens or this exactly observing another tip I'm going to add before giving the word to whoever wants to add there is a very good entry point is looking for tests. And the tests that have in the name end to end or integration or these kinds of things, they tend to activate multiple pieces. And once you understood the global functionality of what it is, reading the tests exposes in more details. This is what the code is supposed to do. This happens. And the third tip is that alter the code on your local copy and add signals or flags or things that you know, oh, I went through here. And if I change that value by hand, this is what happens, or this fails or these kinds of things, but it boils down to the same idea is trying to understand by observing how it works to to understand. Is there anyone else who has experience on on on that. Regive Chris. Yeah, it's usually good practice to set yourself up as a user first. So you have the first hand experience of what to expect in every stage and every step. And functionality, right. Yeah, exactly. Very, very good. Is there some somebody else, Rajiv or Yeah, I just like I want to add like the best thing is to learn by doing so this is like something you just go through like rough. Since I think this be the students are these are all college students so they have like much idea about that. So whatever they read it, they go through as a scratch like a general user perspective. So they get more overview of something so just like start with a user and just hit and trial this learn by doing and just go through that that that's a process. There's something I'd like to add because I've seen that in a question of cool and I'll let him then afterwards react on that. The question would be, you first try to understand the global picture of what the code base does, or do you only concentrate on the feature you're going to work on. And, and you just fly into it and try to understand the piece that you're going to to change mark. Do you have an opinion on that before I give mine. I actually don't I've I've done both and had varied results from either. Exactly it is was basically what what I wanted to say. It depends. It depends also from your nature. Some people have a holistic approach they first need to get the global picture to understand the various components how they interact and how they live together. And the approach that we described that Chris was hinting to first to understand how it works on the surface, then starts digging into it and peeling off the layers of the onion. Before you get others go immediately to the feature. And, and to the active item they want and then builds the global picture of it. Mileage depends depends on the case depends on the way you, you, you tackle problems. So it really depends. So Mukul you had a plate full of answer to your very interesting question, is there something useful for you in it. Yes, yes. Like, I basically try to run it. That's what I do, and I execute, I exit, not execute I like understand it from the main person and that's what I do, but this still doesn't give me what I was thinking like you. I was thinking like you. You must be using some tools or something like that will that would have make it easier for you. But that wasn't the case and you guys are also reading it, but understanding it by reading it and that's how things work. Yeah, there's no miracle solution for that one. And Mark, you wanted to say something. Yeah, I think I think your ID is a good, a good friend. Right. Be sure you use it. So read advice some years ago of people who advise specifically to spend time learning more about the features of your integrated development environment because it can help you navigate code much more rapidly. The additional skill you have to develop not something anybody else can can really teach it's how do I navigate from one symbol to another inside my integrated development environment. How do I set a break point how do I remove the break point how do all things that you're spending time intentionally learning how to use your ID well are a good thing. I, I happen to use a rather strange ID environment and it works for me other people use more standard ID environments but knowing your environment and what works for you is really is a is a can make your comprehension process faster. Yeah. I have one comment I'd like to add to it. The conclusion of the discussion we have now is that reading the codes is where where the majority of people start and spend a lot of time in Mark shared that very experienced developers spend a huge amount of their time doing that. When you write your code. In fact, you're talking. Literally talking to the people or to yourself in a couple of months that will read your code. And so be be wary of that and and and try to help the person by choosing adequate variable names method names. An adequate comment, not to comment this is a function that or a method that does this yeah from the name you can figure that but why did you choose that algorithm so it's a dialogue that you're setting up with the person. Reading, you're not talking to the computer he's clever enough and he doesn't need you're talking to human. Just wanted to add that. And for the joke I can. I can add that maybe remember that a person who's going to maintain your code is a psychopath that knows where you're living to take care of him and don't try to make him angry. This is a little bit too far. Remember you're talking to either yourself or a colleague in a couple of months. Does that help you. Yes, I have another question. Like you were talking about choosing name for funds. So, assuming that I have a feature request issue for feature request, and I create a function. Now, what is happening that that person is like use calling a function that is already implemented, but I didn't know about that that the function was present in the code base. So I created my own implementation of that function. So, how can you know that the function was there or what can I do about this like the function name. It can decide by function name, like someone said that that function name should be XYZ and I have my implementation that saying that ABC. So, now there will be two funds and doing the same job. While, what I should be doing is using the function XYZ that is already present. So, what can I do to like handle this kind of situation. Currently, I like after I raise up here the maintainer will say that this is already present use that and I will fix that and like look for the changes. This is okay but you're waiting for somebody to to catch it up. Good point. And this is where. But here you wasting your time or you spending your time and the maintainers time so there might be other strategies mark, you wanted to say something interesting dialogue. Yeah. Okay, so, so recent story. I was found by reading the Java doc of a particular test method a test class called Jenkins rule that there were features inside that thing that after many years of doing Jenkins development I didn't realize they were there. Okay, no shame. I went in and started using them. So I think Michael the correct answer is great, you learn something you won't have to learn that again. But it's you solve the initial problem, write the function you needed. Somebody told you hey you know what there's a way to simplify this. Great. Now you've learned, and you simplify it, revise it, and keep going. We start where we are, and we learn more about the things in my case. There were some impressively capable functions in Jenkins rule that some really smart people had created that I should have been using for a long time. And reading Java doc would have been a good thing if I'd done it several years ago, but I wasn't at that point interested in reading the Java doc but I might have should have about that important piece. So, it's okay. This is the message. If you want to improve yourself like getting to know the features of your ID, which is a very good exercise, or another tip that I give to young young people is increase your typing skills to increase your speeds which are these. Hey, you have a couple of half an hour an hour to spend. Hey, start digging into the code, or the Java doc of the libraries that you're using can even be the Java ones, and, or, or the mainstream ones, and have a look and say, Oh, yeah, I didn't know that or this is. Oh, and so you build up your passive knowledge of the features that are available. So, before giving you back the word I'm going to ask, are there comments on this or other questions I seen that Sonali joined the call. Zach also joined a call so want to give you also a chance to either give your opinion on on that or ask a question. Cool is a very good question. Good evening, everyone. Good evening Sonali something to share or ask. Honestly, I don't have anything I've been busy with my exams. I also have an exam tomorrow. So I was just studying mobile computing. Okay, good. We have five minutes left. Other questions other topics. Mukul, I think something had a question you had already a lot of CPU cycles for you so I live. It's not that go ahead. Yes, thank you. So, first of all, I'm having a lot of fun in these meetings. And the questions I want to ask are not necessarily related to open source, but more of general career advice. My first question is that how do I negotiate my salary. In an interview. So, I have that sort of that's an interesting question. Now, I can't give you advice on on on that one. I started trying a baseball bats by and when discussing with during the interview here. I will not be able to help you on that one. And the only thing I can, I can give you is by increasing your market value, let's say that way, building your experience and being able to show to the recruiter will make you in a better position for these kind of discussions. And what we're doing here through open source is a wonderful way to build that experience so this is why we're spending the time, not only for open source but also for you. This is a win-win situation where the community gains from the people's work but you as a human being learn. So you're increasing your market value as a developer with that. Now, how do you talk to an employer or I, I, I can't give any good advice, especially as it's very cultural. So it really depends from country to country. So I'm sorry for that one was an interesting question for him but that one I, I'm sorry, unless Mark has or somebody else has. I'm sorry salary negotiations are a country specific and a company specific thing by all means plan for it. Don't be shy about asking, but ask the people around the organization where you're discussing what the expectations are, etc, etc. US salary negotiations, I'm confident are quite different than salary negotiations and negotiations in India. I'm sure that Chris negotiates very differently in in Hong Kong and John Mark differently in Belgium, right, each, each has their own place and talk to people who are geographically near you preferably also company near you so that you understand what your choices are and what options you've got. Other question cool you had a question. So, this is basically about the issues that are marked as bug. So, how do we replicate environment likes this is that the bug was produced and XYZ OS. So, how do you guys like do that. Do you use AWS VMs or like local VMs, because if I use local VMs there. I will have memory constraint like I have 16 GB RAM and I don't think it will be enough to run the program like in a nice way or and I mean, so how do you like replicate a environment which can produce that bug. Mark, you want to say something or do you want me to start or go ahead and try first with what you've got, because what you've got is local to you is convenient, easy and fast. Try try first with what you've got because the difference between your environment and the place where it where the bug was initially reported may not be relevant. And so your 16 gigabyte machine your four gigabyte Raspberry Pi, maybe enough to duplicate the problem. If that's what you've got locally. If you can't duplicate it. That's good information to tell to the person who reported the issue saying, I attempted to duplicate the problem. I took the following steps and couldn't that will then help them understand. Oh, okay. I did not give enough detail, and you give them back more detail saying, here's what I attempted. I ran this on this equipment with this environment, and it didn't show the problem. So hopefully they will realize, oh, I need to say more. If not, you can tell them directly, please tell me how you duplicated the problem give me more precise steps. This is exactly what I wanted to say. Does that answer your question. Basically, like in few of the issues. They maintain a like mentioned that the issue is replicable replicable, but for that. For the logs are for what I want to see what is happening wrong deal. I have to replicate that so how can I do that like what you guys are what you guys do for that. I want to ask that, like the problem is arising in specific environment like specific OS or specific conditions only. So, how do you always. Well, so, so if it truly is environment specific. That's impressive, right, because that's rare. It's, it's surprisingly rare for it to be environment specific but maybe it is that they say hey I only get this failure when I'm running on a system 390 mainframe running ZOS, not running Linux on that system 390 mainframe from IBM. In case you can ask for log files, as you said you can ask for log files you can ask for diagnostics, you can inject additional diagnostics and give them a new build and say, this build has these additional diagnostics that will help. Someone like I very much trust calls that remote debugging and notes that it's very very difficult. Right it's very expensive because the round trip time is so slow. And here, focusing on trying to reproduce the environment is is very seldom required. As Mark said, unless there are signals that show that it's environment specific because you have error messages in in the operating system, or you have memory related problems. So, and try first based on the environment to reproduce the functional part the sequence of steps that were that were required. Hello to Tabi, they joined the call. Thank you for turning the camera on I like seeing the faces so welcome aboard. So Mukul, did that answer your, your question. I guess. Okay, does somebody else have a have a question. No, I'm going to ask because Tabi opened her camera. Where are you calling in from. Kenya. Kenya. Okay, nice. So I'm very happy to to have a lady joining and also to have somebody from the African continent. Very good. I just have a little return over here so welcome. There are other questions or topics that can be discussed today otherwise we're slowly going to close this call and meet again next week. Note that mentors are very busy these days. In order to do a lot of chasing somebody wants to add something for this call or a question, comment, experience. Otherwise, I'm personally very happy to see the people joining. In the waiting period, is it okay for us to like continue. But or that contributing for the issue from the GitHub. Yes, yes, so this is a general comment I just going to find okay to go on mute because there's a loop back in there. So, please continue. It's it's part of building your muscle building your experience. They are a lot of candidates this year. A lot and we only have a limited number of seats. But with all the experience that you're gaining. You will be able to compete again next year with a much better position with the experience. And on the other side, professionally also you continue to learn and see how the community works will also have October fast, which is another open source event so here. Don't hesitate to continue. You're you're welcome and will I try to range also to have people available from the community to guide you will be maybe less focused than with Google summer of code but here. Let's have fun together. Don't drop the effort. A lot of people spend a lot of energy learning things investing and here we're nice. Nice group of people here and we can also help each other here so don't hesitate also to help other students or young contributors. So good question. Here. I think we're going to leave it that because I generally go up to the hour and each time my dog is getting upset because he's waiting behind the door to have his walk. It's the evening here. So we'll close the. The call here. Thank you very much for everybody to have. Joint will will make a little bit more publicity on Gitter if people forget the exact time. When the office hour. Starts in a pleasure to meet you all. And see you then next week. Okay. Thanks. Cheers. Bye bye. Thank you Alyssa for joining. Bye. Thank you.