How I learned Django while working at Eventbrite by Allison Lacker

Speaker 1: Thank you. As said, I'm really passionate about accessibility and search, and I'm not talking about either of those. A little more about me, like why are you here? Why are you listening to me? Um I grew up in Ohio, which was really boring. So I went someplace totally different, which was Illinois. And I got my computer science degree from the University of Illinois. And then I was like, man, this is still actually really boring. So I ran away and joined the Peace Corps and taught people how to use computers in Cameroon. with the Peace Corps for two and a half years. And then I came back and I joined Eventbrite where I'm a senior software engineer. But None of that actually matters. Those are kind of like the highlights, the successes of my life.

Speaker 1: Why I know something about not knowing anything is because at each of those points, I didn't know anything. So, why should you learn? Why is it important? To which you say, what sort of programmer are you, Alison? Don't you know that our field's always changing and there's so many cool things you can do? It's like, yeah, yeah, yeah. But why does your company want you to learn? You always want to, but maybe you're doing that at night secretly. But this is why you should be doing it on company time. First of all, there's the bus factor. If you haven't heard of it, it's the rather morbid term for how many people can get hit by a bus and have your company still function.

Speaker 1: There's also the term unicorns, which are they're very rare people who do exactly what your company needs to happen. They're called unicorns because they're almost impossible to find. So I say you should start as a horse, like start working on growing your horn. So this is kind of my history of when I've learned different things. In school, I did Java and C and Visual Basic and MIPS. And since then I've used none of those. Surprise, surprise, I don't use OCaml if if I'm bright. Um my first job, I started learning HTML and CSS and C sharp. And I have not used C sharp since then. And then at Eventbrite, I started with JavaScript and Python.

Speaker 1: And surprise, you actually need more than just those things to do your job. So you start learning a couple other things. I started working on our search team and learned solar. And then really you need also some Cassandra and some Redis and you pick them up one by one. But it's not just the technologies, it's not just the languages. It's also all the other tools you need to do your job. It's Vagrant, it's Docker, it's your text editor. All these other things take time to learn, and you can't just do it instantaneously. I also think learning at a company is actually really awesome. So, for one, you have people to talk to. There's probably somebody there who knows what you're trying to learn.

Speaker 1: And it makes a lot of sense to be able to go and talk to them instead of finding somebody randomly online, like be on IRC, and be like, are they going to hate me if I ask them this really beginner question? There's also a framework already in place. It might be great, it might be bad, but the last time I did a side project, I took three days setting up my environment and all the technologies I needed. So, and that was knowing how to do all those things. So just skipping past all of that, land in an environment that's already set up. It's really useful. You can figure out the other things later. You're doing something that's useful. If your company's successful, or if you're not, then you're trying to make them successful. It's something that's a product, it's gonna get used. It's probably live.

Speaker 1: And probably the most important thing, you can't give up. If you're working on something as your side project, you can't, you can just be like, oh, I have these other things to do, I guess I won't work on it today. If you're making something for your company, You have to continue making it. You can't just be like, oh, it's too hard. I guess I'll stop working on this now So, how do you do it? And I guess in the schedule, the title of this was actually How I Learned Django at Eventbrite. And the talk is actually more about how anyone learns anything at any company. But this is kind of my strategy of how I did it. And there's definitely lots of different ways. People might have different strategies, but hopefully

Speaker 1: it's useful for someone. So what I always have to do and I always have to remind myself to do is do one thing at a time. That giant list of things to learn, don't try to do them all at once. Do one of them But similarly, if you know Django really, really well and you keep getting projects at work that are doing Django over and over. Maybe expand your horizons. Maybe try and work on something where you don't know anything. Really try and work on something where you're learning one new thing. But you can talk to your manager, you can talk to different people and say, do you need help on that? Do you need help with your Go project? Do you need help integrating Postgres

Speaker 1: into Django? And you can learn new things that way. I'm not sure if anyone in here is a manager or a tech lead or a senior engineer or really anyone who is making schedules and telling other people what they should be doing. This is actually your job. Ideally, people are gonna be coming and saying, I would love to learn more about JavaScript. But they might be quiet. So if you're telling them what they should be working on, maybe see what they're interested in. Try to introduce to them new projects Maybe there's a perfect bug that's a great introduction to something new and it needs to get done and only one person knows how to do it. Don't give it to that one person.

