Setting up new developers for success

Speaker 1: Saving uh all the energy for the end of the day. And uh

Speaker 2: that's an assumption. But okay.

Speaker 1: And I'm super excited to to hear this talk. I mean we've all once been a new developer. So uh let's see how we can help

Speaker 2: yeah

Speaker 1: more of those to get started.

Speaker 2: Yeah. So who am I? I am Marike. I am from the Netherlands, uh Groningen specifically, which is like all the way up in the north. Uh what am I? I actually started uh with IT at 12, worked my first HTML then. I love, love, love front-end web development, which is exactly why I don't do that professionally. Uh so I became a back-end developer, uh studied it as well. I think I've been in

Speaker 2: I'm not sure how long I've been, but somewhere between one or two decades in IT. I have two jobs at the moment. I work at Clipa, which is a OCR company, so you can scan like receipts and they put it through a whole cool like monetary tracking system. Well it's cool. And it's a really cool company as well. And on Fridays I am a coach at something called the BIC Academy. It's a vocational education. Those are teens. They are ruthless. Like they were the first people to see this presentation after that. Nothing was scary anymore. Um like seriously, they are. But like my students range between 15 and 33 of age at the moment. So that is quite

Speaker 2: quite a lot. Also, I will try to stand still, but I am very AHD and tired. So let's just get started and I hope, spoilers. More spoilers. Oh my goodness. That is a shame. Um yeah, it was this one. I I love this thing. Seriously. I have a couple sections. It's uh some like preparation, uh a bit about psychological safety, um practicalities, and some parting words of wisdom But first, leave your ego at the door. What I mean with that is if you want to train juniors or I call them new developers. Because uh you want people

Speaker 2: to adore you or want to know how amazing you are or whether you want to tell them, yeah, I'm your boss, so do this or whatever. Anything like power plays or like ego tripping No, that's makes you that sort of disqualifies you for the job. So if you want to go on power trip, stay away from juniors. So with that being said, preps. Get your house in order first. You first always need to have an onboarding strategy in your company. One of these reasons is because people who are new especially when they're new in your in your company. That can also be senior developers by the way. They need to know who, well, what the company is, who the company is, and who to ask when Something is wrong. Clipper

Speaker 2: does a pretty cool job because as a new developer you visit every stand-up of every team once. You get like introduction. um presentations and there's like a whole hub with info and there's HR that you can ask and everyone's available, even a board, so that is pretty cool. So people sort of learn in their first month where they have to go with which questions. Is it going to fill me now? Seriously? No. Tools for communication. You must not only have one tool of communication, it's plural for a reason, multiple tools for communication. For example, I uh I have a lot of information processing issues. So if you talk to me, I will Definitely not hear half of what you're saying and probably not understand the other half.

Speaker 2: So I prefer written, but some people just want to do Zoom goals all day, which is um my definition of hell. But Some people prefer that. So you ha must have multiple ways and tools for communication. And I um I am a huge fan of documentation, so I just push this everywhere. You must have documentation of everything. How the company works, how products work, whatever. Documentation brings a bit of like self-supportiveness to people. What's it called again? Independence. Uh and also uh it allows you to forget things. Like you write it down, people forget. I have once had a direct colleague die, like over the Christmas, that was really bad. Um and he didn't document, so I was

Speaker 2: like That double sucked, like personally and professionally that both sucked. So write everything down. What's in someone's head should be on paper. And the good thing about documentation is the shorter it is, the higher the chance that someone is going to read it. So all that. By the way, I completely fangirled over uh Wilhelm's presentation earlier. So everything he said All that and more. So psychological safety. This is the most important thing. What you must provide for anyone, but especially juniors, is a safe environment for them in which to make mistakes and to function because people who feel unsafe will uh they will not function or they might get angry or whatever, you'll get into trouble.

Speaker 2: Um I did not come up with this idea. This is actually I don't know whether it was Google who came up with the idea, but they did study this and in 2012 they discovered that psychological safety is the number one key to having successful teams. Let's dive into it. Um one thing you must know beforehand is your position of power with towards another person. People always have like sort of an unwritten hierarchy. Like people who have been longer in a company will always be looked up to by new developers or new people. But there's also more like cultural and We of course have a lot of sexism and racism and now look around the room for a moment and count the number of people here you see who are not a white dude.

