Writing a book: Venturing into other fields in tech as a dev

🎤 About the talk
đź’ˇ Talk highlights

Trailer for the talk

Here's a sneak peek of the talk: Nadia will share how working as a developer help her venture into other fields in tech.

Want to see the whole talk?Watch the full recording here

About the talk

In this presentation, Nadia will talk about how working as a software engineer equipped her with the skills to plan, write, and publish a book to help aspiring developers learn to program. We’ll use Nadia’s writing experience as a springboard to talk about how developers can venture into other areas related to tech.

By the end of the talk, you will learn the best ways to improve your craft as a developer. Hopefully, you will also be inspired to step out of your professional comfort zone and try something new.

This talk will cover

  • Why you should learn from the best
  • How embracing challenges makes you a better programmer
  • Why it’s important to show your work early

We’ll use Zoom Webinar to hold and record the event. Register to the event to access recordings afterwards.

Career Growth

About the speaker

Nadia Zhuk

Nadia is a self-taught engineer working at Intercom. She is the author of “Crossing the Rubycon”. She volunteers at Code Your Future and Women Who Code. Her goal is to help people from non-STEM backgrounds enter tech.

Transcript

Elliott: All right. Welcome to everyone who is currently joining. We'll kick off in about two minutes. So please enjoy zoom webinar. If you are new, down below, there is a chat function. Please use that it is completely normal that you cannot see each other in zoom webinar, but rest assured. People are coming in.

Elliott: So what I would love to know while we're waiting for everyone to turn up is where in the world you live, because that's always fascinating. And secondly, if your transitioned away from another job into the dev world, what were you before you became a dev? I used the start of your journey and you were a cobbler before. I'd love to know that as well.

Elliott: Just give it to nothing minutes. Singapore, Las Vegas. Yep. We always get a very worldly crowd here.

Elliott: Berlin, we've got to get every continent. That's always my goal. If we can get every bull catheter, now that's a story. Just give it another 20 seconds people to turn up. Should be good.

Elliott: All right. Let's, let's kick off. Welcome everybody to what should be a pretty awesome event? Obviously this is Nadia hanging out on the side of the screen with me. We will go over a few things before I introduce it. Absolutely. As I said before, it is completely normal that you cannot see each other in zoom webinar, but there are quite a few of you and as we've just established and chat from all over the world, sometimes you'll see it defaults to host some panelists. Please change it over to everyone. If you do want to chat and network, that's always something that you can do. So at this point, I think we can get started with the main event.

Elliott: Welcome Nadia, how are you today?

Nadia: I'm doing fine. Thank you so much.

Elliott: Excellent. So Nadia is a self-taught full stack software engineer, a book author, and a career mentor. Before teaching herself code, she had worked as a translator and journalist. Nadia is passionate about bringing more people from non-stem backgrounds into tech and she tries to explore this through blogging, public speaking, and volunteering at code your future and women who code. Outside work, Nadia enjoys studying world war two history, reading and exploring London, which I haven't been to London about 10 years. So I'm very, very jealous with that.

Elliott: Yeah, with that, I'll hand it over to you Nadia.

Nadia: Yeah, thank you so much for a lovely introduction. Hello everyone and welcome to my talk. I'm glad to see many people join today and I'm glad that you chose to spend part of your monday or evening together. I hope my talk will be useful and inspiring for you.

Nadia: Some words of housekeeping for me. I really do want to encourage you to ask your questions in the Q and a box below. We will have dedicated time for questions at the end of my talk. So please do ask away and I'll be glad to answer any questions. And also if you hear something that resonated with you during the talk please feel free to comment in the chat and kind of, it'll be nice if we can get some conversations going.

Nadia: You will receive a recording of this talk afterwards within one week of this event. So if you hear something that you would like to revisit, the part where you will get a recording of it, the next slide is actually my introduction, but I think that Elliott did a wonderful introduction of me, and this is more or less, repeats of what he said.