Speaker 1: Give it to somebody else. So when I was in the Peace Corps, my title was teacher. I had classrooms of 80 students, which is not efficient at all. But we did a lot of classes on pedagogy and how to teach and how to learn And there's a lot of different strategies, but a lot of people talk about visual, auditory, and kinesthetic, which isn't actually true, but humans love categorizing, so we're gonna go with it. And you might recognize one of these as how you learn. You might say, oh yeah, I'm definitely an auditory learner. I can stare at something for days and have no idea.

Speaker 1: But if you're a visual learner, some different ways that are really good to learn are pair programming. Maybe it's as an observer, you should also participate as well, but figuring out how somebody else is doing it. You could read books. You could read the documentation. You can read source code. Something I've noticed that more junior engineers have trouble with is diving into the source code because it seems complicated. But that's one of the best ways to figure out what's going on. Especially if there's some behind-the-scenes magic. You could Google it, you could ask around, but the fastest way and the best way is probably to go and look at the source code. You can also watch seminars online. There's Udemy and Cotton Academy in so many different awesome ways.

Speaker 1: So I have stacks of textbooks. They're fantastic. They hold up my desk. I read them very rarely. I think once my internet went down and I was actually trying to do something with an A-star algorithm, so I looked it up, but that was really weird. My roommate, on the other hand, will order basically a new textbook once a month and actually read it. I don't know how he does it, but that's not me. Auditory learners. They come to conferences. They do online classes. Most importantly, talk to people, ask questions. And kinesthetic learners. If you don't remember hearing about auditory, visual, kinesthetic, kinesthetic means touching things, like actually physically doing things with your hands.

Speaker 1: So if you're a kinesthetic learner, which is most people, hack on projects. Maybe follow some tutorials online. The things that I always do are post-it notes and whiteboarding. We have some giant whiteboards on our walls that I'll take over and scroll all over them. It's kind of frustrating actually when I'm working with people in our national office because then they'll be like, wait, what's in that corner? The light's not hitting it. But I also used to have two monitors, and my second monitor was only used as a place to put post-it notes, which really annoyed my coworkers, so they got me a whiteboard for behind my desk. The most important thing to note here is that no one is only using one. Everyone needs a bit of all of these things. So

Speaker 1: start with what you works best for you. Maybe start on that tutorial. And if you get stuck, maybe go and talk to somebody. So, some tips for working with other people. The two dogs here: the brown one's my dog, the black one is Cleo, they're best friendemies. Sometimes they will curl up and sometimes they'll attack each other. It's kind of who knows. We have to coordinate who comes into work. But they're kind of representative. So The best way is to find somebody whose style compliments yours, somebody who you're comfortable asking questions to. But maybe that person doesn't know everything. And so maybe there's that one person in the corner who you think is gonna bite your head off if you talk to them.

Speaker 1: So, how you go to that person, because odds are they're actually not as scary as you think, some really great ways are to schedule time on their calendar. Don't come and interrupt them in the middle of a problem, but be like, hey, I'm trying to figure this thing out. Can I talk to you at three o'clock? Because I see you don't have anything else to do, man. Don't say it like that. They probably have things to do. You can also talk about what you figured out on your own. If you come to them and you say, hey, what's a model in Django? They might be kind of annoyed. They shouldn't be, everyone should be nice and ponies and blissful. But if you come to them and say, hey, I read the documentation about what a model does, and this is my problem right here. So I'm trying to figure out the best way to implement

Speaker 1: Um passcodes on the model. Do you think it would be better this way or this way? And it gives them a lot better foundation of how to help you and where to go. And there shouldn't be any resentment there. Another cool thing to do is if they're one of those people who, let's say they're the only one who knows anything about your payment system. And so therefore nobody wants to bother them and they're always busy fixing bugs on the payment system. You can go and talk to them and say, hey, I see you're really busy. I see there's this bug. I could fix this bug. Could you help me? And then there's no way that they can really say, no, I don't want to do that. Because you're helping them.