Speaker 2: Yeah. Everyone's like, yeah. Um so the first if you have like a company full of white dudes which uh we call a monoculture, the first woman or black person or whatever to walk in is probably going to suffer or uh unless you have like a really good system in place to make them feel happy and even then it's a lot of work. I am by the way not qualified to dive into the details for this but you always must be aware you might have a position of power. And I had a boss, or like yeah, he was a boss, not a leader, and he um hope he's not watching. Uh ex-boss luckily, but he uh always said like I want people to be honest to me, to tell me what's going on. The thing is, people, especially when they don't have like a long-term contract, are not going to be honest to their employer.

Speaker 2: So you can say that you want people to be honest, but meh. So um always keep in mind. Door precision. Oh my goodness. Um you are getting so many spoilers today. That's really good. Um You do not want to clone. Your role as a guide is to sort of supplement their lack of experience with yours. I mean everyone can learn. But the experience is the real thing that makes you a developer. I mean, we all become seniors because we have wrecked production a couple of times, or in my case Done a lot of dumb things, including deploying at five PM on a Friday afternoon while drinking wine

Speaker 2: That was not my best moment. It was many years ago and it was really dumb. But like if you haven't destroyed production database or whatever, at least once in your life have you ever been a developer Well, or you are a new developer, but you will. So you know, it'll be cool. Um but like people have like a lot of opinions. I I think developers are super super stubborn and they're like yeah but I want it to be done like this or that and my goodness um style guides are like Something else. But you must remember that you do not want someone who thinks exactly like you do. Actually, it's more beneficial to have someone who does not think like

Speaker 2: you because different people will come up with different solutions and if we all act the same way we won't have like a complete solution. For example, I am I love web accessibility. I'm not that good at it, but I advocate it everywhere. Like I actually made a mistake earlier today on Twitter not uh writing the the hashtag correctly. Yeah, feel free to retweet. And that's the thing because we don't have a lot of like blind people in our daily lives, maybe, but we need to learn to cater to people who are not like us. I mean we are technical, safety people with fast internet, good devices. Most of us are fully able.

Speaker 2: So we are like probably the worst user to design for because we are perfect. And I say perfect because we're not perfect, but for developers we're like the easiest target group It's way better to target to a broad range of people and if you have a broad team, there's more chance of you achieving that. It will also, by the way, cost a lot more time discussing everything. But well um Suck it up, I think. So oh and that also uh sort of ties in with new developers' new ideas, but what I mean with this one Is that new people will look at your code or whatever and they will be like, huh, why is that? And you're like, yeah, but we've been doing it like this for years.

Speaker 2: Okay, but why? And then sometimes In a good situation, gears will start rolling. They'll be like, yeah, why are we doing this? And I also make sure, like, if I have some some people, uh young people, I will sometimes just drag them with me to complicated whiteboard sessions or whatever because I think they are super valuable. Either they just learn or they contribute new ideas, which is a win-win. With that being said, this is my favorite. Success is a team effort, so is failure. I think working together is as a team is what makes good products I just casually mentioned doing a really dumb deploy

Speaker 2: at Friday afternoon while drinking wine. That was a bit dumb, but there were three seniors sitting around next to me who could have dragged me away from the screen, which they should have done of course, but um had I destroyed production it would have been their fault as well. You cannot blame something on the junior because yeah who more if if like if you can allow like a new developer to ship a buck to production They can also be like, yeah, but who approved it? Who guided them? Who whatever? You cannot pinpoint a problem one person. But so is success. Like you support each other, you learn from each other. At Clipo we try to have people like ask questions in public channels and not in DMs, so everyone can chime in

Speaker 2: and also for people to learn to ask questions. So work together. That is yeah important. And I also always make a point of making compliments in public. Why? Well for one, um very practical. HR is in charge of renewing contracts. Um and the people who are in charge of renewing contracts usually don't know how someone performs. But if they see that someone got a lot of compliments in public , they have like more reason to to keep someone uh on the employment role. But it also sort of improves someone's confidence and social standing and you can say like yeah this person did something really well. Uh

Speaker 2: plus we just need a bit more love in the world, I think But keep your feedback private. And when I mean feedback, I don't mean code feedback. I mean like when you notice that someone is not performing well. You know, if you'd ask someone in public, yeah, why have you or like if you even say you suck, that would be weird. But why have you been doing so badly these days? There's so many things wrong with that question. But um Maybe someone is grieving or stressed or whatever, and if you just put them out there, like HR is going to know, colleagues is going to know, there will be shame, there will be stress. It sort of starts a downward spiral So anything sensitive, put it in private, but like

