 How's everyone doing? No, no, I'll just try and entertain you while God does this thing. Okay, I'll get it. I made my slides on Monday, which is still, like, pretty good for my track record. All right, should we go? Okay, great. Hi everyone, my name is Isha. Some of you here have met me before and know that I love to talk, so. I'm going to be talking about my developer journey, and after listening to Sujan's talk, I realized that mine is slightly tangential, if not opposite to everything that she said. So I'm going to try and draw parallels where I can, but I hope that you gain something from what I'm going to talk about. All right, so, welcome on board. My title is the Hitchhiker's Guide to Software Development. That's because I just read Hitchhiker's Guide to the Galaxy and I just got very excited about it. I tried to find more metaphors to match Hitchhiker's Guide, but I think I'm not as creative as Douglas Adams, so I couldn't really do that, but I'll try. Let's start with just getting to know each other a little bit. I can tell you something about me. I have a degree in electronics and communication engineering. I do not have a software development degree. The only software development I learned, so to say, is when I did C++ in school and one C course in college during engineering, where we only wrote programs like factorial and multiplication tables and stuff like that. And I think my first sign should have been where I wrote, did the assignments not only for myself, but the six people who were sitting around me. That should have been my first clue, it wasn't. I ended up in software development entirely by accident. This company that I used to work for before my current job, which was instantly my first company, they were doing a recruitment drive, a bunch of my friends were going and I was like, yeah, sure, let's go, it's gonna be a nice trip. And that nice trip turned into a job offer and it turned out to be a pretty kick-ass company to work for and I worked with them for six and a half years. So I'm what they call a full-stack polyglot developer, which means I do anything and everything that falls on my plate. It also means that I'm a jack of many trades, master of absolutely none. But it's been a good experience because I've gotten to do a lot of things and I'll talk about that in a little bit. I am a consultant. We primarily do consulting with agile and extreme programming. That's what XP stands for. Pretty neat trick to writing good software, doing development in a more sustainable manner. Check it out if you haven't so far. I also love salsa, the dance, not the condiment. Actually the condiment's not too bad either, but the dance is what I prefer. And I spend a lot of my time and money on that, incidentally. I have been a developer slash consultant for more than eight years now. Worked with one company for six and a half years. My current company I finished two years in January. I have worked on more than 10 projects. I have worked on more than seven tech stacks. I just got lazy to count after seven, actually. I have worked with clients from more than five countries. I worked with people from much more than that. Also got lazy to count, so gave up. I have written and deleted countless lines of code in the last eight plus years. I'm pretty sure I've deleted more than I've written. So I count that as an achievement. And of course, being a consultant, there have been unlimited hours of talking to a lot of people. And that's not because I like talking. It just comes with the job. So yeah, I already talked about how I ended up here. Let's find out a little bit about the people in the room. How many developers? Most of the room, which is good. Any non-CS background developers? One, okay. Two, all right. Okay, three, four, five, six. Okay, great, perfect. This is my perfect audience. How many people with less than one year in development? Oh, great, even better. Definitely my target audience. Anyone with between one and five? Perfect, more than five? Okay, cool. So we have a fairly mixed bunch, which is good. So at any point, if you have a question or want to add a comment, please feel free. I don't want this to be. I have tried very hard to make it sound as non-preachy as possible, but it might still come off that way. So please jump in wherever you want to. So counter me or add something. I'd be more than happy. So with that, let's jump right into lesson number one. And these are based entirely on my experience. Of course, your experiences could have been different, could have been exactly the opposite. So please feel free to share, but disclaimer that this is based entirely on the last eight years that I've spent in the industry. Lesson number one is that there is no right way to be a developer. There is no, this is a developer or this is what a developer looks like. Everyone has their own learning journey. Everyone has their own skill sets. Everyone has their own strengths and weaknesses. So we all bring something different to the table. The whole point of development teams and tech teams is that we're all contributing in our own ways and bringing different perspectives in. Every single developer I have known in the last eight years has been somebody who's a combination of every developer they have met in the past. Every developer they have admired in the past. Every person they have admired in the past. When I first started out, I would look at someone, walk with them and be like, oh my God, that's the kind of developer I want to be. And then on the next project, I meet someone else who's like the exact opposite of the last person, like no, maybe that's the kind of developer I want to be. And then over the years, as I've met more people, both developers and non-developers, people I've worked with, people I've interacted with have made me the person and the developer and the consultant I am today. So I'd be very wary of someone who says, oh, that's not a real developer. That's not a real job. We all have our own things. Software development is such a broad domain. It is such a broad field that it's impossible to just put it in one box and say, that's how a developer should be. Lesson number two, before I move on to that, actually wait, let me just check quickly what my lesson number two was. Right, yes. How many people here have been or are scared of asking questions in big groups? Yeah, yeah, yeah. I'm exactly the same. Well, used to be, not anyway. Am I still on this? Okay, apparently not. Yeah, there we go. The best way and the cheapest way to learn is to ask questions, even if they seem stupid to you. If you don't ask, you will never, ever learn on that thing because especially in development, half knowledge is a very dangerous thing. It's very, very dangerous to make assumptions because you spend countless hours having worked on things based on that assumption and then you find out those assumptions were completely invalid. So ask questions, ask for clarifications, seek more information as much as you can. If you're in a group, if there are multiple people there, if you have a question, there is a more than likely chance that someone else in the room has the exact same question or something that will help them answer their question or it'll just encourage them to ask more questions. For, I think the first two, three years of my career, I never asked any questions when I was in a meeting or in a discussion because I assumed everybody else in the room was much smarter than me and which is why it didn't matter. It was stupid, they would think I don't know anything which was often true but it also meant that I never actually learned what I needed to learn. I never really got the entire value of being in that discussion. So I got to a point where I got feedback saying, hey, I think you're asking too many questions. Sometimes that derails the discussion. So like, okay, that's useful. How do I counter it? So I was told, you know what? If it's something that doesn't need answering immediately, write it down on a piece of paper, ask it later. It's a trick I've used, it works, maybe try it out. But the key thing is to always, always ask questions if they're relevant, of course. If they're, you know, critical to the discussion that's happening right now, not necessarily to derail the discussion. Because like I said, it's the cheapest way to learn and it's very important to have as much information as you can before jumping into writing code to state it at the simplest level, right? All right, lesson number three. You don't have to live, breathe, sleep code all the time to be a good developer. Majority of the developers that I admire and take inspiration from are people who have hobbies outside of code. I'm not saying you shouldn't spend time doing research or learning new things or keeping up with the latest trends, reading tech news, all of these things. You should do it because software development is a field that changes very, very quickly and very, very drastically over a very short period of time. It's constantly in flux. There's something or the other happening all the time. But it doesn't mean that you can't do anything outside of code or outside of tech if you're a developer. I have met people like that and they are not the easiest people to work with, at least in my experience. It's very exhausting when you're a new developer and a senior you're pairing with says, oh, you go home and read this book. Tomorrow I'm going to ask you 20 questions on it. But I have dance class. I pay money for that. I want to go do that. So no, I can't. But it's okay. If writing code and if doing side projects and having pet projects is something that gives you joy if I'm not going to pull a Marie Kondo on you. I'll try not to. If that's something that makes you happy, great, go for it. But you don't have to do it just because that's expected of you as a developer. I don't have any pet projects. I'm a little embarrassed to say that but it's true. But at the same time, it doesn't mean that you don't do anything about it. You still need to do research. You still need to stay up to date. But it doesn't have to be the have all and be all of your life. Before I move on to lesson number four, any questions, thoughts? No? Okay, so about people who just leave really speed code, I think when you say that it's very difficult to work with them, it's very true. Because I do meet people who are like that. And they just don't, they just focus on their work. I'll give, they don't really see the full picture. Right. Yeah, and that's a very fair point, right? It's very easy to get lost in the details. And because I work in consulting, a lot of my job actually involves sort of stepping out of the details and seeing the bigger picture, seeing what the end-to-end journey looks like, where is this product headed? What are the things that we need to change in order to change the way we're working or to improve the way we're working? A lot of that is involved as part of my work. And it gets, like you said, it gets very difficult when you're lost in the details and not seeing the bigger picture. So thank you, thank you for bringing that up. Anything else? Any thoughts on that? Okay. All right. Lesson number four is probably the most important lesson I have learnt as a developer and a woman in tech. Imposter syndrome is real and that's really okay. It's fine. It happens. A lot of people experience it. A lot of people deal with it. There is no harm in it. What matters is how you deal with it, more importantly. It's not to say that, oh, it doesn't exist. It's all in your head. No. You wouldn't tell that to someone who, I don't know, had depression. You could, but you shouldn't, because that's very unfair to them. But it's a very real feeling that a lot of people, especially women in tech have, I was reading some research that said that over 70% people in tech actually suffer from imposter syndrome and majority of those are women. So yeah, so one of my biggest, biggest learnings has been that it's real. Sorry, I didn't ask, but is there anybody here who doesn't know what the term imposter syndrome means? Okay, cool. So yeah, to give you a very personal example, when I first joined my first company, I joined as a fresh grad. I had very little computer science experience. I didn't know half of what was going on. I didn't know what Ubuntu was. I didn't know how Linux OSes worked. I didn't know what Git was. I didn't know there was a language called Ruby that existed. There were a lot of different things that I didn't know at the time, simply because I had never been exposed to that sort of thing. And I wasn't envisioning a career in software engineering in the long term. So when I first got in, my company did this six-week onboarding program that they do and it's a global program. So you have everybody from all over the world who's hired as a grad consultant, come in and be together for, work together for six weeks and then everybody goes back to their home offices. I got there and the very first day, I think I could see that everyone in that room knew more than I did. They were people who had already been working in the industry for a year or more. There were people who had graduated with very strong computer science backgrounds and they knew so many words that I'd never even heard of and it was very, very intimidating. And at that point, I did question if I was at the right place, if I deserved to be in that company surrounded by so many smart people. And feeling and what I was going through with another trainer in the program and the advice he gave me was one of the best advice that I have gotten. And the advice was this. You know more than you think you know. You have to have faith in the people who have hired you. You have to have faith in the people who have brought you where you are because they had faith in you. They obviously saw something that they thought you could bring to the table, that they thought you could contribute and that's why you're here. And that is something that has stuck with me over the years. And that's not to say that I've gotten over my imposter syndrome. Even standing here today, I don't think I'm qualified to be talking about any of these things. But to me, it's about sharing my experience. You could take it with a pinch of salt. You could, maybe it applies to your own experiences and it gives you the confidence to, you know, take a leap and do more things. But for me, that was the turning point. Another example of you know more than you think you know was the same onboarding program that I went through when I joined the company. Three and a half years later, I got a call from the stuffing manager and she said, hey, the university is looking for some trainers, do you want to go? And I remember I was on vacation at my parents house and I'm like, I don't think I'm ready to go be a trainer at university. I've barely done anything. I've done maybe like three projects. I don't know anything. She's like, no, no, I'm sure you'll be great. I think you should go. And I went and I was super scared. I was a mess. I spoke to the program leader and I said, dude, I don't know what I'm going to do. She's like, no, no, don't worry. Things are gonna be fine. You have all the material. You have all the trainers. It's gonna be great. It took just my first term, which was the first I think six or seven weeks that we did. So make me realize it's true. I actually don't know what I'm talking about. This is stuff I do on a day to day basis. This is stuff I apply on my job every day. And I just have to talk about it. So this actually works. I ended up staying for two more terms. I ended up going back for five terms and joined the core team for that program. And it was one of the most amazing experiences of my life. I learned so much and I grew so much as a person during that time. If at that time I had stepped back and say, nope, not ready. I'm absolutely not going to do it. I'm not going to even try this. I wouldn't be the person I am today. So I owe a lot to that one woman who said, nope, you're going to be fine. I think you should do it. So another example of you know more than you think you know. All right. Any thoughts before I move on to my final words? Not like I'm not dying. I'd like to add something. Yeah, go ahead. And I said about at least a few years back now I think a lot of young graduates have already having a lot of hands-on experience before they get into their first job. But earlier that was not the scene. You come with a lot of bookish knowledge and then you are thrown into this team where most of the people at least my first job, I had architects and seniors with more than 10 years of experience. So yeah, most of the time you're scared to approach them asking, okay, thinking whether I'm like asking the right question or not. But I think that's where the importance of a mentor comes. If you have somebody with that confidence to go back to me, even if it is a bunny. Yeah. So in both the cases that you have mentioned, I have one of them. Ah, yeah. So I think it's, I feel that in any job in whatever position you are, if you have a good mentor then yeah. Absolutely, absolutely. Like the value of a good mentor I think cannot be underrated. It's so important to have somebody in your life who you can just talk to. Like I'm very thankful for the mentors I've had in my life and some of them have been exceptionally strong women. And it's been so important to just be able to talk to them. So I'm very glad you brought that point up, thank you. With that, so going into my final words before we disembark, have opinions. It's okay to have opinions. You should have opinions. You should form your own opinions about things that you know. But you have to be ready to change them based on new information. I used to absolutely hate statically typed languages until a few years ago. It's like, Ruby is the way to go. Forget, I shouldn't say that word. You know, forget about statically typed languages. Forget Java, forget Scala. But then when I actually dug deeper into these, I was like, actually they're pretty good. Why did I like Ruby with all its duck typing and whatnot? But the important thing is to, there's something you like today. You discover new information, you might discover something better. And that's great, right? The important thing is to keep learning, keep discovering new information and keep forming new opinions based on that information. As much as possible, if you'd like, contribute to open source. It's a great way to learn. It's a great place to experiment with things you've not done before. And Sujan was talking earlier about having a portfolio and actually open source is a great way to build that portfolio. Your GitHub profile is the best way to show someone what you've been doing, what you've experimented with, just that how broadly you have actually explored in terms of tech. So contribute to open source and also of course it's for the greater good. So there's that aspect of it as well. Find a Buddy is very similar to what you just said, that it could be anyone. It could be a senior. It could be a friend. It could be a mentor. But just someone you can talk to about your struggles, things you want to do next, when you're unsure, when your imposter syndrome overtakes in your life. Oh my God, what am I even doing? How did I end up here? It's very important to find a person. I'm definitely not trying to say that software developers don't have friends. I mean clearly, we're all here, I'm sorry. So yeah, just find someone you can, you trust that you can talk to and you think will be your sounding board. It's very, very important. Don't be afraid to experiment with the kind of roles you do, with the kind of tools you use, with the kind of technology you use. I have, I've been a business analyst. I have been a scrum master, which is by the way, the most confusing job I have ever seen. I don't really know what it means to be a scrum master. Probably because I've worked in an environment where we never had scrum masters. So yeah, but yeah, I've been, I've been a technical analyst. I've been a business analyst. I've been a scrum master. I've done training. I've done training trainers. I've done, and of course development, because that's my core job. But each of these roles has taught me something new. It's also taught me that I never want to be a business analyst full-time. I definitely don't want any scrum certification. Not because I think there's anything wrong with these roles. I just don't think they're for me or the kind of stuff that I want to do. So experiment. You never know. You might find something that suits your skill set better. You might find something that you like doing better, something you enjoy more. And that's, what are the way to learn more about yourself than to just experiment? Just jump in and try it out. And of course, with those words, go forth, explore, do your thing. Remember the lessons that I have shared. And with that, we shall say goodbye. Thank you so much for listening. If you have any questions or feedback, you can either tell it to me now or you can reach out to me either by Twitter or email. So thank you.