Speaker 1: So what should you work on? So yeah, it's your job. Sometimes you have things given to you. And sometimes you might want to work on something different. You might want to learn something new. But the best things to do are To figure out what's really important and then talk to your manager and be like, hey, can I work on this thing for a while? And so those things that you should could be working on are what's important to your company? It's a really easy sell to be like, hey, I really need to learn Elasticsearch because our search needs to get better and no one else knows how to do it, so can I work on it? They're a lot more likely to say yes than if you're like, hey, Elasticsearch is really interesting to me and I'm working on it on my side project and I'm starting a startup

Speaker 1: and hey, can I just like take a couple days to learn it Which they're more likely to say no to. Um and another thing is what do people complain about? Are the admin tools really bad? Are The SQL query is really, really slow. Maybe you don't know anything about SQL, but you know that every day your admin is complaining about this One query and it's really slow and everyone's way too busy and everyone's avoiding it. And it might be because there's tricky things that you don't know about, but whatever, jump in. Take that query and say, I want to make this better. And you'll make a lot of people happy. And people will also be really willing to jump in and help you because it's something that's a pain point for a lot of people.

Speaker 1: So, you have all these things you want to learn. How do you do it? You have your job. How are you still being productive while you're doing it? Something that's really important is to time box. Don't spend a week reading a textbook about something. It might turn out that your textbook is about Cassandra and then you're like, oh wait. Redis would be better. And then all of your time is not wasted, now you know about Cassandra, but not relevant. You're not being productive. So give yourself some time. One of the f my favorite rules that somebody gave me early on is that if you work on something for an hour and you haven't gotten anywhere, then you should go and talk to somebody.

Speaker 1: You should try and tackle it first yourself, because it helps you learn better. But anything longer than an hour, go and get help. Prioritization is really important. Maybe Elasticsearch is more interesting to you, but for your company, making that SQL query faster is much more important. Prioritization is a really hard problem. It's not going to be solved in one bullet point, but try and think about it when you're working on different things. What's most important? You should be doing that. You should not be turning videos of your dog into gifts during work. I would never do that. Another trick that doesn't really fit into time management, but that has really helped me, is to leave comments in the code when you take a break.

Speaker 1: So it often takes me a long time to context switch. I'm working on some code. People are like, oh, let's go get some boba. You'd be like, yeah, it's really nice outside. Let's go outside. And then you come back. You're like, wait, what was I doing? And then it takes you a really long time to figure it out. Or you might even have a file open. You're like, where in this file was I? So I always leave comments. And sometimes they're inane. Sometimes it's like I was turning the color of this line from blue to red. And you're like, no, no, I'll remember that. Pro tip, you won't. So after you've learned everything, after you know everything in the world, as you're going to in the next month, how do you remember it?

Speaker 1: Write it down. So I'm constantly taking notes. And you can also be writing documentation. You could be writing bug reports. Maybe you are just getting your dev environment set up and it's taking you a really long time, and you think it's because you have no idea how Docker works, and then An hour in, you go and talk to somebody, and they're like, oh, you don't have this package installed. You're like, wait, I just spent so long trying to re-download it and it's just failing. That's probably because the documentation's wrong. And so either you should go and fix it, or you could write a bug report.

Speaker 1: Maybe there's actually an error somewhere that should get fixed. For lists, I basically always have at least two lists going on. One is what I've already learned. So as I'm going through the week, I really like to be like, today I did I figured out how to turn videos into gifts. It was great. And then you'll be able to figure out in a week or two when you need to turn more videos of your dog into gifts. How to do it. You don't have to go through the same process of Googling because it's really easy to forget. You do something one time and you're like, I'm done. And then you need it again in a week.

Speaker 1: Something that I actually did when I joined Evemprate is I had this secret Google Doc where I wrote tips. I was like, this is how I run the server. This is how I index search. And I thought this was really embarrassing but I couldn't remember how to run the server or get my development environment up, so I didn't tell anyone about it. And I had the secret document And then I realized a couple months later that everyone has these secret documents. So ideally it'd be shared. Or maybe it's just a reminder that it's not that embarrassing. Not every company has their dev environment set up the same way. So just because you don't remember RS, I know it's only two keystrokes. If you forget it, it's fine.