Speaker 2: boost someone up in public and like a lot So practical these. More spoilers. Um more spoilers. Oh my god. Give an ADHD or a button and things go wrong, like seriously. Um oh my god, things go really wrong. This is really fun. I am having so much fun. with this thing. I hope you are too. Um I am not touching the button now. You must limit the number of context moments. I learned this from experienced senior developers. I always thought that if you have to guide someone you sort of have to helicopter over them and just Keep checking in with them. Which is a bad idea because she also needs to let people go. So I check up on people maybe once a day.

Speaker 2: twice a day and I make sure that they know that they can reach me if they really need me. Or when I notice on the springboard that things are going slower than expected. But um funny thing is one of the best things you can do while helping people is to leave them alone. It's pretty allowers. I never thought about this before, but Top two. And I also reserve time slots. So I always know like at a certain Thursday afternoon or Tuesday afternoon I have a time reserved for someone. And you also must do that when you think you have nothing to discuss because either you're going to find something to discuss or you have some private bonding time or whatever. Just make sure like This part of my agenda is yours.

Speaker 2: I think people respond really well to that because that's clarity and they know they have dedicated time and all that. And always stick to the one-on-one sessions. One-on-one, they don't have to be paired pro programming, though I do love pair programming. Um A lot of people indicated to me that they don't really like the whole classroom vibe, but with one-on-one sessions You can sort of remove the classroom fight because you can focus on someone's specific needs. Because like some people like I said prefer uh verbal communication. For me, like Write things down and in bullet points. Like if you give me I will if you give me a bit of text like this, I will never read it Promised. So you can cater your sessions to someone and they will feel free.

Speaker 2: And if they have something private to discuss, you have time for that as well. So yeah. I love this one as well. Actually, I love a whole lot of these slides and tips. I think I just love my job. But anywho , I have been Going through my slides in a high speed time. So we're already at the parting words. I have two words of wis sets of wisdom for you. First one is treat people like they're going to be around for years. There's this lovely fake conversation where someone says, um What if we train someone and they leave? To which someone responds, what if we don't train someone and they stay?

Speaker 2: I can tell you like who would prefer the first situation? Hansenier? Okay, who would prefer the second situation You are allowed to raise your hand. I mean I'm I'm good. No shame. Yeah, so just train them. Which brings me to the second point. If you treat people well, they will advocate for you as well. It's like if you have an ex-employer or ex-colleague who is still talking really well about you. You have done your job right Um and worst thing that can happen is you have invested some time in them and it's lost, or at least it that's good for the other company who takes them after you Um but in the best situation you have an amazing colleague

Speaker 2: for years. And I also think that if you give the right example, like if you treat people well , um genuine kindness and interest that they will learn to do it back because I think we do have a bit of a vulnerability issue, at least a lack of vulnerability issue in IT where it's all like Well, I'm cool, I'm amazing and everything I do is the best thing ever. Yeah, that's not very healthy. I mean we don't have to be all cuddly and cute together, but some Level of empathy would be preferable as well. With that being said, I think I have just broken my record for this presentation. A little wrap-up. I hope my head is not in front No. Um

Speaker 2: one of the things you have to do is provide psychological safety to people, which is actually the core of having a successful team I this is one of the slides I edited. What did I put here? Do not put people on the spot unless it's a compliment. Yeah. And you are a safety net, not constant supervision. And with that being said, where is my question slide? I had a question slide. Um Let's just keep it here then. Um are there any questions? By the way, if anyone follows me on Twitter, you know like it's a bloody miracle that I am

Speaker 2: even here. So um I am spent.

Speaker 1: Thank you so so much.

Speaker 2: Yeah.

Speaker 1: Let me be your question slide then. Um Are there any questions from the audience?

Speaker 3: uh only giving positive feedback in public right if you if you get like asked by by managers or something to provide feedback on some One do you also keep it exclusively positive? Because I have so far been doing that, but I noticed in company everybody is doing it and it leads

Speaker 2: So the question yeah, the question is do we like stick to only positive feedback when managers ask? I don't. Um I will of course always present even negative feedback as like just a fact and not as a personal attack, not like, oh, he is not performing well, but they could do better. Or that I will find the words to not make it a personal attack. But I think if we want to teach people, we do them no justice to coddle them. And what you also make must make sure is that your team as a whole is functional. And if you have one person who is not really going well, not really going right, you risk upsetting the balance of your whole team So I don't really see it as much as negative feedback when we're like things they still need to learn and then we decide, I usually do that with my uh