Nadia: I think I can go to the next one, which is the one about fun facts about me. So there are things that you might want to know about me. I'm originally from Belarus, but I've already lived in four plus countries. I'm currently based in London and it will be nice for me to meet people from, for coffee in London. So if you're based in London, feel free to connect.

Nadia: The second thing is that I am a huge book nerd and on average, I read anywhere from six to two-five books a year. Unfortunately I've been reading much less recently. But in 2020, I did a crazy challenge of reading a hundred books a year. So again, if you want to talk about books, feel free to reach out to me.

Nadia: And the third fact is perhaps the most relevant for today's conversation. Yeah, a year and a half ago, I wrote and published my own book called “Crossing the Rubycon,” which is a book where I tell the story of how I taught myself to code within, and got an engineering job within nine months. And before I did that, I used to be a journalist and an editor.

Nadia: So this book is actually a personal story of my life and also how to guide, of how anyone who wants to become a programmer can repeat my journey and actually do the same.

Nadia: So today I'm going to be talking about how working as a programmer actually helped me write a book. In this talk. I'd like to explain how I transferred the lessons and the skills that I learned while working as an engineer to the writing project.

Nadia: My hope is that while listening to this talk, you will start thinking about the skills that you already held and how those skills can be transferred to a completely unexpected field. I hope that this talk will inspire you to view yourself in a fresh light and kind of that's my, that's my hope for today.

Nadia: So I am, I'm a self-taught engineer. I never had any computer science education in school or in college. And I've always been pretty awkward with tech. I think some of this awkwardness still remains with me. So I was one of those people who you perhaps met, people who are afraid of changing a setting on their phone or setting on their computer because they're afraid of breaking the whole machine.

Nadia: So I was pretty awkward and, you know, pretty annoyed when it comes to tech. I remember at one point, quite a few years ago actually tried to learn HTML because I was told that HTML is such a great skill to have, and you should totally learn it. I tried to, and very quickly I gave up because it was just too hard for me.

Nadia: So when it comes to coding, I was never the brightest person, you know, when it comes to code new skills. So I didn't have any special gift or skill to learn coding. Yet, I still managed to teach myself to code from zero, to, to being paid as a programmer in just nine months. It was pretty incredible that somebody was willing to pay me money at that point, because my skills were still so basic.

Nadia: I was happy of course, but also I wasn't delusional and I realized full well that my skills were just not great. And, I knew that I was very far from being a good, or even a software engineer. Right. So I knew that I needed to become better and to become better I understood that I needed to learn from the best.

Nadia: So throughout my career, I've always tried to optimize for learning. And, whenever I felt that I wasn't learning as much as I could have, I would be trying to look for new opportunities. So that's how I came. This mindset kind of led me to work at Zendesk, which was my previous job. Applying to that company was really, really scary. I remember. before my first interview, I Googled the interviewer who would be doing the technical interviews with me. And I was so intimidated because the guy was clearly brilliant. He was given technical talks about Ruby, and I was very intimidated to be coding with him. But then when I got the job, I realized that the people who surrounded me, so many of them had master's degree in computer science from top, polished universities.

Nadia: And, you can imagine that it felt very intimidating to work with them. But still I realized that working with them was probably the only way for me to learn and to grow as an engineer. So, I was learning from the best developers, but also I realized that I needed not only to work with brilliant people, I need also to read books by brilliant people who, you know, I wasn't able to really, to work with, but still I could learn from. So the books written by some of the people that you currently see on your screen, many of them were way beyond my intellectual abilities and coding knowledge at that point.

Nadia: Those books were crucial for me because they managed to bring my skills to a much higher level. And also if you are in Ruby, Ruby on rails community, as I am, probably you will recognize some of the faces. And I'm very grateful to the people, to those people, to their brilliant books, for helping me improve my skills and take them to a whole new level.

Nadia: So when writing my book, I used the exact same approach that I did when learning to code. So most of the first draft of my book, the first draft of crossing the Rubycon was really a dumpster fire when they realized that or more accurately, the one, my editor kind of told me that I was very discouraged because clearly I couldn't fry it. And I couldn't tell a story. It was sad because I've already spent so much time on it, but because I spent so much time on it, I couldn't really give up and I had to, you know, do something. I had to fix it. I had to learn.

