 Right. So it's 14.50 and I'm just going to start the presentation. Yes. So this is what we are going to do. We're going to have like housekeeping and about me for five minutes. I actually less than five minutes. It's just like I usually have a five minutes buffer. So if there is a lateness and so on and so forth we still have time. But I'm going to have housekeeping descriptions, explanation and about me. About housekeeping, this talk will not related to any technical stuff. So no technical related information in this presentation. So if you are expecting to have technical stories or technical way of doing things with your friends or with your team, this is not the right moment or not the right sessions. And also for the questions and answers, please keep the questions after the presentation. We will have a lot of time to do questions and answer. And also if you do want to ask questions, please use the microphone over there in the front. And as for your information, all of your questions or all of your voice will be recorded for letter use. So people at home or the one that cannot come to DrupalCon can see it. And then your voice will be recorded. Just F-I-A. That's the disclaimer. And then if you want to ask questions, please state your name, your role and what you want to do. Maybe it's related to what you are and what you are going to become or what you're willing to have in the future. And also please remind me that I should repeat the questions. I usually forget. So please remind me about that. Right. So back to the agenda. We will, we've done, but the housekeeping, we'll talk about the different types of roles that I had and their evolution. And then I will talk about the challenges and lessons learned and QAN discussions. So hopefully we can have a fruitful and really nice discussion after a while. Originally I applied for one-hour sessions, but they told me that can you do it in 30 minutes? And then I said, I take that challenge. So I'm probably going to, I'm going to speak really fast and go to really, I'm not going to explain every point, but if you have questions for each point, you can just ask me afterwards. Right. How's housekeeping about me? All right. This is about me. My name is Arady Nourizal. And in Drupal I'm called Neo Xavier and that's my user ID is still five-digit. So I created my Drupal ID around 11 and half years ago. I started with Drupal 4.4. And before that I was doing web development and other stuff. So I started doing development from 1997. And that's me with Drupal Guoba in, in Sweden. I don't know how do you call it. Drupal Do in English. And I took it when I was working in the, in Stockholm. So my old colleague is in front. Really nice. They call themselves different name at the moment. Hopefully they don't change their name next to Pogon because every time I meet them, they have different name. And then I'm wearing a traditional Indonesian clothes called Patek. We have International Patek Day. And then this is, I took it when we have the International Patek Day. I went to the office with these clothes. So pretty interesting. And oh, yeah. Fun fact is the most favorite clothes by, so Nelson Mandela really like these clothes. So you probably see Nelson Mandela using these pateks. And then there is a map over here. This is basically my life. I've been working, living and studying in those places. So it's quite a while. And at the moment I'm working for Lund University in Sweden. Okay. I don't see any people that speak Hindi, so there is no joke there. Because it means something else in Hindi you have to. Okay, next. Different types of roles and I had, and then in the revolutions. Right. I cannot actually see this. I have to go there. Yeah. This is the role I had when I was a single factor. So at first I start as a cobbler. What is cobbler? Cobbler is basically you do things randomly. If you see shoes cobbler, basically they recycle existing shoes and then to patch another shoes. That's what you do as a shoes cobbler. When I was a website cobbler, I basically took down existing website and then rewrite the stuff in it and then publish it as my own, basically. So that's how I learned web design by reverse engineering existing website in the internet with Notepad back then. And then after that I became a hobbyist. The difference is that I do it more regularly as the things that you do after work, the things that you do after school, after universities. So I was working in an oil and gas company, not related to any website, but I feel like I'm enjoying doing, you know, solving stuff, solving challenges in web development related. And then I had a purpose with my hobby. Like my purpose was started when my friend asked me to do their website. And then, oh, I think I can help them with this and that. And then, again, after that I get a real client that pay me with exposure. You probably know this. It's like, I think a lot of people in graphic design know about this. Like, can you do me a logo? But I cannot pay you, but you get an exposure because I show your logo everywhere and stuff. But it was fun because I had something to show people. And this is the reason why I'm making a website. Because as soon as you finish your stuff, suddenly like in instant, everyone in the world can access your creation. It's not the same in biopharmaceutical company, right? You need to have like tests and stuff. And this is the reason why I choose web development, not the desktop programming or other type of programming. And then I became a mature developer. That doing it part-time because I still had my work. And then I do the development as a freelancer on weekends. And then I became a professional developer. This happened when I was in Sweden. I did professionally, means that that was the only source of income that I had. I was studying and then I was doing website on the site. And then I became a professional developer in company. So the difference here is that when you are doing it yourself and then the client is yourself, you don't have to think about it a lot. I mean, the client is yourself, so you have like a big picture of what the end product will look like and then you basically doing that. But then if you work with other people, like the client is other person, you need to have some kind of a first communications and then some kind of expectation management. Expression management is that what you expect and your client expect supposed to be the same thing. Otherwise they will have like, I thought that you can do this while you don't have this, that kind of stuff. And then it will bite you in the end and then if it's your friends, then the cost will be your friendship. If it's freelancer, then the cost will be your pet testimonial in your, used to be like freelancer.com. Right now we have other website that do that. And then if it's in company, then it will cost your job. But the point is that you have to think about, if you do it yourself, you don't need to care about other people. If you work with someone, you have to care about their opinion. So you don't, you cannot push your opinion. You have to think about what the other people thinks about the end result of your product. Next is a team player. I was in a dev of two, development team of two people. And I was in development in a team of five people in HL workflow. And I was in a dev team where the front end is another company and we are doing the back end. And the UX is another company. And I was a lead developer, team builder, project manager, solution architect, and product developer as well. So I will tell you the difference between these two. In the dev of a team of two, so before that the big mindset change between the single factor and the team player is that you have to think about the first, the scope of your work. I mean, it used to be like you do everything and then if you work with the team, you have to stick with your scope. Even though you can do front end, you can do system administrator, but if your role is a back end developer, don't mess with other people. It's like, do you know the back seat driver things? You are driving and you don't want to be the back seat driver for that person because you will create unnecessary debate and unnecessary discussion that will prolong the project. And that may cost a lot of money because of that. And also, the difference between the team of two and the team of five is that you just need to have more time to plan. And then the more you go down, the more time you spend on planning rather than on development of things. So right now, 80% of the work will be planning, not actually developing the codes. When you work a lot, you don't need that much of planning because especially if you work for yourself, the client is yourself, you don't have that enough expectation and you don't need to build your reputation around it, right? And yes, and if you are a part of a team, development team in company, then you work with other company, then you have to have this kind of a shared jargon or shared lingo because one company may think one word means something and the other company means something else. That kind of shared lingo needs to be addressed or it needs to be discussed in the beginning of the project. It's part of the communication skill that you need to, when I see, when we say features, is it the features model or is it the features for the website? For instance, we have to have like that description when you work with other people as well. Otherwise, there will be confusion. There is a story with ISS, International Space Station. Some Lockheed Martin engineers built the model with imperial measurements, not metal, so it doesn't fit. Even though it says this is five and this is five, but the other guy is five meters, the other guy is five feet, so it doesn't match. That's kind of like, even though they are our technical engineers, they still have that problem as well. And then when you move to lead developer or when you are actually leading something, most of your time will be spent on actually taking care of other developers, not actually doing the work. The work is done by the specialist. As a leader, your work is taking care of the other developer, which is make sure that the other developer has whatever they need. Like, do you have a good connection or do you have a good environment? They can also, so the specialist can work as efficient as possible. And our, our, our, our I had a privilege helping a university to build a team, so you have to think about what is the workflow between the developer and I help as well with the infrastructure, I help as well with the, this is the, I'll say, the knowledge that you have to have first before you do a triple development, something like that. Then in, in this position, you have to think about not about one week, but like one year from now, what happened in one year, like, is your solution or is your prioritization match what we, match with what will happen in the next year or next two years. So for instance, if you are helped to build a team that doing triple seven and you know in like, in the next two years there will be triple eight, you have to make sure that the developer in that team knows about object oriented or if they don't know about object oriented, then you have to set a plan to educate them. And educating people takes a lot of time, so you have to plan that outside of the real world. So maybe you set like, I don't know, Friday workshop where you do that and something kind of education seminar every month, for instance. And also, if you are in the head of project manager, you don't do the code, you basically just plan. It's about planning and your role is about planning things, planning the resources, the human resource, the infrastructure, the other resources. So you have to make sure that that's your priorities. And as a solution architect, you have to know the goal of the project. That's the things. I mean, if the goal is to make your site faster, if the goal is to reduce cost of the existing solution, or the goal is other things. And then you have to create the solution that match the goal. And the important part here is again expectation management and the communication with the end user or the clients. What do they need for the project to be finished? Maybe you can split the project into two phase, like phase one or phase two. Maybe you can split the project into phase one, phase two or phase three. The point is, if you have the client expectation match with your expectation, that will be easier to communicate. And then it will be easier to ask for resources, for instance. And if you are a product developer, you have to match your expectation with what the company is about. I mean, what is the company things it will have in the future? Like what is the vision of the company? And the product supposed to have and then fulfill that vision. And again, the big difference between the single players and then the team player is the communications, expectation management. And if you are from different culture, you need to understand the client's culture first. How do you talk with each other? Like if you are a European company and you have a Chinese client, do you guys have different way of communicating things? And then, I don't know, maybe the Italian company work with the German company. I mean, they have different view of time, basically. And the Italian and the Spanish are probably a bit more lenient on time and the German is really strict on time. And then if you say, like five days, you want to finish in five days if the German thing about it, but the Spanish probably laugh five days each plus minus one or two, maybe. I don't know. Somebody have that experience probably. That's including as well. Because like if you have a plan, a timeline that this resources or this port or this firewall needs to be accessed tomorrow and then you work with some other people that, yeah, maybe plus minus and then, you know, what I understand as well, if you work with Swedish company, you have to take a thing about the June and July because that's a holiday in Sweden. So a lot of people actually try to avoid that month if you want to send stuff to Sweden. We'll send it on August or before June. Otherwise, you will not match with your expectation. Again, the emphasis is understanding your client, understanding your peers, do a lot of communication, make sure you have the same definition on something and then understand the culture. If you understand the culture, you can have two choices. Comply with their culture or basically make sure they change to your culture. But in my view, it's better if you can be more adaptable and more flexible to the client's culture. And then you can have better communication and then it will give you better reputation, better testimonial, better feedbacks. Right. And then this is the challenge and let's learn. The challenge is the scope of work. Again, if you work alone and you work everything by yourself, the scope is the whole project. If you work with other people, you have to have clear definition of the role. I'm doing this, you're doing that so there is no overlap. Because if there is no overlap, you're probably doing half way in this part and they are doing half way in that part and then after that, you have to have a discussion how you merge those things. That will take time. And a chance of mindset of you don't care about everyone and now you have to care about everyone. You have to care about everyone else. Like in Drupal, if you look at the Drupal issues, a lot of the things is not about, okay, if you have time, go to the Node 8. There is a famous Node 8 that's an issue that finished after eight years. So there is a lot of discussion about that. And if you have a lot of people working on the same project and that you want to make everyone happy, happy, then you have to spend time on that. Then you have to put it in your timeline. Again, empathize. This is a challenge because if you are not grew up in a culture where you empathize a lot of things and then maybe you are lonely or maybe you grew up by yourself in the high school and you don't have a lot of friends, you don't have this concept and then you have to learn this. But this can be learned because I was that guy. I didn't know how to empathize other people. I was thinking like I was the one that know everything and then, well, my way or there is no other way. And then you have to understand other people. And empathize start with listening. And listening is not the same as hearing. You can hear words but you're probably not listening to them. Listening have more than just hearing and putting the words inside your ears. You have to understand them. You have to know what they mean. If they mean A, does it mean A, B, C or is there other background that makes them say A? You have to know that. And then this is related to cultures specifically because I'm coming from the East culture in the nations of East Asia and then I'm working in Europe. And the work ethics, the communication style and the formalities are not the same. So the work ethics in certain countries in Asia is not that hard but in western countries is pretty there. Some people are workaholic there. And then in Indonesia also our work ethics is after 6 p.m., a lot of people are still working in Japan. They finish at work at 10. And in Germany, when I was working in Germany, they sat down the computer after 5. They kicked me out of the office 4.45. And then because of that, I learned that I cannot work more after 5. Then I have to reprioritize my work. So you have to understand if you just came from Asia and then you work in Europe, you have to think about what the other people expectation of you in Asia is. It's not suggested. People are over time teams, over time is common in Asia but not in Europe as far as I know. And the communication style and the formalities is also important. If you are from Europe and you're not familiar with formalities, that you call your boss or your client without a short name or without the sort or something like that, and then you work with Japanese, that maybe there will be unnecessary tension between that because in Japanese culture formalities is really important. Then you have to think about the target culture as well. Right. And then the next one is a lesson learned. Done is better than perfect. When you work alone, you want everything to be perfect. But if you are working with other people and then you have client, then it's better than perfect. The reason is because there is money involved behind that. And then to get that money, some organizations need to go a certain length to get that funding for your project. And then the organization also want to see the result of the money that they spend so they can justify to the taxpayer for instance or the larger organizations. So, done is better than perfect. It's related to the prioritizations. Ninety-five percent delivered is better than 100 percent is not delivered. Right. And then after that you can improve the 5 percent over time. And then you are not a superman, so you have to delegate some stuff. If you are single-fighter, you think you know everything and then you can do everything. When you are working with other people, you have to delegate like, I'm doing this, you're doing that, and I'm not going to touch that because that's your work. And then we can do it, we can do everything parallelly. Yes, don't be a superman, be Avengers or Justice League, depending on what religion you are. Means that Avengers and Justice League has, they have different skill, but they have the same goal. This is what we are supposed to be as a team. And the member of Avengers or Justice League can change over time, but the name is the same and the goal is the same. That's what team or group supposed to be like. And organization or company is basically just a group of people. And again, listening is not the same as hearing. This is goes 5 percent for the people that saying the things and then listening to the things. Because if you just hear the word like, yeah I'm hearing the word, but you don't actually act upon the words that you hear, then the one saying it will not say it again to you. And then you as a project manager, for instance, oh this developer is really nice. I think the problem is gone because he never tell me any complaints again. Maybe because the project manager's name fell, listens and then developer doesn't want to tell the project manager again. And there is two more stuff. Assumption is your worst enemy. Do not assume. Just confirm that what you hear is actually what they meant. Do not assume. If you don't know, just pretend that you don't know anything and then just ask questions. Because when you ask questions you may learn something new. If you just talk then you just repeat it yourself. And then what you need or what they want, what you want or what they need is probably not what you need or what they need. Use that as a basis. So maybe you want the new cool stuff but probably that's not what you need at the moment. Use the data. Like do we need Facebook M or Google M? Something like that. Oh because it's new stuff. But then when you look at it from the data, if you implement that, probably there is no use. So we probably don't budget for that features to be implemented at the moment. Right. And then we have both sessions on 28th of September about sharing configuration in multi-sat environment in Drupal 8. Please come and then show your thoughts about it. We will have, we will show our experiments with features and configuration management in Drupal 8. And there will be other people that will share their setup as well. Right. And then join us for contribution sprint. If you have not been in the sprint, you can go to the first-time sprint cylinder workshop and in the end of the session they usually have live core commits. Maybe there is interesting stuff because last time there was a baby that do a core commit. They take the baby on stage and they let the baby press the enter button. Sprint instinct. I don't know what they will have to do. Next sprint. Right. So what do you think about it? You can send the survey there. And this is a question and discussion. I don't know how many times we have, I think we still have around eight minutes or so or less. Or this finish. Right. I don't think we have more time but if you have questions just approach me after the sessions and then we can talk more. Right.