Speaker 2: team lead, uh, to focus a bit more on that in the coming weeks to just steer them in the right direction. Does that answer your question?

Speaker 3: Yes.

Speaker 2: Cool.

Speaker 1: A question in the back in the back end.

Speaker 4: or if it hasn't been as good. I'm curious what what your advice would be about how we can all be more vulnerable with each other.

Speaker 2: Well, how can we all be more vulnerable with each other? I think actually as dude you probably have to figure that out yourself a little bit, but I think honesty on itself is already good. Like you can just start practicing like little things like I haven't slept well or d or I don't really feel so well. Just just start with the little things and practice and then eventually it will start growing. You don't have to open your heart to everyone. Um and you know no one's going to force you to. I hope, at least that would be an HR breach probably. But you can just practice with the little things and build it up. And if If other people see you do it, then they will also start copying and then you get more genuine two-way conversations as well. Start practicing. Oh, and don't laugh at each other.

Speaker 2: Like, seriously, some some of you can be really mean to others. Like, ha, you, you are like, Oh wow, you feel bad. Don't don't put people down when they are opening up. Reward the good behavior.

Speaker 1: So many good uh so much good advice here and and and uh if I can add a comment, it's not just about companies but also about communities. Uh so for instance a conference uh event or a meetup uh where people are new and a lot of this goes as well.

Speaker 2: Yeah, I but I actually told Paulo this morning, I feel like we are our presentations are like the perfect hamburger today. Like he starts with the community, I end with the uh more like personalized approach and then everyone in between halfly spoiled some of the slides. But I think a lot of people I think this this is a really good place where we're all helping each other. Maybe you don't find every presentation in Interesting, but it's still like you can still compliment people like might not be your subject, but cool that you did it. I mean not everyone dares to put themselves up on the internet. Forever, for everyone's uh eyes and scrutiny to see.

Speaker 1: I couldn't agree more. Um I have a question. Um And I'm kind of hoping for for I'm looking forward to your answer, uh but uh

Speaker 2: Oh yeah.

Speaker 1: Does this uh advice of onboard having an onboarding strategy, does that go for all organizations? No matter their size, no matter

Speaker 2: I think it does. Um I'm glad that you're happy with my answer. Um also because um I've worked I've I've I'm now in my second startup going scale up. Um I've actually I am this is like with Clipa, this is the second time I'm uh experiencing this this this pattern and I notice how handy it is that pe that they have already sort of practiced with certain strategies when they were small because then they can scale it up instead of like oh dear we now have 30 employees what do we do with them So you can just build it up and actually it's really good because if you're a small team you can easily make uh like small corrections and all personal. Which is much easier than when you have to cater to 30 people.

Speaker 2: So you have some time to just dig in a bit. So it's actually I think actually you should start when you're l really small. That's the ideal time.

Speaker 1: Hmm. It doesn't have to be the onboarding strategy, but just a.

Speaker 2: Yeah, but we all learn. That's the thing. But but if you like ask for feedback as well, like how did you think This was going, you will have some tools to make it even better for the next person. I mean it is everything almost in communication is a two-way street, if you want to, which you should. Um so yeah, just go start onboarding.

Speaker 1: There's a question there.

Speaker 5: You emphasize quite much about uh documentation. And I cannot disagree with you. And documentation, but the thing that I encounter if the time is the is it being maintained or how is it done or how is the the line for it or principle for it and so on. Do you have any advice or models or interviews like that for healing up, you would say, or feature in a shape

Speaker 2: I I I did actually write a blog a couple years ago, blog article, which mentioned some of these things. Actually documentation was a bit out of scope, but I think it's just one of the most important uh things. Um I always say that documentation it's better to have no documentation and outdated documentation and it's almost impossible to document after the fact. So when I see a uh a a pull request Without documentation I will nag people and like seriously I got named head of documentation after some point because they were so I have been doing this for weeks and they were like okay you're head of documentation now jokingly and it kind of stuck Um and I also have like Flake 8 plugins. I don't know who know does anyone not yeah. I have precommit with Flake 8 plugins.