Speaker 1: Maybe that's not how you did it before. So it's great documentation for the next people. That secret document of mine helped when somebody else knew joined because they'd be like, wait. How do I get the dev server up? How do I make it stop threading? You'd be like, oh wait, I remember all these things because I have this not secret document anymore. I'm sharing it with all of you. It's documentation. It's also really great to be able to say, hey, look at all these things I've learned. Especially if you're in the process of learning lots of new things. It's really easy to get frustrated. You might be like, I've done nothing this week. I have all these tickets. I've accomplished nothing But if you look at your list, you could say, oh, I

Speaker 1: figured out how to make SQL queries faster, and I figured out how to write in Cassandra, and I've done this tutorial, and I've read this textbook. So, yes, you still need to be closing tickets, but it's really good to be reflective and say, what have you done? What do you know now? And also to communicate that with people. It depends on how your company's structure is set up, but if the main record of progress is like how many tickets you've closed and you've been spending all your time learning, maybe your manager doesn't know what you've been doing. So communicate that to them. Say, hey, these are the things I've done. Look how awesome I am. It's also really great because when you're in that cycle of learning and figuring things out

Speaker 1: You probably have your confidence being lowered. You'd be like, I don't know anything. Your imposter syndrome is going to be hitting pretty hard. If you have it. But when you look back, you can be like, oh, no, I definitely know Django. Like, I have that going. Just because I don't know how to write Go, that's fine. I know this other thing. My second list is what you want to learn. So when you're trying to figure things out, it's really easy to go down that rabbit hole. to go down that spiral and say, there's so many cool things here. Like I was reading this tutorial and it said how I could do multi-threading and I said how I could do like make a chat program in line. You're like, I'm really gonna follow that. Then it's like, oh wait, no. Like I really just need to be figuring out how to put words on the screen.

Speaker 1: But you do want to do this eventually. So put that down as something you want to do later. Let's say you're figuring out how to write SQL queries and you're reading some Stack Overflow answer and it has a link and says, yeah, that's a good enough solution. But if you want to make it a hundred times faster, you should do it this way. Then maybe you really want to click on it and be like, ooh, how do I go down that rabbit hole? But you should probably put it aside. If it's not immediately relevant, I would put it on this second list. And be like, hey, this is what I need to go and do later. Generally, I figure out how to go back to those when I have that problem again. Maybe I need to make a SQL query faster. It's like, oh yeah, that other time I needed to learn it too. So it's probably something that's really valuable and not just a trendy new topic.

Speaker 1: I also know that if I don't write it down, I'll get really angry at myself for not following it immediately. So it's kind of like a no, I've acknowledged it, it's there, I don't need to do it right now. I'll do it someday. And the best way to learn is actually to teach. So people often will think, I just learned this. I am not a good person to teach it. The people who are best to teach are the experts, the people who have been doing it forever. And that's a blatant lie. The people who are best at teaching new people is the people who have just learned it. And a lot of that is they just went through it. They remember what was frustrating. They remember what was hard.

Speaker 1: There's also the pro that sometimes the all the setup stuff around teaching is the complicated thing. And somebody whose dev environment has been set up for months is not going to remember. So there's lots of things that I've talked about. You should figure out what works for you. There's lots of different things. You should take the time to learn. It's really important. No one should ever be able to say, don't do that. Especially if it's not a priority for your company. I've been really fortunate that Eventbrite has been really flexible. They've said, you know nothing about search and you're a JavaScript engineer. Have fun. Which I don't think is actually normal. But there's all these tricks that you can do. You can say, hey, this has been really hard for people.

Speaker 1: There's this one person who's the only one who knows this. And so if he got hit by a bus, like would be out of luck. But if I learned it, then I'd be able to help them. But most importantly, again, is to have fun with it. Learning should be fun. It's one of my favorite things about computer science, there's lots of different things. You could be doing anything. So don't get too caught up with frustration or by saying, I don't know anything. to have fun. And that's it. This is kind of what's worked for me and what's worked for people who I've talked to. But if you have any other tricks, I want to know them. I want to add them. I want to help people. So Tell me, please. That's it.

Speaker 2: What was your first project at Eventbrite? Or your your first Django project?

Speaker 1: Yeah, my first Django project was actually making our Teams feature. And It was really interesting because I had been a front-end engineer and I was really good at JavaScript and CSS and they were like, ooh. We have to start this project. You're being paired with a senior engineer who knows everything about Django. So you'll do the front end and he'll do the back end. Like cool, no problem. And then there were some critical bugs that he had to go and fix and I had nowhere to start. So he's like, hey, how about you just set up the models for this? It's like models. What what does that mean? He like sent me a document and I started writing them. And he would review all my code, but he was actually very busy on other things, and I ended up writing most of that project. So that was really useful.

