 Kelsey hails from the far off town of Cisco where she currently works as a mentor for the HackBite Academy for having her own internship in education. She's previously worked with the Internet Archive building tools to improve user experience and accessibility and is here today to talk to us about how to move beyond the Hello World tutorial experience as a beginning developer. Please make her feel welcome. All right. Can you guys hear me? Awesome. Cool. So welcome to I finished the beginner tutorial. Now what? I am Kelsey Karin Holly. I go by Karin at work and Kelsey in lots of other places. So I figure go by both. My Twitter handle K Karin Holly. I'm not super active, but I am responsive. And if you want to follow along with my slides, they are available on GitHub. So I am a software engineer currently working at Honor. Honor is a Python shop and we are hiring. Feel free to ask me later. I have a CS degree from UC Santa Cruz and I've taught girls who code over the summer. I got really passionate about it. And I'm currently a mentor at HackBite, which I am loving. In my spare time, when I do have spare time, I am an avid reader and I also am a crafter. So if you like knitting or crochet, I'm into that too. So this talk is going to cover three different learning approaches. And I'll delve into each one. I'm also going to talk about getting connected with the community. And then I'll summarize everything at the end. So some things that I'm not going to cover. I'm not going to talk about boot camps. I'm not going to talk about code schools. I'm not going to talk about college or online courses or how to find more tutorials. So the first one I'm going to talk about challenge based learning. What do I mean by that? There are lots of websites out there that will give you lots of different exercises. You can do one at a time and kind of grow your skills through a small problem instead of taking on something big. This style might appeal to those who don't want to start on a big project, don't want to build something from scratch. If you like rewards or trophies or badges, there's also that kind of a motivation behind it. And another thing that I really like about these is most of them have pretty strongly covered edge case testing. So if you think you solved it, awesome. You run the test and you realize, oh, I missed something. So this is a very small list of the quick Google search that I did to come up with all the different tools out there. There are a lot of them. I think I played with three on this list. Some things to keep in mind when you're choosing a tool. If you're wanting to learn more than one language, maybe today you're learning Python, but next month you want to start learning JavaScript, try and pick a tool that's language agnostic or that has multiple language support inside of it. So you're not picking one tool for Python and then having to find something else for JavaScript or something else. As I mentioned, strong solution testing is really important. They help you out to figure if your code is not optimized, it's not running at speed, or if you missed an edge case, things like that. So having a testing that gives you an error message or something to go off of is really helpful instead of just saying, I failed. A lot of these tools have in-browser interpreters as well as editors, so if you're wanting to be on the go, if you don't have a dedicated laptop, many of them you can just work completely online with them. I mentioned badges before, so if you like reward motivation. A lot of them have built-in review and feedback mechanisms too, so if you want to get ideas on how to improve your code or if you want to help others, there's a few that do that. And many of them have competitions, so maybe you're not ready to do a competition yet, but they do host them every month or every week, so when you feel a little bit more confident, you can join one of the competitions. The first one I'm going to talk about is HackerRank. So some things I liked about HackerRank, they have a pretty good diversity of problems as well as languages. They support both Python 2 and Python 3. The way they have things grouped is from easy to advanced, so maybe you don't need to do the hello world anymore, you've figured that out on your own. You can move on to something a little bit more advanced, maybe you haven't played with strings as much yet or some of the math-related functions. They also have that in-browser editor and interpreter that I was talking about. I believe they have syntax highlighting. Their tests run in real time, so if you hit, you know, submit my code, check and make sure it works, you get to watch as each one passes or fails, and you'll get to see the error messages of why it failed. Maybe it wasn't optimized, maybe you missed an edge case. Some things that I don't like about HackerRank, they don't have a community collaboration type of built-in. When you submit your code, you submit it to be graded and then it's lost in the ether. So there's no, hey, you could improve by doing this. There's also no way to take those problems offline or test offline. You have to do everything through their website. Another one that I've played with, Exorcism I.O. The things I like about Exorcism I.O., completely opposite of HackerRank, they do have a built-in review set. When you submit your code, it goes public and anyone can make comments on it or you can ask questions and get help from others. I think that's really cool. You might have done it one way, but there's a million other ways to code something. You can also join teams or create a team, so maybe there's eight of you all learning Python together and you want to start tackling these challenges. You can post your code, what you did wrong, what you were missing, where you need to improve, and you can grow together. Something else I thought was really cool, their exercise list is actually an open-source repository on GitHub. So me, as an advanced engineer, I might see that, oh, this has a bug in it or I really think that you should include this exercise on your list and I can help contribute and help them grow in what they're offering their students. Some things that were not my favorite, it is terminal command line dependent, so if you're not comfortable on the command line yet, they do walk you through how to get set up and how to get started, but it's going to be a little bit of a learning curve or a barrier for entry there. And everything in Exorcism IO, you do run on your computer. There is no in-browser interpreter or test runner or anything else. Everything is run on your computer in the command line or in the editor of your choice. And another thing that I ran into, maybe this is wrong, but it seems like I had to complete all of the exercises in order. So in order to get exercise two, to even look at it, I had to complete and get all of my tests to pass for exercise one. From a learning perspective, that's probably a good thing because it means if the next exercise is building on a concept, I haven't just skipped over exercise one just to get to two, but I'm the type who likes to skip around, but as I said, there are a bunch more challenge-based websites that kind of fit this model. So I've just covered two. There's lots more to explore. Pick one that appeals to you or has a community that you like. So summarizing the challenge-based learning, it's a great way to build incrementally on a new language. The built-in test suite will help you figure out what you've missed, what you need to fix. It's a great way to learn how to do things, but you're coding style as well. And many of them do include competitions for prizes, money prizes, physical prizes, or have jobs attached to them. So if you complete this challenge and do really well, you might get a job offer. So example-based learning, what I mean by this is looking at someone else's code and dissecting what they did and understanding what they did and then being able to take those concepts so this is kind of appealing for someone who needs some starting point. They're not ready to go off and build on their own. The exercise approach didn't appeal to them, but they still want to be in code and learning. If you enjoy reading other people's code or reading other people's stuff and kind of seeing how they did things, this is also very appealing. And if you've been reading about a lot of abstract concepts, maybe you've read about Decorators recently, but you've never seen one in the wild. So I'll look at someone else's code to see what that decorator looks like and how it's running. So finding a project, I do recommend that you have at least a basic understanding of GitHub and Git. If you don't, there's a couple of tutorials I'll put on my last slide that'll kind of help you get started, but you're going to need to find things on GitHub and then probably clone them onto your local machine. So things to look for once you have that cloned or once you've picked a project or when you're picking a project, a good read me. Does it have a good setup instructions? You know how to install, to build it, to run it. If there's no read me, this probably isn't the repo for you. Is it under active development? Was the last commit eight years ago? That's probably not what you want to play with. It might be out of date. It's probably broken. Avoid those. If the contributor is really responsive, if there are lots of issues being posted and they're answering or they're doing pull requests well, if you run into problems or have questions, that means that you can interact with them and figure things out as well. The next one I'm going to say is a little bit more personal. It'll be up to you what you call easy to read or follow along with, but I recommend you not dive into something that's really complex for you. Find something that you're going to be spending a lot of time in. Make sure that you can follow along with what it's doing. And then don't be afraid to Google for foreign words or terms. I've heard of pip before. Most of these repos, if they're Python, are going to be talking about pip. So maybe read about what that is. Things to avoid. If it's importing 100 outside packages and you've never heard of any of them, probably not what you want to start with, because then you're going to be researching those 100 things before you even get to the code you want to be reading. If it's overly complex, if you're importing from this file which is importing from this file which is importing from this file on, if you have to trace that long tree, that's going to take a lot of time too. Probably not something you want to get started in. And then if you don't even know where the main file to start reading is, don't bother. If there's not like a main.py or something that says, hey, this is where the code starts, then I wouldn't use that either. So I've talked about how to pick a project. Let's talk about searching. So if I'm going to go on GitHub, what kind of tools do I use? I use Slack a lot in my daily basis. Do they have anything open source that maybe I can play around with? I can search on GitHub and see. I have a lot of friends or engineers who are also doing various open source projects, various hobby projects. I could look at their GitHub to explore their repositories and I can talk to them directly if I run into problems. The most important thing I want to say is find one that's interesting to you. I don't just mean like the code is interesting, but the topic. If you're interested in machine learning, I should pick a machine learning repository. If it's not a topic that you're interested in, chances are you're not going to want to spend the time to figure out what that repository is even doing, find something you're interested in. I'm a crafter. If there's a knitting repository, I'm going to be so into that. So quick search in GitHub for Slack, narrowing down Python. There's 4,000 results. I can pick some. Sure. Looks like we've got some Slack bots, some things that are doing something with the API. There's a lot of things I can explore. Once you've picked some repository to start exploring and digging into, some ways to start breaking it down. At a macro level, what is this code trying to do? Is it a bot? Is it a web app? Is it a command line tool? What is this repository doing overall? And then you need to kind of understand how they're getting what they require to do this. Are they importing from the request library? Are they importing from a file next door to this? What's going on to just generate the toolset they need? And then going into a more micro level, what is this code actually doing? What is this function doing? What is this line? What is this code block doing? Really digging in to understand how this code is working. And then asking even more questions. Why did they write it this way? Could you write it a different way? Maybe instead of using a for loop, you could use a while loop here. So why don't you change it? What happens? And if you throw an error message, those are the best! Because then you get to figure out what happened. And you get to learn why it mattered that it was done the way they had it written. Don't be afraid of error messages. They're really scary at first. I promise they're super fun. Maybe that's a personal opinion. And remember, you're not breaking their code by changing all these and generating errors. It's not like their server is suddenly going, you're doing all of this on your machine. Any changes that you make are on your machine. So it causes much chaos and havoc as you want. It's great. Once you're feeling a little more confident in this repository, you feel like you've got it under control. See if there's any open issues that someone has posted. Hey, this was causing a syntax error for me. Could you fix that? Maybe while you were working with it, you were like, you know, I really wish it had this feature. See if you can build it out. And then when you're kind of done playing with this repository, what are the takeaways that you found? Did you learn some new third-party package? Had you never used requests before? But man, it's awesome. Did you get exposure to some new built-ins? Maybe sets were new to you and you'd never used them before. Were there concepts that you hadn't seen? Decorators or generators or some other concept that you had heard about but hadn't seen in the wild? You can now use those in a future project or at least are less afraid of them. So summarizing for the example-based learning, find a repository that's interesting to you that you feel comfortable kind of digging into. Make sure to ask lots of questions of the code. How did they do this? Why did they do this? What happens if I change it? Don't be afraid to cause all the error messages. Again, they're fun. They teach you what matters and why it's wrong. And then use what you learned. So project-based learning. These are the people who are like, no, I'm not into the exercises. I don't want to go planning or else's code. I want to build my own thing. And they're ready to get started from scratch. So if you already have a project in mind, maybe you have that blog that you've been meaning to get started. And of course, you should build it yourself. So let's do this. If you couldn't find a good example on GitHub, maybe no one was using the Slack API quite the way you want to. So you're going to build your own thing. It's really appealing for those who are very self-motivated and very goal-oriented. If you're a junior engineer and you're trying to interview at places, creating a portfolio, building things from scratch that way is really good. You can show them off to future employers. So my biggest piece of advice. Scope creep. If you've never heard of scope creep, it's when you start off with this little tiny concept and then it just balloons out. So you're going to build an email server. Great. All you need to do is send or receive emails. But we're going to do that. All you need to do is send and receive emails. But wouldn't folders be nice? And wouldn't filtering be really cool? And what about auto-forwarding? And then it just keeps going. So to help kind of manage scope creep as well as kind of build out how you should do this project, I recommend breaking everything down into to-dos. And a to-do can be anything from research a new package or a new concept, experimenting with how that package works, actually writing the code for a certain file or function, documenting everything you've been doing, writing the readme or the setup to make sure that anyone else who comes along and plays with your repository can actually run it. And then building tests as well. So all of those can be to-dos and they can be broken out even more. If you feel yourself getting discouraged, I once wrote a project that had a thousand lines of code and didn't test any of it. And then I was like, I should write tests. That one giant to-do of tests was looming over me. I hated it. So I broke it down into even smaller pieces. I had to test this file. And it wasn't as daunting then. I only had a hundred lines of code to test instead of a thousand. And it felt really good to kind of say, yay, I finished this one. And it felt like I accomplished something. It kept my momentum going, and it kept me interested in what I was doing. So I made sure to celebrate each excess. Anytime I finished one of those to-dos, I was like, I am awesome. And if you get stuck or if you trigger those error messages you're talking about, Google is your friend. I have typed in an exact stack trace into Google before and been absolutely thrilled with the wonderful results that I get. Because everyone else does it too. They're like, I got this. What does it mean? Stack overflow. There's usually a great conversation. Yeah. So Google's great. Stack trace messages in Google. Super great. I'm going to tangent slightly and talk about my passion project slash horror story. I got really addicted to this board game called Castle Dice. And I was like, I know. I'm going to make this into a web app because all of my friends are moving away and I love playing this so much. Wouldn't it be great if we could just log in and play together? Yes. This is what I will do. So Castle Dice had three decks of cards. It had five different trackers. It had a board over here and a board for tracking over here and a third board for tracking more things. And there were turns and rounds and people involved. Anyway, super fun game. I recommend it to everyone. The complexity, though, for coding this probably a little more than I should have bitten off. So I started breaking it down. I was like, you know, I've got these five types of dice and each die has six sides but they're not one to six because there's a cow, there's a barbarian, there's one stone and a two stone, and then that dice deals with gold and not stone. Okay, so I need to figure out how to store these. How am I going to randomize the roll? What happens if I need to add the dice together? So there were lots of to-dos on my plate, not to mention the decks and the trackers and everything else. So did I finish it? Not at all. Not at all. But I do go back to it every six to 12 months. And for me, I wrote the dice five years ago. It's kind of interesting to see how my code has progressed. And I keep coming up with more ideas about how to fix it, how to change it, how to improve it. And there are small things that work. It's just not the full game. That's fine. That's totally fine. So my lessons after playing with Castle Dice, it was a huge project and it was definitely something that I shouldn't have chosen as my first, yeah, I'm going to break away and learn Django. There were a lot of things that I still don't really know how to approach. I never studied game theory, so I'm still trying to figure out how I can do you take a turn and now it'll tell me I've taken a turn and then it will tell the next person. Anyway, that'll be the next month thing to play with. I did learn a lot though. This was the first time that I had built a randomizer to roll this dice and do some stuff. I think it was the first time I'd built a dice, I was super proud of it. I'm still vaguely proud of it. Meh. And it didn't actually matter whether or not I completed it because sure, I didn't build the whole game, but I did build the dice roller and so you could click a button and watch the dice change sides and roll and give you different values and I got to show that off in an interview and I was embarrassed that I didn't finish the whole thing but they were really impressed to see that I had something working and that they could look at my code. So that's kind of cool too. It didn't matter that it wasn't finished. So to summarize, choose something small and break it into smaller tasks. Stack overflow in Google. Awesome. I consider everything a work in progress. If you asked me about Castle Dice, your last commit is two years ago. Are you sure it's not an abandoned project? No. I will come back to this. I promise. I promise I'm going to finish it someday. And the biggest thing, make sure you're having fun. This is a project that you chose to build yourself. So keep it fun. Don't be discouraged. So getting connected with community. We've talked about all these different ways that you can do code but getting into the community is what I find is really helpful because there are people even here today who, if I go up and say, you know, I'm really struggling with this Python thing, chances are they at least know what Python is, right? Pretty sure. They're using it in their daily jobs or they have used it in a daily job or they're on some open source project or some hobby project or they're just learning it like me. Or not like me currently, but anyways. So coming to these community events, you have lots of options to not only network but also get advice and guidance on things that maybe you're struggling with or that you need some help with and you need a new resource, new docs, whatever. It's also a great place to find a mentor. So I love mentoring. I hope I'm good at it. I think I'm good at it. I should talk to my mentees. Mentors will both help and encourage you so they're not just going to hand you the answer. Really good mentors will coach you to the solution. They want you to be able to think through the problem yourself and not just be handed the solution. They want to make sure that you can come up with it on your own the next time and understand why that's the correct answer. And we also really care about your growth. Like, I'm a mentor. I really love it when my mentee has been struggling with something and she finally has this click moment or the code finally stops triggering an error and she calls me up and she's like, oh my god, it finally works? Yes. I just want to celebrate with her. That's something that I get to enjoy as a mentor. I have helped her through this process. I have coached her and now I get to enjoy the fruits of her labor. Not take credit for them, but at least enjoy them with her. So there's lots of groups, conferences, tech events, all kinds of things out there. These are the handful that I have been to or am aware of. Pie ladies, lunch was awesome today, by the way. There are lots of Python meetups, Django meetups, Flask meetups. If you're more into the conference scene, PyCon, North Bay Python, which you may have heard of. PyBay, there's lots of Python-specific things. Even if I just go to meetup.com and type in Python in San Francisco, because that's where I live, there's a ton of results. And these are just the groups. They're not even the events. If you're into other languages, there's Waffle.js in the Bay Area. I know there's Donut.js in Portland. There's Railsbridge. Hackerspace, I think, is more agnostic. There's lots of ways to find interactive communities. If you are of the female or non-binary persuasion, there's also Pie Ladies, like I mentioned, but Girl Geek Dinners are really great networking opportunities. Women Who Code has a great newsletter. They also do events. Girl Develop It does, I think, JavaScript courses, but I think they also do events. And if you're the type who lives in the boondocks in the middle of nowhere, you're like, I'm not near a metropolitan area. How am I going to do anything? There are tons of online communities as well. Pie Ladies has their own Slack. Exorcism.io that I talked about has a built-in community platform, so you're able to interact and get feedback anyways. So, to summarize my summaries of summaries, we covered challenge-based learning, so practicing with small exercises, taking advantage of the test cases when they do and don't fail, community feedback, competitions, all the things baked into that. Example-based learning, so digging into someone else's code and really understanding how it works, why it works, what breaks, asking questions, playing with error messages. We talked about project-based, breaking a large idea down into smaller pieces, preferably avoiding the large idea in the first place. Getting help with that, putting things into Stack Overflow and Google when you run into problems, and having fun. All of these, that is the most important part. We also talked about community, various events, finding a mentor. So, the biggest takeaway I want you to have today is there's no one right way to continue your learning journey. Maybe one of these really resonated with you. Maybe you hate all of these ideas. That's great! Don't take my word for it. Some of these have worked for me, some of them have not. Some have worked at certain times, and others not. So, pick your own path, your own journey. And then here are all the resources. Again, I work at Honor. My Twitter is kkaranholly. I did manage to post these slides on GitHub right before this talk. And then some other links that I talked about. So, thank you. Thank you very much, Kelsey.