Speaker 2: Um and I kept telling some of my people to a team that they needed to end their documentation with a dot and start it with a capital letter. That was so annoying, so I just added flagate plugins that now do it for me, which is really cool because now I'm not the annoying Ben nah dictator Plague Ades now. So it just automated away and and deny pull requests without documentation. I think it's also a bit like the same as with unit tests or whatever. Like it's not maintainable if it's not there. Like So just force people to write it and people will object to that, usually salespeople I think. Yeah, you'll have to figure a way together to bypass

Speaker 2: sales in that case, if they don't want it. I think uh most see the benefit these days Yes.

Speaker 1: Yes. Next question. It's uh at the window. Yeah.

Speaker 5: I think uh they often said is the uh the best uh uh teacher is someone who just learned And according to some of the things you said, we should also uh educate people to educate uh uh which is uh like saying when you learn when you learn this you would be the next one to teach the the on the next on what And uh and about this uh uh with documentation, we uh a good rule is to say If you ask questions, make a wiki page, then ask your question and write the answer into the wiki page because you would be the best one to formulate something that's hard to grasp. It's like how

Speaker 5: how to explain how to ride a bicycle. You cannot explain it because uh it becomes silent knowledge and a lot of the things we do.

Speaker 2: This is exactly ex what we've been doing. Like we also have like a developer presentation monthly where we just present stuff to the entire dev team. And when someone builds something really cool, we just tell them like, okay, you're going to present it or you're going to write a a a wiki article or or both. Usually both. They um so we already encourage that. And I also encourage like people to I also want like the the less experienced developers to do like pull request reviews and all that. I want them to experience the whole flow because you cannot start early enough with learning how to like interact with each other. So um good one.

Speaker 1: And there was one more question. I think we have just a few minutes left.

Speaker 2: Everyone wants beer, I guess.

Speaker 6: How in the In the evolution of like remote working and on-site, off-site, hybrid, distributed teams, how have you found

Speaker 2: Oh my god. This is I I I got this question back when I first gave this talk and this is um this one is a bit mind blowing for me. Um, I love I have a problem. I love remote working, but for the work that I do, I want to be there in person. So I'm like, one of the two has got the gift Um I hated remote pair programming though you do have like these really cool plugins now in VS Code, in PyJama, whatever, that allows you to share a screen together, like actual uh program together, which is Super cool, although I still prefer the in-person version. And I think you just need to um Call on each other more. Like in the office you run into someone at the coffee machine and you're like, how are you doing? And if they're not really well

Speaker 2: then you'll sort of hear it or you can see that they're a bit sad or you can like happy and you can act to that. Remote you have to really just call in a couple times. Maybe even plan it just like hi and just call in, how are you doing? That sort of thing. And I think that I I'm not the type of person who likes that because it's an interruption of your work if you're like programming. So I found that really hard to be honest. But yeah, it's all about like finding what works with each other. There's no golden rule to this. But like for teaching people, I'm glad to be back in the office. It's not impossible, but it's not the best either

Speaker 1: That was possibly the last question. Is there anything you would have liked to be asked?

Speaker 2: No. Oh yeah, uh well um I am normally kind of dead at this time anyway, so I'm just happy that there's beer. But I would like to thank you. I am like super like it was already explained. I'm like super happy that we have these like C thingies. Um they're really cool. I love the venue I I think He did a marvelous job. It's really funny. I've been to a lot of meetups, conferences, but like starting off with the pronoun badges and uh code of conduct and all that N not everyone does that. So I'm like super happy that you all did that. That's like good preparation as well. And I love the venue. I I think you just did a marvelous lot job and

Speaker 1: We basically just got onboarded by other Django Khan people.

Speaker 2: Good strategy. And uh now the one thing I had promised to make this an example, uh emails like, oh god, she didn't forget. I would also love to have more women in IT. So like Try more and one of the reasons why that just happened look this is my dress ladies it has pockets Pockets are a way to a woman's heart. So I was like, I was telling Emil Yaki can just put this in my pocket. It's like, okay And I was like, Yeah, only a dude would say that because the women are like, Yeah pockets. Um and this is also one of the reasons why it's really cool if you have like more women but also like people of different colours and ethnicities and all that.

Speaker 2: Everyone can find someone they resonate with. So I'm so happy that there that there are women here, although I wish there were a bit more So be kind to your fellow developing ladies and non-binaries and whoever else, uh dear men. Well, that's that.

Speaker 1: Yes, one hundredth emoji. And thank you, uh Malaika, for being

Speaker 2: Beer?

Speaker 1: Sticking to the very last end almost because there is also lightning talks to be