 Is this thing on? Cool. All right. So I'm Ashish Dixit. I'm here to talk about how you can make a difference and be a productive member of a team. Not necessarily immediately, but pretty quickly by following certain strategies. And this is irrespective of your background. But before we get started on that, let's take a little detour and find out more about me. So I was born and raised in this little country called Nepal. And I was a part of a small middle class family. So we have computers growing up. The first time I actually played with a computer was when I was in school. And I think it was the eighth grade when we started basically having access to computers during computer classes. And I was absolutely fascinated. Like the first time I played with it, I was just giddy with excitement. So I wanted to learn more about how they worked. And then around 2002, I came to the United States as an international student freshman year. I was like, well, you know, I always wanted to learn about those computers. So let's take a CS class and see what's up. So I took a CS class. And doing one of my projects, I actually ended up fixing a bug in my dream and remembered it the next day. So I was like, this thing's pretty cool. I think I want to keep doing it. So that's how I started with programming. But as I took more classes in CS, I was always very concerned that I was learning a lot of new things, a lot of interesting things. But I couldn't see clearly how knowing those things would help me provide value when I went and got a job in the real world, right? So that was always in the back of my head. And the real world happened. Graduated 2006. And two days after graduation, the H-1B work visa at Coda expired for that year. So if you know the immigration laws of this country, there are a lot of fun. So which basically meant companies weren't really looking to hire anyone who needed sponsorship. So I ended up doing like a year gig. I ended up doing just eight months. But I took a gig for a year at Berkman Center for Internet and Society up in Boston. And it was actually cool because it was my first introduction to open source, Ruby, Rails. I even went from being a Windows user to be like, fuck this. Let me install Ubuntu on this. And I never looked back. Well, no, I did have to look back because, again, the immigration laws. So to stay in the United States, I either had the choice of going to grad school and becoming a student again. Or I had to get a job that's sponsored. So that's what led me to a .NET job. The cool thing about this job was that I actually got to code. In my previous job, even though I was hired as a developer, there was way too many administrative tasks that needed to be done during the day and training interns, that kind of stuff. So I was very excited. And I thought I did well. I was fixing bugs, getting to know the code base. They liked me enough that they said, hey, sheesh, I think you should be our ETL developer. And I said, hey, that's awesome. But I know nothing about SQL. They're like, hey, it's OK. You'll learn. So I did. I did a little bit of ETL development with Perl. And then it was not Ruby, but it was close enough to Ruby. The only problem was that the company was known for this methodology that you may not have heard of. It's called crisis-driven development. It's when you go to work, and there's a fire, and you fight it, and then you come home, and you rinse and repeat. And this happens because the company didn't think it was a software company. They had a software product that they were selling to a client, multiple clients, for a lot of money. But they didn't think they were a software company, so they were not invested in the idea. They were not sold on the idea of how software should be built. And it was OK for a little bit. But I was watching the Ruby world from the sidelines. I just started getting very tired, because I would read articles. I would see people talk about how software should be built, write tests, have clear iteration goals, all that stuff. And we were just winging it the whole time. So I needed to figure out an escape plan. So I started looking. And then I came across this job description for Optiva Software Apprentices. And the one thing that caught my eye in the job description was they said that, for this position, we value potential over credential. And I was like, that's great, because I do have potential. I just don't know enough about Ruby and Rails. But I think I could learn this after all. I mean, I learned SQL and Perl and became an ETL developer without no background. So I was like, oh, I'll try this. See what happens. But good old friend Immigration Law came back knocking again. So according to the United States Immigration Law, if you are on H1B visa, you need to be employed for a full-time position. So an apprenticeship, because of the nature of it, you can't expect companies to make it a full-time position. Therefore, even the opportunity was there. It was not something that I could do. Luckily, though, there were other people who believed that I could deliver value as a developer. So I got a job at a company in Baltimore called MDLogix. And I found myself in this situation that I had dreamed of for so many months, like when I was planning this escape plan from the crisis world and the Excel hell. So I got in, and I found myself in this situation of understanding, OK, what are iterations? What agile actually is versus what the neveless agile world? And then how to write tests, all this stuff. And it was great. I learned a lot. And then four or five months after that, I was hired at Groupon. And I've been there for a year now. And it's been an awesome ride. I basically got to do the same thing again. A new team, new environment, new way of doing things, new code base. And then you just get in there, try to figure it out, and then see how quickly you start delivering value to your team. So why am I talking about this? Well, I strongly believe that people want to go to work. And they want to know that they're making a difference. There are different factors that people take into consideration when they're looking for a job. And there are different things that make them happy. But I think at the core, everybody wants to feel like the work that they're doing is helping someone. So that's what it is. And I think the drive to deliver quality work and the desire to improve constantly is a good place to start. I used to think that I needed to know the fundamentals of Ruby. I needed to be well versed in different things that Rails does that make things easier. But what I realized through my experience is that at the end of the day, what really mattered was not what I knew, but how eager I was to learn and how willing I was to be OK with the uncertainty. And if nothing, the one thing that'll get you comfortable with uncertainty is, again, the old friend, the immigration law. So the other reason I also wanted to talk here is because I actually want to start a conversation around this. Yes, I'm speaking to you in this 20-minute slot, but I don't want it to end here. I want people who are in that situation where they feel like they have the potential and they have an opportunity to sort of see this and try out some of the strategies that we're going to discuss in a little bit here and see how it works for them or talk about other strategies that they have employed that has been successful and have more people talking about this stuff. I also want to start a conversation among people who are more experienced, who are working with these new developers coming in. And I want them to sort of see what kind of mindset they're coming in with, what kind of struggles, like mental that they have to work through, and basically be better prepared to understand the new developer coming in with limited background and then have enough information to help them make the most of the formative six months. That is when you start at a new team, right? So let's start with some of the strategies. I think the first thing you want to do is, yes, there are a lot of things that you don't know when you first start out, and it's kind of overwhelming because the list of things that you need to learn keeps piling up and up and up, but rather than focusing on things that you don't know, you should focus on, well, what are the things that I do know? What are the things that I could bring? What do I bring to the table, a value proposition? So one of the best things coming in with no preconceived notions into a code base is that you can look at something and you're like, this does not make sense. Why are we doing this? Because you don't have the preconceived notion. You're not used to that code being there, and you've not accepted that as a new person. You're in a great position to identify stuff like that. The one thing is that you have to bring light to the situation, so you have to speak up, just be like, hey, this does not make sense. Why are we doing this way? Why can't we approach it this way? But do it in a way that have a positive outlook about it. Don't have some empathy for whoever wrote that code and try to understand what context it was written. Maybe there are certain constraints when it was written that are no longer valid. The other thing that you want to do is you want to leverage the skills that you've already have. Maybe you had a strong JavaScript background before coming into this new gig. Or maybe you did a lot of ops work for your previous company and you know your way around the Unix shell better than most people. Or maybe you have really strong speaking skills or writing skills. All these skills are valuable things that your new company and your new team could stand to benefit from. So definitely find opportunities where you could use these skills and then help your team basically achieve their goal in whatever way the goal may be. The only trick is to be cognizant that your skills should not be the hammer and everything shouldn't be the nail. Don't try to force just the stuff that you know onto everything. So I think Corey Haines was here, was responsible for this picture, although I found it somewhere else. But outside of the very sad possibility of making Pandas sad, I think pairing also allows you to give a great introduction to, give a new person a great introduction to not just the code base, but the domain of the app. And it allows a very interactive, engaging conversation on your first day. When you're going through the code and you get to ask questions, you get to play around with the code, the console. And it's really a great way to sort of get your feet wet with the app and then know where things are basically. The other awesome thing that it allows is that it enables the new person coming in to not worry about syntax. They could focus on the problem that they're trying to solve. And they can just not worry about like, oh, I don't know the syntax for this. That's secondary, because you could just look at the problem and you're like, okay, if I were to do it in pseudocode or whatever, I'll do this, I'll break this problem into these little pieces. And here's how I arrived at the solution. You could just talk it out with your pair and then with your pair's help, write the line of code that actually implements that solution. But what that does is, it gives you the opportunity to learn the syntax as you go, but it also engages you like very early on in problem solving and it builds confidence. You get excited when you're coming up with these solutions. You're already delivering value and you don't even know the syntax yet. And I think that's awesome. So once you've kind of figured out like your way around the code, like you have some idea for where things are, I think it's a great opportunity to take time and sort of take things on your own. Like just go for a little adventures here and there. And the best adventures are squashing bugs. Bugs, we try and always say like, oh, we have to minimize bugs, but bugs are absolutely the best friend for a new developer. And you should ask to be on bug fixing duty because it allows you the opportunity to test the knowledge that you gathered from the earlier phase when you're pair programming with your team and see how truly do you understand. And then when you're trying to figure out how why the bug is happening, maybe you'll discover something else. Some part of the code base they weren't sure of. It's just a very good way to start working on that quickly and then on your own pretty much. And then definitely ask for help, even though if you're on your own, don't feel like you actually have to figure everything out. The reason you're on a team is you could lean on each other. Not everyone has to be an expert. You're not expected to know everything. So even though it's tough to ask for help, they'll be like, oh, you know, like, yeah, I feel like I should know this, but I don't is a good way to start. But definitely ask for help. The only thing I would say is like, when you're asking for help, and I struggle with this initially a lot, is to at least take time and try different things. And at least from the person you're asking, like, see it from their perspective and make sure you've exhausted all possibilities of things you could try before asking them a question. Because if you do that, then you at least get more benefit out of that exploration phase of when you're confused, working with something. So again, like, you've been at a job for like a couple of weeks now, maybe three weeks, like squashing bugs, and it's been great. And you're asking a lot of questions, and you're finding out about all these things. And that's a great time for you to then be like, okay, let me start working on some stories. And the cool thing about stories is like, just like bugs, it forces you to go explore certain areas of the application, test the knowledge. But then it also like cultivates ownership. Like now you have a piece of the application that you've shipped. And that's exciting. That's exciting that like something you built is making someone's life easier somewhere, right? So it gets you very excited about the product you're building and you, I mean, an excitement just leads to, I think, more code and more fun. There are things to watch out though, or at least one particular thing. We hear a lot of conversations around code quality, elegant code, like proper design, all that stuff. And they're important and it's good to keep that in mind. But when you're first starting out, allow yourself to write ugly code because you will write ugly code. And it's okay, everybody does. Like don't feel like the code that comes out of your hand has to be this beautiful, elegant piece immediately. And definitely if you do write ugly code, resist the urge to be like, oh, let me just scrap this and rewrite this until you make it functional. Let it actually do what it's supposed to do. And then you're in a better place to make it better. So you've been working on bugs, you've been working on some features, now you're like in a very good position to start like actually improving. At this time you should probably be like fairly comfortable with the app and you know your way around. So like this is a great time for you to start improving your workflow, your tools and then maybe understand more of like the stack, the technology stack. One of the good things that you can do to get started with improving is just like automate your workflow, pay attention to what you're doing and then just try and find ways where you could improve, like shave off like a couple of steps in what you do fairly regularly. So at Groupon, when we were at my team what we used to do was we follow the GitHub flow. So we'd throw a pull request, we'd push everything to a branch and then go to GitHub, try and find our branch, click the pull request button and it was just like annoying. And so what we did was like, well let's just write a little bash script and see what happens. So now we have a little bash script that just pushes your code to GitHub and opens your browser in the pull request window ready for you to just click create. And it was not like too bad and it was not that big a deal but like now 15 or so people are using it and more people if they know about it they'll probably like it too. So stuff like that, just find ways to make your daily lives better. One-on-ones, they are awesome. Definitely try and talk to your team lead or your manager constantly, like fairly regularly to try and get feedback because they're in a very good position to tell you how well you're doing and what areas that you could use improving. I highly recommend. And then especially if your focus is on improvement it's a great way to have that feedback. Like every week you have or every month however regular you wanna make it. You have someone saying, you should rework on this this time around and then it's great. Like you're improving every day. Communication. Language inherently is very ambiguous and what that leads to is sometimes like your understanding of the sentence versus the other person's understanding of the sentence is completely different. And especially when you're new to the domain it's very important to clarify your understanding of the acceptance criteria for the story you're working on. Not just because of the potential ambiguity of English language but because you're new you may not know like external dependencies. There might be certain APIs that might have to be built like. So definitely communicate with your teammates like, hey, so this is what I think I need to do. Is there anything that I need to be aware of? Do I need to send someone an email to have some API endpoint be created and is there any possible ways that this could go wrong? So it's always important. And the other thing about communication, which again I'm slowly trying to improve on is to try and distill it to the core essence of what you're trying to say and give them enough context but let them ask for details. Don't overwhelm with all the details at once because they can't process all that information. Utilize the available resources that are around you. The sheer knowledge among your team is a great place to start. Like if you've always been interested in closure and someone's doing closure at work, that's a good place for you to get your feet wet and then kind of lean on them and then learn that. It doesn't have to be study groups either. It could be meetups locally or like within your company that you could go to. There are various other things. I mean training programs, companies might do training programs internally. So whatever resources are available, definitely take part in those and try and get as much out of them. So once you've done all this, like you've gotten to a point where you've kind of created your own apprenticeship of sort and you've gotten to a point where you're fairly comfortable with delivering value on a daily basis. So it's a great time to take a breath and then look back and then congratulate yourself and then thank the people who've been part of the journey. It's also a great time to start thinking about how you can pay it forward. And there are different ways you could do it. With startups like Code Academy, with initiatives before like Ruby Mencon University, there are a lot of places where you could do mentorship. So that's definitely one thing to do. You could write blog posts, speak at conferences, that sort of stuff as well. There are definitely other strategies. You could, I think one of the biggest ones is side projects which I think Dave Hoover in his book explains as breakable toy, which allows you to try different ideas in the safety of a simple app. I highly recommend this book by the way for anyone who's trying to improve. And again, I'm pretty sure there are other strategies. If you have a strategy on your own, let me know. I'm $20.45 on Twitter. And I'm Ashish at groupon.com. So that's all I got. Do you have any questions? Okay. You can't do the questions right now. All right. Leon.