Speaker 2: Did it go into did it go into production?

Speaker 1: It did. It is live. It is used by Tough Mutter, which is one of our biggest clients. So if you've ever signed up for Tough Mutter, you've used my code.

Speaker 2: Well also, do you have any advice for uh this is more like a let's say that you don't you're in a situation where your job isn't so flexible and you know you've I mean besides get another job. Uh but I mean how you navigate that like if you want to work on something else and maybe your manager's not really amenable to that and you could always get another job. That's I've been I've been in this position and I got another job. Um what's your advice there? Because that can be tough.

Speaker 1: Right. It definitely can be tough and I don't want to be like quit like you said, but there's different things you can do. You can try and talk to another team. If there is maybe there's another team doing something that's really interesting to you. And you can be like, hey, can I work with you? And maybe you're Structure, you're a direct manager probably wouldn't like that too much, but maybe it'd be okay to switch teams and do something more interesting and get a manager who's more flexible Or just try and say, okay, there's this project we need to work on. Can I do this part of it? And just kind of like slowly shift. So something that I had initially done when I was really interested in search. is I was doing the front end and I was like, oh, maybe I can just add this new field to the database. And they're like, no, no, we're busy. And then they're like, wait, we're busy. So yeah, you should do that.

Speaker 1: Go and do it. And so I did, and it was great, but I just kind of had to poke at it for a long time. And then we had some shuffling and I got a new manager and he was like, wait, you're kind of interested? Like, yes, it's yours now, and threw it all on me So some of it's like a slow progression and sometimes it's dumped on you and it's great.

Speaker 3: Uh you mentioned that you had uh like your own secret notes file and then everybody you discovered everybody had their own secret notes file. Um What's been your experience with having sort of like a a company wiki or a team wiki just to collect all this knowledge? Um has uh have you had like one person sort of in charge of that or is it just l left up for everyone to sort of organize or does nobody actually contribute and is it's just an empty wiki? Just what's been your experience?

Speaker 1: So we have engineering documentation and it's fantastic. When I first started, it was actually very difficult to edit. Like you had to check out the repository with all of it. You had to make your changes, you had to commit your changes, and then if there was any formatting that was wrong with your restructured text, it would send this giant like blaring email to all of engineering being like the build failed, like the build failed. And so people were really intimidated and for some reason didn't want to modify the docs. So I think one of the best things we did there was actually just add a little edit link so you could directly edit it. Um, and then we removed that really horrible email. And so it became a lot easier for people to go in and change it.

Speaker 4: In a past life I used a IDE called Eclipse. You might have heard of it. It has one killer feature and anywhere you type in to-do and all caps, the string that follows it is uh captured and put into a list in another pane buried somewhere in the app. But you can find it if you look hard enough. And then there's your entire to-do list across all your projects. I wonder is there anything like that that you've run into for Python? Because it seems that that seems like it that's I would use that exactly for the situation of okay I'm walking away I need to write a note.

Speaker 1: Yeah. Um that's one amazing. And I don't do things that complex with my TDO. It's more like this is the last thought I had, I'm shoving it in right there. But I also use notes, embarrassingly enough, where I keep a lot of my lists. So that's kind of the equivalent. I'm not sure, does anyone else have an answer to this that I could also benefit from?

Speaker 5: tag in mind with to do. If I if I need to do to do something, I put a to do in front of the comment and then I just go search for that.

Speaker 1: Okay, so you search, do like a global search for all your to-dos. Essentially yes. Okay. So one Yeah, Sublime is a plugin.

Speaker 5: That's that's what I use. So yeah.

Speaker 1: So your answer there is Sublime has a plugin.

Speaker 5: Yeah, basically, yes So no plus yes and

Speaker 1: one. Does PyTarm have anything?

Speaker 5: Yeah, PyTarm looks first thing.

Speaker 1: Okay.

Speaker 2: PyCharm looks for to-dos too.

Speaker 1: Thank you. Is that it? Any other questions?

Speaker 2: Any other questions? All right. Thank you, Allison.

Speaker 1: Okay, thank you.