Nadia: So I did the same thing I've always done. I try to learn from the best. So the first thing that I did was I turned to textbooks on writing. There are a bunch of books were great writers. Talk about the skill of writing. And I read one byRay Bradbury, another one by Stephen King. So I read everything that the greatest writers had to say about the art and the science of writing.

Nadia: And second, I started learning from the best fiction writers, because as I said, it was clear from my book that I couldn't really tell a story. And I think that classical writers are experts at telling stories. So I felt that if I feel every single free moment of my life, with examples of the best writing ever. This would kind of lift me up from my competence in a way. So the books by Charles Dickens, Oscar Wilde, Ernest Hemingway and others helped me get a better understanding of the storytelling, and also they help me improve my grasp of the English language.

Nadia: So I try to emulate the writers and copy their writing styles. It sounds naive, but also this trick worked. English speakers who read my book, they said that the book had very few grammatical errors and they assumed that this book was edited by a native speaker. My editor was also not a native speaker. So the trick worked.

Nadia: I think that trick works every time. And it doesn't matter what skill you're learning. You should always try to learn from the best. So that was lesson one.

Nadia: Lesson two is embracing the struggle.This is the lesson that I learned fairly late in my coding journey. And I wish I knew this lesson from the outset. So when I started coding, you can imagine, as a self-taught engineer, as a former editor, I struggled a lot. I struggled with basically everything. Most of the time, what my colleagues said didn't make much sense to me at all. So I had to Google the most basic words that they used for things like docker, shell compiler. I had to understand what those words mean first before I could start doing the actual work.

Nadia: And when I tried to do the work, I unfortunately couldn't because I had no idea what code I needed to write, where this code was supposed to leave, and when I even knew what to do, the code never worked.

Nadia: I struggled every step of the way with this,it didn't feel good at all. But what I didn't realize back then is that this was exactly the way it was supposed to feel like. So the struggle that I'm going, what's going through, and maybe you're going through the same struggle. It's the crucial part of learning, trying to solve a problem before being shown the solution helps you memorize the new material.

Nadia: So if you're struggling, you should see this as something that is helping you learn and not, not as something that you should avoid at all costs.

Nadia: So, you can imagine, by the time I was starting to write my book, I'd spent years of kind of struggling in the basement, embracing the struggle with programming. I think this helped me, make it much easier for me to accept and cope with the fact that writing the book was unbelievably difficult. So it definitely was one of the hardest things that I've ever had to do on a lot of many levels.

Nadia: So writing a book is intellectually very difficult. It is also a very lonely occupation where you spent hours and hours inside your own head and then kind of following your heart on the page where everything looks and feels completely different from the way it looked in your head. And then you have to go back over the same sentence over and over and over until you feel that she's all the way, every sentence is fake and that was not true. And you can see your own thoughts on the page.

Nadia: However, the struggle, it didn't mean that, you know, I was like a bad person, a little bit better. You can see here, Ray Bradbury, you know, pretty brilliant guy saying that right in this. Just the dreadful exercise and the terrible occupation. And I do love this quote. So with writing us with programming, struggling is good. and with anything hard actually struggling is good. So it's hard for everybody even for, if you meet an experienced programmer who says that coding was very easy for them always, it's very likely that they simply have forgotten what it was when they were starting.That's tip number two.

Nadia: Another lesson is about talking. It's a practical lesson that I learned while working as an engineer. And I think that many engineers who are listening to this will relate. It's very important to you. Talk through a problem, talking to someone or maybe just thinking out loud. I mean, just talking to yourself, it always helps make the issue as complex and brings clarity to it. And that's not surprising if you think about it, we think by talking and talking helps us organize our thinking.

