Presented by WWCode London Speaker: Helen Scott (https://www.linkedin.com/in/helenjoscott) === Bio === Helen is a Java Developer Advocate who works with the development community to help them be awesome. Helen believes that content creation and communication are the best ways to engage with the community and help everyone learn together. Helen has worked at numerous software companies and has experienced the highs and lows of the software development cycle at all stages. Helen loves to learn new tools and technologies and share that journey of exploration.
=== Abstract === We learn to write code at university, bootcamp, or we teach ourselves. Then, after months/years, we launch ourselves at our development careers and also, inadvertently launch ourselves at a whole bunch of other skills, that we might not have even realised we needed. These skills are rarely taught on traditional routes, but it’s these skills, when combined with writing code, that make you a great developer.
~~~~~~~~~~~~~~~~~~~~~~~~~ About Women Who Code ~~~~~~~~~~~~~~~~~~~~~~~~~ Women Who Code is the largest and most active community of engineers dedicated to inspiring women to excel in technology careers. We envision a world where women are representative as technical executives, founders, VCs, board members, and software engineers. Our programs are designed to get you there.
Tweet Us https://twitter.com/wwcodelondon Email Us [masked] Follow Us https://www.facebook.com/wwcodelondon/
___ 💻 WWCode Digital Events: https://www.womenwhocode.com/events 🔎 Job Board: https://www.womenwhocode.com/jobs 💌 Make a Donation: https://www.womenwhocode.com/donate
Not today, Helen. Oh, yeah, definitely record it. Yes, I know it's being recorded. Thanks very much. Okay. I'm going to assume someone is going to shout at me if they can't currently see my screen. So just to brilliant. Thank you for the thumbs up. So a little bit of housekeeping. This is quite a fast paced talk. I also talk quickly, so it's going to be very fast paced. I'm going to be one off to the other. It is being recorded. I am going to be talking through a bunch of resources. You don't need to write them down. I'm going to give you a QR code and the link at the end. So please don't worry about writing them down. You don't need to spend your brain power doing that. Lovely to see some of you on camera. That makes a huge difference to me, especially presenting virtually because I can get to go people. Hello. Just like 18 months of pandemic. I don't see anyone anymore. So thank you for doing that. And thank you for taking your evening as well. I'm hoping to wrap up sort of ten to eight times questions. I know those of you in the UK might want to watch the great British Bake off, so I'm going to try and get you there for that. So welcome to my talk. Writing code is easy. Being a great developer is hard. So I am currently a Java developer advocate at JetBrains, and I graduated from 20 years ago, giving away my age with a very stereotypical computer science degree. We did Java even in Java 1.0. I left University. I went into the obvious job, a job programmer, and I failed and I failed really badly. I failed so badly, I quit my job. I went home to my mom. She didn't want me back. Love her daily. But fair enough, I left the country. I went to teach English abroad and I was convinced that I was an utter failure. And I came back and I picked myself up and I carved out a career in technical writing. And then more recently, I've come full circle and jumped back into or back into development from the point of view of a developer advocate because I realized I love creating content and Javas. Okay, actually, maybe I can do it. Maybe something's different and things are easier this time around. So what happened? What contributed to my failure back then? Probably drank too much. Probably didn't apply myself. But my hypothesis is that learning code is easier than some of the other stuff that we have to learn. So little bit of background. Where do we learn? We learn predominantly at University, quite academic, quite theoretical. Spread over three to four years. We might learn at a boot camp. So that's a mix of theory and a practical approach. And that is spread over one to three months. We might be self taught. And if you're on the call and you are self taught, my hat that I don't have. But if I did have would come off to you because huge, huge kudos. That's so hard. And wow, kind of blows my mind. To be obvious. To be honest with you, it's amazing that's arguably the most practical approach to go into coding. There's also apprenticeship. I've heard of a few of those, especially in the UK, so that's a quite up and coming past, and they have advantages and they have disadvantages. But what do you learn on each of these routes? Well, this is what I learned at University. This is my University. This is the syllabus for the three straight four years if you work in industry, and this is the 2021 intake, and it's not changed. And I'm not bashing my University in any way when I say this, but I want to point out that it's not changed. It is predominantly programming data structures and algorithms, machine learning, computation, technical writing, one module first semester, but it hasn't changed. It's very theoretical in its approach. And I thought, Well, okay, maybe that's just my University. So what about your University? Okay, similar. There are a few other topics coming up, computers, music, data science and robotics. That sounds fun, but fundamentally, they will teach you to write code. It's all centered around this programming thing. So I thought, Well, what about bootcamp? And then I started to see something quite interesting coming in. Obviously, there is still a huge emphasis on programming, but I started to see the more practical things modeling and building relational databases using the commandline interface, managing Git and GitHub. All my life. We're going to talk about that a little bit. I started to see this more practical topics coming in. Then I thought, okay, well, self taught. That's the final one that we looked at. This one is really hard because I don't know what this path looks like because it wasn't my path. So I took a guess based on some of the courses that I found online, of course, since the programming. But the really interesting thing started to come out thinking like a developer who knew that was a thing. We're going to talk about that as well. How to use your IDE life balance, time management. We all need some of that in our life while I do anyway. So that's where we learned and what we learned and it's this right. We learned to write code, whether it's Java code or JavaScript front end, whatever. We all learned to write code, and then we leave the institution if we went through a boot camp or University anyway, and then we go into a real job and that's when it gets weird. And it's really worth remembering from this point on that we are all self taught. Once we've left that structured environment, we go into our first job. We're all self taught. And what I want to do in this presentation is hopefully draw your attention to a lot of that, because I want to talk about the hard. I want to talk about the self taught skills. So these are the ones that I've learned in the last 20 years. I did not have them back in year 2000 and many of them I'm still definitely on the journey, too. I'm going to talk about for each skill, what it is, why it matters and give you some resources of where you can learn more. Like I said at the start, there will be a QR code and the link at the end. You do not need to write them all down if you don't want to. They are relevant to you, irrespective of your experience. So I'm going to start with the stuff that you're more likely to encounter earlier in your career and then progress through. Certainly, there's no such thing as a stereotypical development career, but progress through some of the harder skills. Now, if you're on the call and you've been coding for a while, you're probably going to recognize many of them. And I really hope that you take the opportunity to recognize them as the independent, self taught skills that they are. And you in turn, you can help somebody else who is fresh into the career. You can put some training in place for them. You cannot laugh at them when they screw up. Yet if you're relatively junior in your career or you're still in the learning phase, some of these may be new to you, and that's okay too. It's better to know what's in store. And it's also to recognize that your learning journey is only just beginning. So you can consider this kind of a whirlwind tour of the skills you're going to acquire in your past, your greatness. So going to get started on the skills now, right? First, I'm going to learn to use slides first, one Googling or professional plagiarism, as I call it. And this one is so weird. You go to University and you are taught that all your solutions must be elegant and unique, and you must reinvent all wheels. And you must not plagiarize that gets you thrown off the course, and then you go into your first real job and people look at you weirdly. If you don't use Google and you not just need to use Google, you need to be good at using Google. And if you're not sure whether or not you're good at using Google, ask a non tech savvy member of your family to find the opening times for a restaurant and you'll realize you're good. It's about knowing how to optimize your search, knowing how to pause the results. And it all comes down to how you can think like everybody else. Because if you're Googling something and you're not getting any hits, you're not Googling the right thing. So it comes down to how well you can relate to other people. So this is the first resource. This is the pattern this presentation will follow. It's going to be a skill and there's some resources. So this one is a blog from Joshua Hardwick and they keep this blog up to date with it every few months, which is really cool. And you might think a Google skill such as being able to find a page containing two words within a certain distance of each other is not that useful. But when you are down the development rabbit hole and you do not know which stack overflow answered, click being able to use Google like this is really useful. It's not just typing the search criteria in and hitting enter. So next skill reading code. This one also blows my mind. We are taught to write code, not taught how to read it, and you are taught to write Greenfield code, and this isn't reality. We go into our first job and I have no props. Today we have a roll of sticky tape and prayers and we have to apply that sticky tape. And in order to do that, we have to understand what's already there. You have to understand what code is there and how to edit it and change it. Now there's a bunch of stuff that can help here indentation design patterns, your IDE, but it's about recognizing the code does not tell a story. There's no start middle and end code is way more complicated than that, unless it's Hello World that maybe has a start middle and end. Lots of cool resources for you on this one. First one is for my colleague Trisha G. She has I meant to update that link. She has lots of information on her website, and she also makes the interesting observation that it's funny that computer language is the only language that one has to write before learning to read. Now there's probably some of you on the call who are learning a second 3rd or wow, even a fourth language. And many of you might be using something like Du Lingo. And when Duolingo is teaching you stuff, it teaches you how to read before it teaches you how to write. And when you get to that lesson, that's worth double XP and it's like you have to write now it's really hard. So again, it's about being able to read the code as well as write second resource on this one from A and M. Bazler, and they write about how you can improve your code reading skills with helpful strategies. So again, when you're new into your job and you're looking at a code base and it's really scary how you can actually change and develop that and some really helpful strategies. The observation that be able to write good code, you have to read good code. And again, you won't have read a lot of good code until you are probably quite senior in your career. In a lot of places, you probably read a lot of bad code. But next skill so my background is Java. I know you're not all Java people. Maybe there are some Java people on the call, but the point around this skill is it's a very fast paced environment. Technology moves insanely quickly, and no matter what technology you're working in, I expect you're nodding your head right now because that's just the environment that we work in. It could well fall into a remit put together a business case for why the business should upgrade or not. And again, for Java, it's not going to be enough to say performance and security. You need to know what that looks like. And this is another skill that we're not necessarily taught. We're not always taught to ask why. And then at some point you get through your career and go, I've realized I've been doing that, but I didn't even realize that I was. So again, it is a different skill. It is an independent skill that you have acquired. These resources are Java specific, but another one for my colleague Dalia Rabbi Sheesha. She's an expert in this field. So if you are a Java programmer and you're going Java 17, next long Term support release, have a look at the content from Dahlia on her website there. Likewise, Angie Jones has also covered this topic extensively. If you are upgrading from Java eight, it is not just for test automation engineers, either. There's loads of great takeaways and loads of very interesting and helpful examples, and he's a master at using examples that we can all identify with, and many of them are food based, which I'm a big fan of. Okay, next skill. So I'm going to go out on a limb and say there's at least a couple of people on the call who have gone to a technical interview and been asked to do some tasks that in no way relates to the actual job that they were subsequently employed or not employed to do. And this is fairly common in our industry. At some point you will probably be asked to do a technical interview, and you might be asked to do something that's a little bit unusual, or you might be asked to implement an algorithm that you would never do in your day to day coding life. However, there is lots of help at hand. And regardless of what you think about technical interviews, whether they're useful or not, it's useful to have the skills to get through them, because at some point you're probably going to find yourself in that situation. I'm kind of cool on Tricia Die again for this one because she makes some really interesting points that I think a lot of us come up against as we move through our career points. Like, how do we remain a programmer? How do we avoid getting promoted away from the technology and the code, which is what we love? So how do we move on from that? She also talks about the social skills that you need to be a good developer, and I think that's really important. I'm going to talk about some of those in a bit. What other skills do you need that aren't necessarily technical, because again, the University, the boot camp, not so much the self taught, but definitely University and the boot camp. They focus so heavily on being isolated and learning to code for the most part that perhaps some of those other skills aren't necessarily there from the get go. If technical interviews scare you, then Emma Boston has also got a book called Decoding the Technical Interview Process and a video to help you. So again, that's really interesting because these are people that have been through the process. They understand the process and they've created some cool content to help with it. Andy Jones as well. Gosh, I have three resources, this one. So Angie Jones, again, lots of articles, these ones for automation engineers. So if you are interested in that stuff, definitely check her content out because it is really very good. If you're on the call and you're perhaps in charge of technical interviews or you're aware they're not working at your company. And by not working, I mean, the company is not winning, and the candidates aren't winning, because sometimes that can be a sign that they're not working. Have a read of this blog. Again, it will be in the QR code at the end. But Sarah blogged about how they recognized that their technical interview process wasn't working and they changed it. They just threw it out and they said it's not working. I'm going to change it. I'm going to make it better. And it's a really interesting read. So if you've got power over the technology process and you think it might need overhauling, definitely have a read of that blog. Okay. Next one. I know there are more Ides than that, but at some point you have to choose your tools. You have to start making decisions. And this is again a little bit further on in the presentation, because perhaps when you first start out, you'll use whatever IDE your team are using. You'll use whatever libraries and frameworks appear first in the Google search, but you have to start making the decisions and managing your dependencies and net new code is pretty rare. As it turns out, modifying existing code is far more common, and we have to rely extensively on third party libraries and frameworks, and they need management. And again, this is a complete flip from certainly the University model, where we are given everything and told what to use, and then all of a sudden we're into the world and you get questions like, what tools would you like to use, what library should be used here? And it's not as easy as it first appears. There's a great blog from this one from Kyler Matthews, and some of this stuff is really obvious, I think, but it's only obvious because I've read it. So they come up with some really interesting points to help you to choose the right technology, the right library. Do you even like the API? What are your needs? Do you understand them? How popular is it? What's the testing status? So it's all about asking yourselves these questions, which again, is something that is quite foreign to us. When we first start out and we go into our first few jobs, okay, next skill being a team player. So your team are like your family. You do not get to choose them, and you're not the lone Wolf that you were at University either. Remember, you get thrown off the course for plagiarism at University and somebody else doing your work and then you go into your first job and you are expected to be a team player. And it's really hard. It's really hard. And I'm the first to admit it. I've worked very hard to make sure that I am the best version of myself. And there are days. I'm most definitely not the best version of myself, but you have to factor in your team weights. You have to work alongside them, and that takes effort. There is, of course, the saying, go somewhere quickly, go alone, go far. Go as a team. It's about communication. At the end of the day, a couple of resources for this one, the first one from office, and they talk about how technical skills are only part of the story and how teamwork really matters. So they came up with four things to help you to be a better team player so you can leave your ego at the threshold. You can embrace feedback. I do want to caveat that one unless it's toxic feedback, in which case, block it. You can be accountable and don't be a knowledge hoarder because all that happens is people come and pester you more because the knowledge isn't anywhere else. So that's a very interesting read. There's also this blog from Alison Deniscore, and it's ten ways to become a Better developer. The list includes things like creating an environment of psychological safety, encouraging everyone to participate equally amplifying unheard voices in the meetings. Repeat what they say. Give constructive actionable feedback. Don't criticize. Don't criticize people anyway. Hold yourself and other people accountable. The one I definitely really well, I like this whole list, but maintaining a growth mindset. Now, if you've not heard of a growth mindset before, there is a lady called Carol Dweck. Now she kind of pioneered this notion of the Grace mindset. And if you're not sure what it is, consider the following sentence. I can't code versus I can't code yet. And then when you stop worrying about what other people think about you and your coding skills or your lack of coding skills, and you funnel that effort into coding because you can't code yet magical things happen in your mind. So gross mindset, Carol Dweck, it's not on these sides. So have a read of that. Some great ideas for ten ways to become a better developer. Okay, next skill that you need, you have to be able to solve problems. And this comes with a certain mindset, and it doesn't always come naturally. It's kind of two approaches. We always have to keep things simple, especially to start with, because development is hard and complexity layers up quickly, and then there's the second aspect of it doesn't work. Not really sure why or the even weirder one. It works. Not really sure why. And we've probably all found ourselves in one or other of those camps pretty much daily as it can be when you're at the coal face. So it's about being a problem solver. Steve Jobs had a very interesting thing to say on this because he came out with a quote that everyone in the country should learn to program a computer because it teaches you to think. I'm not sure I'm completely in agreement with that sentence, but I do think it's an interesting point to raise because I do think there is a specific mindset that goes alongside being a developer. It's about mirroring your thought process and problem solving. So talking of problem solving the resource here. This is from Richard Reese and in their blog they came up with a four prong approach for how to solve a problem. So here's what human beings do when we're stuck. Number one, we try a solution. Number two, if it doesn't work, we try a solution. Number three, if it doesn't work, we try a solution. And for those of you in security effectively, we try and brute force it. We just keep hammering the door, trying something else, because that's how we operate. That's a very human thing to do. We just keep trying until the door falls down and it's not very effective. And it's incredibly frustrating. So what Richard said was, okay, break it into a framework first. Understand what's being asked. So really understand it the number of times that we just don't understand stuff is quite baffling. Number two, plan. Don't just dive straight in there. Plan how you're going to solve the problem? Because if you don't plan before you know it, you've forgotten to create a gift branch. You forgotten the steps you took to get to this point and you're lost. Number three, divide the problem up. So you've all heard saying, divide and conquer. And this is again, how we can solve problems instead of this brute force. And then number four, if that didn't work and you're stuck, you can debug it. You can reassess it. You can do more research. It's like a depth first approach versus breath. First, you can actually go down, go. Okay, that didn't work. Come back to the top of the tree, go down and try that. And it's a much more planned approach to a really buggy problem. So I really like that framework. Okay, time for an annoying gift this is the only one in the presentation and I'm going to pause it now. So writing tests. I didn't write a single test at University. I didn't write a single test. It was a long time ago. I hope things have changed, but maybe they have. Maybe they haven't. But regardless of what you think of test driven development or if you practice it, we are not always taught to write tests, and writing tests is a unique skill set. It is different to writing code. Yes, it is writing code, but it's especially a test driven development. Being able to switch your brain over to that approach is not simple, so there's plenty of Java world. There's lots of testing frameworks to help with this, but it's about understanding the value that tests can bring you, and that's just irrespective test driven. It's about having the confidence in your code and testing goes a really long way to achieving that. Okay, if test driven development is your cup of tea, the book by Kent Beck highly recommend. It's an excellent read. There's also this blog from Dave Chenny, and they make the observation of if you don't, someone will test your software, someone will do it. A user will do it. And if you worry about who will maintain your code after you're gone, write good tests, especially if you know that person. But they talk about who should perform that testing. What the proportion of manual testing is, what that testing means for your code and how that can give you confidence to change your code as well. Okay, next skill working with VCs. I have put Git there because I'm going to focus on Git just from its commonality point of view. Another self own. We didn't use version control at University, so our idea of version control was to zip up the code base and put it on your desktop. Windows 95. Things have changed an awful lot and you will frequently become fairly proficient in Git. Pretty quickly you'll be able to do the branching, the cloning, the committing a basic smash, a basic merge. But then something's going to go wrong and I guarantee it will go wrong. You will make a small mistake, and then you will compare that mistake by trying to fix the first mistake, or someone will have rebates when they should have merged and your local repo is completely out sync. Something will go wrong and you will have to phone the resident get expert on the team. Now where I at my previous role. This was a very talented gentleman called Paul, and in the end he did a Git lunch and learn on all the innovative ways that I had screwed up Git and it was really well attended and I thought it's not just me. Git is really hard. It's about Firstly, recognizing that Git is hard. I mean, if you're on the call and you don't think it's hard, just come find me afterwards. You can teach me, but it's about recognizing that being able to get yourself out of trouble is really helpful as well. Lots of great resources to get books from Katie Silon Miller called Oshitget or Dangit Git. Same book, one sweary one not. And I like this book because it goes from the problem point of I accidentally committed something to the wrong branch, or I need to undo a commit from like five commits ago. And that's me literally every other week because I always get carried away going I'm going to do this commit push. So I really like that. There's also an excellent blog from Peter Cottle. Sorry, it's not a blog. It is a website. You can actually learn the basics of Git branching. It's very visual and it's very helpful. So that's a good one as well. If you're on the call and you've heard Git and GitHub and you're not entirely sure what the difference is. Have a read of this blog. For those of you on the call who know the difference, you might think it's really obvious, but it's not if you're new and you're new to Git. So check out what is Git and GitHub or Git versus GitHub because it breaks it down right from the beginning. And it's really helpful because I've seen experienced developers get this wrong. So have a read of that if you're not sure. Okay, reviewing code again. This one is kind of crazy because we're never taught to do this at University. And can you imagine your lecturer saying, oh, can you just go and review the code that Katie wrote? Please see what you think. No one ever says that, and it's related to reading your code as well. So yes, code reviews can be toxic. That is a separate presentation, especially if this happens. It's very easy to say your method name doesn't follow convention. Or why have you used that loot construct when you could use this? But experience will tell you what to focus on and what to give feedback on. So resource. Here Angie Jones she created and I love this list. She created the Ten Commandments for code reviews, and it includes wonderful Nuggets of knowledge, like how not to take it personally, how to detach yourself from the code, how you can contribute your rationale to the code review without getting angry, how you can compromise and of course, treating others how you like to be treated. That's really important as well. So phenomenal list. If you're just starting to do code reviews, make sure you get support from your peers, they are difficult to do well. In my opinion, there's also some great resources from Dr. Mikayla Greeler. So they talk about what we've all heard either, or we've all experienced. Some of us, the team fear some teams fear because they've experienced that. The main drawback of code reviews is reduced code velocity, which means reduce productivity. And then if the code reviews are rubbish, nobody is winning. Literally nobody is winning. So she talks through how you can actually change that model, try different things and hopefully make code reviews more helpful and more useful for your team. Debugging I don't know what the equivalent is for other languages, but in Java we have a line of code called System Out printlin bracketsquote. Do we even get in this loop? And we use it for debugging all the time? And it's not very efficient and it's not very fast. And I don't know why I'm admitting to it on a recorded presentation, but it's true. People still do it because ideas were not around 20 years ago, debuggers were not around. And even though they are around now, we don't always make the time to learn them until we've got a problem. By which point, when we've got a problem in our code that needs the debugger, we're already stressed because we have a problem in our code. So debugging is a skill. It is a huge skill, and it is a skill that takes a really open mind to progress. Right. If you're on Twitter, please go check out Julia Evans. This one is in the QR code. At the end. I am a huge fan of her work, and when I was putting this presentation, she got together. It was like she knew because this tweet appeared on my timeline of if you've run into a bug and it felt impossible. What made it feel that way? So what Julie Evans does with the insight that she gathers from the community is creates designs and graphics to help us to understand why we might be struggling with something. So in the end she posted that question and the output was a bug might feel impossible because it's hard to reproduce. We might be missing something. Our mental model might be missing, something. We might not have the tools to inspect the program state that goes back to the debugger. One of our assumptions might be wrong. That happens, or the bug is just really freaking complicated, and it might be one or more of those things, but it's worth remembering that debugging is really hard. Okay, how many of you have walked into a room, sat down with a team and being asked to come up with an estimate for how long it's going to take? Nobody teaches you how to do that either. In fact, at University, you do the course, and then the lecturer says you have three weeks to do this assignment and you go, okay, two weeks in the pub, half a week at home, half a week to do the assignment, got it. And then you go into your job and you have to somehow learn how to calculate in a completely different way and say, up front, how long is something is going to take you? There's often business pressure to over commit, and that doesn't end well. Why is estimating so hard? This blog absolutely nails it to me. So imagine the scenario. There are six to ten people. You're going on a trip. It's going to last three to five days. Everybody eats different food. You need to buy some drinks, not too many. They're heavy. Don't forget the tea because we're British and we like tea. Get the best possible quality. Now, before you even go into the store, tell me how much that's going to cost. It's really difficult. There are some things you can do. You can break down the work. You can look at history, you can ask questions, you can take your degree of confidence into account. For example, I always underestimate how long something will take me. It's like a thing I do, and I know I do it and I still can't stop doing it. So I add extra time onto my estimates because I know that that is a behavior that I have. So consider that when you're doing estimations, there's also this an excellent blog of why software developers suck at estimating time and how to fix it. And this also comes up with four reasons why we're not very good at it. Parkinson's Law, that is, everything will take as long as you give it. So if you say it will take a week, it will take a week. Everyone is different. Thank goodness for that. Software development is a process. It's not just about writing the code. There's a whole ecosystem of other stuff that we have to do. If you're not sure what that ecosystem is, just look in your calendar and it takes time to get in the zone. Most of us don't just rock up to work. Whether that's the dining room table or an office and go right ready to code. It's hard and it's an art and it takes time. Okay, next resource deleting code, and we're never taught how to do that. Either we are taught to write it, put it on a pedestal and admire it. We're not taught that it shouldn't live forever, or the code has a life cycle. It just lives and we move on. But that's again, not the real world. Now, when I started looking for resources for this one, I came across a very interesting and a blog that could anger some people, I suppose. And it was this one and it's from Melissa McKen. And the author said, I'll delete your commented out code without reading it. And I'm not sorry. I was like, Whoa, don't delete my commented out code. That's not cool. But then I thought, Well, that's what version control is for. So if you're deleting your code, don't comment it out because it should be in version control. Even Hello world should be in version control, and you can just version control it, delete it and move on. The author does go on to talk about various ways you can approach this. You can catch it before it becomes comment junk. So it is controversial, but it could be worth checking for you if you are still thinking I'm going to carry on commenting out code because I'm not sure if it's used or not. Consider this story. It's a little bit old now. 2017 old long story short, they launched a new they updated the service the New York Stock Exchange. They did say manually. Three out of four deployments passed. One failed left the old version running. Sorry. The new version recycled an old flag that was no longer used. It had been repurposed to mean something different. They switched it on software Apocalypse. The old version of the code still had a dependency and it woke up zombie Software Apocalypse and it resulted in a loss of $10 million per minute until they could shut it down 45 minutes later. So please don't commentate your code. Please just delete it if you're not using it. Otherwise bad things happen. Okay, next skill right. What have I got? About five left. Okay, pair programming. So pair programming is really helpful, no matter what the technology is. Two heads is definitely better than one. Most of the time I say most of the time because it is mentally exhausting and incredibly rewarding. So find opportunities that allow you to pair program, turn up, give it your best shot. I do want to caveat this with. There are some days when my colleagues would say to me, what is your best day look like? Helen be like, not here. I don't want to be here today. So be aware of your own mental health and where you're at, especially in terms of you're going to comparing with somebody for an extended period of time. A couple of resources here for you. First one from Sound Fair talks about Mob programming. So if you're interested in what that is and how that works, you can check that one out. There's also a blog from Nat Bennett that I've Linked, which is about more on the burnout side of things where they talk about how he pair programmed for most days for years with hundreds of other engineers and makes the observation that it was one of the best things I've ever done for myself, socially and emotionally, and it produced some great software, but it also burned me out. So that's something too. That's quite an interesting week. It looks different from both angles as well. If you are not familiar with Pair and Mob programming and you don't know what they are, check out this guest post from Brigitte Bachelor and Nina Sen Sega on Martin Fowler's blogs. They talk about how to do it, the benefits and the challenges. Red, green, refactor talks. It will step you through it really nicely. So have a read of that one. If you're not sure what you think, you might want to try them out. Okay, next skill managing your meeting load. Wow, we've all been there, haven't we? We just look at our calendar and die slightly inside. Developers have a lot of meetings as a rule. And if you don't have a lot of meetings, that's great. But remember that they come with a heavy context in switching costs back when we're learning it's very asynchronous it's very just this and then this and then this that is not the real world. We have to learn to use our time wisely group meetings and check in with ourselves as well. So this matrix is going to be familiar to most of you. I expect the eyes and how a matrix if it's urgent and important, just do it. It's urgent, but not important. Can somebody else do it if it's not urgent, but it is important, plan it. And if it's not urgent or important, what is even doing on your plate? And it's worth going through this every now and again with your workload, especially if you're feeling overwhelmed. You might be surprised at what you can get rid of. Also, a great blog from Dan lines on too many meetings. When he spoke to software engineers, he actually discovered that it wasn't that we hated meetings we hated inefficiency poorly planned meetings, poorly executed meetings, missing deadlines or not getting enough time to do our coding. So that's what we really don't like. So there's lots of tips in that blog for how to actually get some of your time back, including just looking at your calendar and going, how many hours a week do I spend in meetings? Because that statistic might surprise you. And then you should take that into account when you're doing your estimations as well. Okay, next switching contexts. So this can be planned, like estimates, changing tasks halfway through the sprint. Or it can be unplanned, like curve balls in life, and you will get them. You will get that phone call that nobody ever wants to get. You will always have those moments where you have to drop work and go, and there is a cost of it that you have to factor in. Switching context is really difficult. There's also something called Attention Residue, which Miami Nishimotovo talks about in their blog here, and it's about Attention residue is where you have a meeting at 09:00, 10:00, 11:00 01:00. And then at 02:00, you realize you're still thinking about the meeting that finished at 10:00. And this can have a really serious knock on effect for your engagement and your satisfaction. And it leaves you exhausted as well. It's not healthy for you talking of exhausted. Please learn this word. Please learn this word. I know you don't want to annoy the boss or let anybody down, but burnout is real. You have to set boundaries and you have to set your priorities. And I can't do a presentation without Grumpy cap some great blogs here. First one from Hussein Pollock, Europe. And this blew my mind when I first read it because they said, perhaps you can say no to writing that code. And I was like, developers don't say no to writing code. What is that about? But then they make the observation that your code has to be read and understood has to be tested and debugged. It's going to increase defects in your software. It's going to increase bugs. And I was like you're calling my code buggy. But of course code is buggy. That's the nature of code. So interesting idea. Maybe you can say no. There's also this one from the developer workload. So if you are not comfortable saying no, and it weirds you out have a read of this because it can be a really practical approach, how you can examine your caseload, how you can say no, how you can be respectful and honest and potentially offer up an alternative as well. Okay, we are coming towards the end. So being aware of your mental health, I've already mentioned it's a very fast moving industry. Any job can take a detrimental toll on your mental health. It is the importance of mindfulness, of rest and having those around you, especially now the last 18 months. It's really important. Many of us have learned the hard way by burning out. It's not what anybody wants to be. I also want to point out that you don't need a side project or a hustle to be a great developer. You do not need code on your weekends if you want to. Great, but you do not need to. Some great blogs here. First one from Lena Kaza and Vova Rock. They talk about how or four things you can do to improve your mental health. So the difference between that focus 40 minutes and unfocused. We all think we're not working if we're taking a shower, but your brain is working. How many good ideas have you had in the shower? Don't forget to work out teamwork. Is everything get oxytocin hormone rate in childbirth, not just childbirth really does do wonders for your mental health. So have a read of that because there's some really helpful tips in there. There's also these articles from Brian Robinson and they really drove the point home for me. I'm pretty sure this wasn't just within the it, but I expect the figures are even higher in it. 48% have experienced burnout, 61% elevated stress, 32% have felt lonely. Those are crazy, crazy figures. So a couple of blogs here the second one I do want to draw your attention to, especially if you are working for a company that is talking about hybrid approach going back to the office kind of part time and you're not quite sure where their loyalties lie. The second blog ten red flags that psychological safety is lacking in your workplace. Have a read of that because if you're not quite sure if your company is fully invested in a remote working for the long term, you might have some helpful information that you could take from that right. Having a great work life balance. I don't need to say much about this one other than it is insanely important. The most important family friends, hobbies, they are all much, much needed blog here from ANU padier. They talk about prioritizing your time following a strict routine which I'm terrible at. Cut out the things which are not important. Be aware of. Burnout don't be a perfectionist. It is the enemy of getting anything done. Learn to say no and enjoy yourself because if you don't enjoy yourself, what's the point? The next one? This is an article from Karina and this is about balancing work life as a developer. There is a link in that blog to a Ted video which I'm not going to ruin it for you because I think you should go watch it, but it's about work life balance and it's about how the gentleman picture in the video there made one small change to his daily schedule after a phone call from his wife and the impact that that had on his kid. It really is. I'm not crying. You're crying moment. So have a look at that. So to summarize, writing code is the easy part. Writing code. Learning to write code is not easy, but it is the easy part. Being a great developer is hard. It's not just about writing code. It's all the other stuff that you learn on the job. So what do you do now? Well, this is your call to action slide that the QR code is coming. The link I will paste, so you don't need to scan the QR code. But this is the part where I really want you to give yourself a huge Pat on the back for being generally rather awesome. Just realize how far you've come realize how many of these skills you've learned. And this is also the part where you go and you help somebody else who is new to the industry. They might not have these skills. I didn't. They might not even know that they need them. I didn't. And you can show them the way. So that is the QR code. I'm going to leave that on screen for a mob. I will also paste the link into the chat as well, and I am definitely out of time. That was very fast. So thank you very much. I'm going to stop sharing that. Wow. Thank you so much. That was amazing to me. That's very fast. I have a new job right now and wow, right now I like kitchen trying to swim and everything is new and yeah, I understand a lot of things here, so thank you. Thank you, sir. Scott, I didn't read the chat as I was going along. Apologies scrolling back to the chat, but yeah, the link I've put in the chat that contains all the resources. If you find any errors. You have a question. Hi, Helen. Thank you so much for the amazing talk. I'd love to know if any of these tips you suggested are specifically aimed at women who code, or if there's any other tips that you suggest to overcome these specific barriers that we have in the workplace of feeling, maybe personally feeling like equal or feeling supported. That's a great question. So the presentation originally was not focused specifically at women or for women in the workplace. It was more focused on just general development. I think in terms, what would I say for women specifically? I think I would just say, be strong, know your work, know that you're good and just as good as the next person, and try to make sure that you are not trying to make sure, make sure you are in an environment where you can thrive. There is definitely an element of that that I wasn't in that environment, and some of that was definitely naivety on my part. So I know I would do things differently if I had my time over and I'd be a lot less harsh on myself. It is only in my more recent years that I've kind of come back to it and gone. Okay. Well, yeah, coding is really difficult, and of course, my University shouldn't have taught this stuff. I'm not saying University should teach that stuff, but it's about recognizing that I can do it. And it's about who you surround yourself with. Surround yourself with people who are going to lift you up. Surround yourself with people who are going to champion you. Surround yourself with people who believe in you. There's probably a whole other talk in terms of workplaces that potentially aren't that. But yes, that's what I would say. Thank you. Choose your friends and your colleagues carefully. I think I have a question about their programming. We don't have it as a tradition on my job right now. So do you have any advice or tips how to start introducing technique if the team didn't do it? Yes. I love pair programming. I would say it's as simple as can we try a little bit of pair programming and just pick a colleague that you think you're going to learn from and hopefully will be amenable to it. Start small. So just be like an hour. Another advantage of pair programming is if you're using the same tools, you're using the same IDE. You can see everybody's shortcuts, like keyboard shortcuts, which is super helpful. I'm biased, obviously working for JetBrains, but just ask, just start small. But then I would also say, be aware of yourself because I don't know about people on the call, but I'm not the best version of myself for 30 days every month, some days I'm just like, I'm tired. I've had a phone call that's throwing me off. I'm not feeling very well. So be aware of what's going on with you, because if you're going to put yourself in close, maybe not close physical proximity, given the pandemic, but certainly close mental proximity with another person, then that's stressful. So make sure you're in the right place for that, but just ask. Just try to get started and you compare on anything. By the way, it doesn't need to be code. You compare on writing documentation. You compare on writing tests. You compare on debugging. Debugging is a great one to pair on because we all go at things from a specific mindset, and we don't always it's very difficult to kind of bring ourselves up to a level of going. Okay. Well, what could this bug be? It goes back to how to debug. We all approach problems differently. Well, thank you. Good luck with it. Thank you very much. Let me just share that QR code. That link I've put in the QR code goes to the same place. So either or welcome. Don't think I've ever given that. Talk back quickly. Thank you. If anybody does have any questions and they think of them afterwards, or your question hasn't fully formed, you can drop me a note on Twitter or LinkedIn. Preferably Twitter. I'm more there than anywhere. My DMs are open, so I'd love to hear from you. And, yeah, thank you again for giving me some of your time. This evening is much appreciated or evening for me, wherever in the world. You're. Well, thank you so much. I think we can. So.