Nadia: So programmers listen to this and they know that we tend to use rubber ducks for this, which can be like a metaphor or it can be like an actual rubber duck. An object that you can use to explain the problem to, and when you start explaining it, the problem and amazing thing often happens. When you just start doing this, this is enough to sometimes on walk you, or maybe it's enough to call someone and tell them the problem to be able to solve the problem.

Nadia: And this was another skill that was just perfectly transferable to writing. And then I'm sure to other spheres of life as well.

Nadia: So whenever I felt blocked in my writing, I often use the speaking technique. So when I couldn't formulate an idea on page, I would often start speaking and trying to express the idea verbally. And it often happened that I already knew how to formulate it. I just needed to write down what I just said, but also sometimes the opposite thing would happen when I started talking about something. I would see that actually, I didn't actually have anything to say. It was just. It was just nothing. And I think that in writing it's much easier to hide the absence of substance. I think when, when you are talking and you are not actually saying it, it's much more obvious than in writing.

Nadia: So a very good tip.I think in many spheres is the, is that if you are stuck, you should start talking.

Nadia: So the one about the tiniest of steps, I think is interesting. And I'm not sure how many of you can relate, but, I've often felt that I didn't, I wasn't developing my engineering skills as quickly as I should be. And this is something that think that many software engineers, self taught struggle with because you are always feeling like an imposter. You are always feeling like you're not good enough. You're not learning fast enough. Although like, there is no speed that you need to have, or like there are, there are no metrics basically, but you still feel this way.

Nadia: And for me, what was helpful was to go through retrospect of my own skill. So I would take a look at some of my recent business of code and compare it to like the awful code that I wrote a couple of years ago. And then it would be very easy for me to see how much of a progress I actually made.

Nadia: So, Sometimes I'm asked by people, whether there's any secret for me to go from going to not being able to code at all to being a successful engineer at companies like Zendesk and Intercom, sadly, or maybe not, not sadly, there is no secret to that. It was just me taking the consistent small steps toward improvement. So it took me a lot of grit and a lot of patience. but overall it just came down to forcing myself to do at least something contributing to my learning, maybe not even everyday, but like at least a few times.

Nadia: So, if you're working on the skill right now, and you're taking steps towards improvement, they can be really, really small. However, they might be able tiny that you don't even notice them, right? It seems like nothing is happening. You're not getting any better. However, even the tiniest steps, they do adapt over time.

Nadia: So if you're working on this skill, you will get better at this skill even if it doesn't feel this way on a day to day. And I think that this is the catch that many people miss, because it's very hard to feel that you're making progress if you're not seeing it, right. So I learned this lesson while being a programmer and I had to remind myself of this, of this truth when I was working on the book, because with my book, I actually had to create four drafts of the book, meaning that I had to rewrite like you know, big chunks of the book four times. And I can imagine that this sounds like a very massive undertaking, now you have to rewrite the whole book, but to be honest, on a day-to-day basis, it didn't feel this way at all.

Nadia: So it felt like, taking a go with the book sentence by sentence and improving whatever I could, I could on that. So sometimes I would just have time to rewrite one paragraph. Right. And then it didn't feel like I achieved much on the date. However, those small improvements added up and allowed me to improve the quality of the book in a major way.

Nadia: So if you now take a look at the first draft of my book and like, nobody can except for my editor and please don't do it. And you compare it to the last drop of my book. It would be difficult to believe that it was written by the same person. But it was the same person is just that eight, eight months were put into this work, and a lot of incremental improvements or of tiny, tiny steps. So if you apply this principle to anything, you will get better. You should just trust the process.

Nadia: So when it comes to sharing my work early, I personally don't like it. I know if you like it or not. I like to just thinks really well. I like to like, ideally there should be perfect before I put them outside into the world. And, while working as an engineer, I thought that my code actually needs to look perfect before I showed it to anyone.

Nadia: So I would work and work and work on this code. And then. even if I felt that something was strange or off about it. So then eventually I would show the code to someone and it would turn out that they would say, now, what, like, what is this, why did you build this? We already had a library for this. Or like, why, why did you implement it this way? There is a way that it's 10 times easier. So, you know, if only I showed my work earlier, I could have saved all this time and all of this effort

Nadia: Speed is very important when you're working as an engineer, maybe like not for you, but for the business. So for the business, isn't the business side of things is very interested in shipping things fast. So, this is one consideration why this is important.

Nadia: And with my book, I think that I kind of use this lesson a little bit, but still I think that I didn't go far enough. So the first draft actually took me two months and when I shared it with my editor, it kind of came up that the book had to be a reason completely because the book had a very big problem, it didn't feel like a story and it didn't feel like a book. It felt like a very, very long search engine optimized blog posts. And you know, those blog posts are great and they have a place to be, but also this was a book, so it was supposed to feel and read like a book, like a novel. So I had to write the book.

Nadia: And I kind of regretted that I didn't ask for feedback earlier. So, I could have saved I think at least a month or maybe a few weeks of work. So whenever you're working on something on any project, basically you should try to show your work to the world as early as possible. If you feel that you are a hundred percent comfortable sharing it, you have probably waited just too long.

Nadia: I like this lesson. I think it's one of the most important ones for me from all this, from the whole experience. I've worked as an engineer at both Zendesk and Intercom. Big companies with very high professional standards and very high engineering standards. So for me, it has been such a great joy to work alongside professionals and professionals in every field.

Nadia: I've learned a lot about from them about being a professional. And I think that I kind of learned what it means to be a pro when it comes to being a software engineer. With my book though, I always kind of from the beginning, I saw it as a side project and because it was a side project. Right. So in the first month I think of writing the book, I worked on it only during the weekends when it felt, you know, fully rested and relaxed. I didn't feel like I was totally invested in the book and I couldn't force myself to work on it while I was tired or maybe not in the mood for it.

Nadia: But I think that around three months into it, I realized that if I kept doing this and if I kept working with the same speed with the same level of commitment, I would just never finish the book on time. It would simply take me too long and I would lose focus and motivation.

Nadia: So I realized that I had to do something different and I had to start reading my book with the same respect that I gave to my full-time job. So it was the only way for me to finish it on time. So I had to go all in. This is when I came across the book by Steven Pressfield and the book is called “Turning Pro” and that's kind of the book that changed my life in the way, but, more concurrently, it helped me finish the book and publish it and kind of finish the project.

Nadia: So the idea of the book is that whenever you're working on this side project is that you should treat your side project as with the same seriousness that you devote your full time work. Right? if you have a job, you show up there, even if you don't feel like it, and you try to do your best, even if you are not very interested in the task at hand. Because with every project, wherever it is, even if it's very creative, there will be times that you just need to do something really boring and something that you don't feel like doing, but you kind of have to do it. If you are treating this as your, professionally as a job.

Nadia: So I never got to the point where I wrote every day, like some full-time writers do, so a lot of writers, they actually write every day before work and then they go to work. I never got to this schedule, but I managed to introduce a strict schedule for weekends, at least. So every Saturday and every Sunday I would sit down to work on the book and I would only leave the desk when I couldn't produce any more writing for the this day.

Nadia: So I also wrote a menu of their weekdays, and I remember two vacations, two separate vacations, and they spent all of this time just working on the book. So if you are working on a side project or maybe you're considering working on it and you suddenly get to the place where you feel like you are in the rut and the project is not going anywhere, it might help you to take a step back and kind of re-examine whether you are treating your project with the same seriousness and the same respect that you grant your day job.

Nadia: So these were some of the lessons that I learned while working as a programmer and the lessons that were very easy to apply to writing and publishing a book. If you yourself want to work on a creative project, or maybe you want to start your own business, or you want to take another role at work. But you feel that you can not start because you don't have the skills you're not qualified. I do suggest that you make a list of the most important skills that you already have and kind of the lessons that you've learned while working in some other fields, perhaps, and think of how you can transfer them to a different task or a different role or a different project. And you can treat it as a sort of like fun homework that you can do afterwards.

Nadia: And I think that it's, it's very likely that you will discover that the previous jobs that you've had and maybe the jobs that you consider it were very like totally useless. And didn't teach you anything. Those jobs actually taught you some valuable and highly transferable skills that you can use to succeed in something else.

Nadia: And the last slide is about an inspiring quote from Jack London, about going up to your inspiration, basically, not just dreaming about something, not just thinking about starting the project, but kind of trying to act and start doing it before you have an inspiration to do that, and just basically not to waste time.

Nadia: That's it from my side. Thank you so much for listening. It would mean a lot to me if you check out my book. The link to the book is also in the event page and you can find it on Amazon, on Gumroad. I truly put my heart and soul into the book.

Nadia: And that's it. Now we have 15 minutes for Q & A.

Elliott: If my microphone work. That's a lot easier. Thank you so much, Nadia. I personally am a master of having writer’s block. So I think I got excited and took a few notes in that I can apply in my life. Awesome. As Nadia said, yes, Q & A. Please. If you can put it in the Q & A button below at the bottom of your screen, much easier to track that then trying to find it in chat because sometimes it can get very busy.

Elliott: Let's just take a look here. From anonymous, what software did you use for drafting and editing your book?

Nadia: Yeah, thanks for the question. I'm sure I don't have any fancy software to write the book. I used plain old, old Google, Google docs to write the book. I think that it started with just one doc and then as it expanded, I saw that it's not really manageable. And I divided the, I think at some point we divided the chapters into different docs, but it was pretty chaotic, consider I had like a good structure or anything. And then all the editing, all the work was happening in, in the Google doc. My editor was leaving notes and I was going to fix it and address it in the comments. When it comes to later, I was using a tool called pro writing aid tool. I think it's called. So it's a very good tool for checking your writing for a couple of things. So, I think the easiest way is to check it for grammatical errors, but then it also checks your writing for whether it's coherent, whether it's redundant, whether you can edit it in any way. So it kind of checks your writing for clarity, and it kind of gives a score to your writing and assesses whether, you know, whether this is too complex, whether it can make it simpler and more readable.

Nadia: So I really like that one. And that's, that's kind of it. No, no fancy programs. And then the type setting and kind of the design of the book itself was done in, Indesign, if I'm not mistaken.

Elliott: Okay. Very good. Another question here, which I think was From job, what was the biggest challenge during the whole process? Was that the number one thing?

**Nadia:**The biggest challenge. I think the biggest challenge was to just keep going basically, because I think that if you are, if you keep going, then you can basically solve most of the problems that you face. And this is true with everything in life. If you have a business and it's not taking off, if you keep going. And all the chances that they will succeed are much higher than if, you know, if you abandon it and for sure it wouldn’t succeed. So I think keeping going, and kind of finding the motivation for me to finish the book and kind of thinking of why I started the project in the first place. So for me, the goal initially was that I didn't see any resources for any books actually written for people like me who came from completely non-technical backgrounds and taught themselves to code at a somewhat later age, because I started coding when I was 25. I kind of wanted to write a book that would represent people like me, and that would serve as a friend, like a friend or a tutor for them.

Nadia: So. Well, I was often thinking about this, when I was stuck. Having support from my editor of course also meant a lot in the process, but yeah, just thinking of why I'm doing it and got to find a new ways to motivate myself, taking breaks, to do that. That was, I think that was the biggest challenge.

Nadia: But also I would say the taking feedback was really hard for me, especially negative feedback. Because if you spend months writing something and then you receive feedback, that actually, now this, this is awful and you have to kind of rewrite the whole thing. It's not easy to take. So, and you know, I didn't handle all of this back, beautifully, but I think I learned a little bit from it. So yeah, I think if you have somebody who's given you a feel like good constructive feedback that comes from a good place. I think it's important to be grateful and not resentful.

Elliott: Awesome. Well, that's a perfect segue to the next question, which was, when did you first approach your editor in the process?

Nadia: Yeah, I think as I shared during the talk, I shared my first draft. I think it was like two months into the process. As I said, I should have done it earlier because I spent like a little bit too much time kind of editing the language itself, but the book had problems with structure. So I think that if you are thinking of writing a book or working with an editor, I think it's very important to be sure that you both agree on the structure of the book, on what the chapters would be and like what the story would be and then you can kind of fill in the gaps between, you know, between all of those things, but not spend too much time. polishing your writing if the whole book doesn't feel right. And it kind of falls apart. So, yeah, for me, I think it was a little bit, like I shared that first draft a little bit too late and I should have done it sooner.

Elliott: Alright. Probably got time for one more question and then I'll tell you all how you can ask more questions later. Did you have any blog writing experience prior to starting writing the book?

**Nadia:**I did have writing experience. I would say that, so first of all, I started journalism in college. So of course I did a lot of, a lot of writing there. And when it comes to blog writing experience, I, afterwards I was an editor and a journalist at an independent news magazine. it was, it wasn't Russian, but still it was writing experience and kind of when you'll learn to write in one language and you understand. You know, what makes good writing you can apply this skill to other languages as well? I believe.

Nadia: What else? I'm trying to think. I'm not really, I wasn't an expert blogger. I would say that when I was learning to code, I did publish a few blog posts here and there, and I still publish blog posts from time to time. But, I can't say that I did much writing. I would say that I did a lot of writing in my job as a software engineer, weirdly enough, I think a lot of engineers would relate because as an engineer, you have to write so much, you have to write a recommendation, you have to write code reviews, you have to write pull requests, descriptions, and all of this teaches you to explain your thoughts very clearly.

Nadia: Also, if you work remotely, you have to communicate a lot with people who are remote and it teaches you to be very precise and clear in your communication and your answers. So all of this helped.

**Elliott:**That's correct. There you go. Just in the interest of time, that is the last question for this session, but what I do recommend for everyone is to please go back to the event page. There is a discussion area that if you do have any thoughts or things you want to ponder, please pop them in there cause that's always a good place that we can go to reference.

Elliott: With that, very awesome session. I think we'll wrap up there. So thank you very much again, Nadia. If people want to get in contact with you, do you have a preferred social platform or any way that people can connect?

Nadia: Yeah, basically you can add me on LinkedIn or follow me on Twitter or subscribe to my YouTube channel and “beetlehope” pretty much everywhere. That's my handle. So be glad to be in touch. If you have any more questions, feel free to reach out and yeah. Thank you so much for joining today and spending the time together.

Elliott: Okay. Should you have any final words of advice for everyone before we finish up?

Nadia: Yeah. I think that what people often have trouble with is actually seeing them for who they are actually. And people tend to ignore the skills, the experience, and like all the awesome stuff that is within them already. And they just dismiss it because, you know, it's like a fish being in water. Like it doesn't notice the water. Right. So you might be thinking that you don't know anything, you don't have any skills, you don't have any experiences. So it is helpful to talk to somebody who knows you and just ask them, you know, what do you think is amazing about me? What skills do I have? Like, what'd you think I'm very good at?

Nadia: And then try to analyze it and think whether this is a skill that came to transfer to something else and something else that can be your new hobby or maybe a new project or side project, you know, business or something like this. yeah, I would encourage you to do that.

Elliott: Awesome. Well, thank you so much again, with that, we'll finish the session there, so thank you so much to everyone for coming. Our next event for anyone who's interested is just in a few days actually, and it's “How to detect silent failures in machine learning models.” So please jump back on to the codementor events homepage, and register.

Elliott: Don't forget, we have events there pretty much every week, if not every couple of days. So always pop in there and check what's new. If you're into machine learning, that's the next one coming up. I will leave this session open for a few more minutes in case people want to network and chat or anything else they want to ponder.

Elliott: And once again, thank you all for coming and we'll see you next time.

High-income, remote careers for developers like you

Join Arc and receive offers from high-growth tech startups paying from $60,000 to 175,000 USD!

Discussion 

Loading...