LLM Zoomcamp: Free LLM engineering course. Register here!

DataTalks.Club

Articles Slack Events Podcast Books Courses

From Hackathons To Developer Advocacy

Season 20, episode 8 of the DataTalks.Club podcast with Will Russell

Links:

Did you like this episode? Check other episodes of the podcast, and register for new events.

Transcript

The transcripts are edited for clarity, sometimes with AI. If you notice any incorrect information, let us know.

0:00 Introduction, career journeys, and video setup and workflow

Alexey: This week we’ll discuss many topics—developer advocacy, organizing hackathons, and Will’s career journey. (0.0)

Alexey: I’m going off script because we have a special guest, Will, whose career we will explore today. (0.0)

Alexey: If you took our recent data engineering course, you probably know Will, a developer advocate at Kestra, a workflow orchestration platform. Will led module two on workflow orchestration. (0.0)

Alexey: Previously, Will built open source education programs to help developers make their first contributions to open source. He creates technical videos and documentation. (1:40)

Alexey: Today, we’ll talk about his work. Welcome, Will, it’s a pleasure to have you. (1:40)

Will: Thank you for having me. I’m excited to dive into what you just discussed. (2:42)

Alexey: The questions for today’s interview were prepared by Johanna Byer—thank you, Johanna, for your help. (2:49)

Alexey: I want to go off script a bit at the start. (2:49)

Alexey: We always ask about the career journey, but I really like your videos. (2:49)

Alexey: During the data engineering course office hours, if you haven’t checked the course yet, you still can—even though it’s finishing, module two about Kestra is available. (2:49)

Alexey: I really like the quality of your picture and all the little things in your background, the microphone, and the headset. (3:21)

Alexey: Tell us about your setup. How did you achieve such good picture quality? (3:21)

Will: My setup has evolved slowly over the years, especially since COVID when everything went online and people started making nice setups. I thought that was cool. (3:44)

Will: We’ll talk more about how I’ve been making videos in different forms for a few years. (3:44)

Will: I decided to learn photography and got a Sony mirrorless camera with an HDMI output. (3:44)

Will: I use a simple prime lens, which gives a nice blurry background. The camera is plugged into my laptop and appears as a webcam, making it simple. (4:09)

Will: What makes video look good is not the camera, but the lighting. (4:09)

Will: I have a nice light off to the side, which lights me up, and some lights behind me to separate me from the background. (4:09)

Will: Because the background is at a 45-degree angle, it creates depth and makes it feel more professional. In reality, the camera is clamped to the back of my monitor, so if I shake my desk, the camera shakes too. (4:34)

Will: The key is to make recording videos for Kestra as frictionless as possible—just turn the light and camera on, and I’m ready. (4:34)

Will: The camera is right above my monitor, so when I do demos, it’s easy to look up at the camera and down at my work. There’s nothing in the way. (5:00)

Will: I used to put the camera on a tripod in front of my monitor, but then I couldn’t see the demo, so I was always leaning around the camera—that was awful. This setup is simple but effective. (5:00)

Alexey: Your voice comes through clearly. What microphone do you use? (5:37)

Will: I have a Rode XLR microphone plugged into a preamp, which connects to my computer. (5:43)

Will: It requires a lot of power, so the closer it is to my mouth, the more radio-style it sounds. (5:43)

Will: I used to keep the microphone out of the shot, but then I lost clarity—people like the clarity of my voice, so I keep it closer now. (5:43)

Will: The big sock helps with pops and crackles, which is not nice for anyone’s ears. (6:01)

Will: This keeps everything looking and sounding clean. (6:01)

Alexey: The hardest thing for me is the lighting. (6:31)

Alexey: Did you experiment to achieve your current setup, or did you learn something specific? (6:31)

Alexey: How did you position the lights? (6:31)

Will: Since COVID, I’ve lived in a few different places with the same desk but different setups. (6:55)

Will: Normally, people think to put the light directly behind the camera or use a ring light, but that loses depth in your face. (6:55)

Will: I learned from photography that having the light at a 45-degree angle creates nice contours and shadows, adding depth. (6:55)

Will: My desk has a spot right next to where my microphone is clamped, next to my monitor. (7:20)

Will: It’s cramped, but it works. (7:20)

Will: I’ve moved the light left and right, and this position lights me up without washing me out. (7:20)

Will: I have a window next to the light, and I used to use natural light, but it’s not reliable, especially in winter when it gets dark at 3 p.m. (7:44)

Will: Now I close the blind and use artificial light, so I can record at any time of day. (7:44)

Alexey: In London, you probably have even less light than we do in Berlin. (8:02)

Will: Exactly. If I open the blind, it lights the background more but puts me in shadow. (8:07)

Will: It’s important to use artificial light so you know what you’ll get from your video every time. (8:07)

Will: There’s nothing worse than one video looking great because the natural light was perfect, and another looking dark because the sun set. (8:07)

Will: This setup is the most reliable. I’ve had this equipment for a few years, and it works well. (8:37)

Will: I could add another light, but I like the simplicity. (8:37)

Will: If people think it looks good, I don’t see a reason to change it. (8:37)

Alexey: Your hobby in photography helped you set up the lights and everything. (9:02)

Will: Exactly. I used to think photography was about buying a lens with a wide aperture for a blurry background. (9:07)

Will: I learned quickly that lighting is the main thing—the blurry background is nice, but lighting makes it look good. (9:07)

Will: I didn’t have a light for a while, and the videos looked better with one. (9:25)

Will: A lot of people could get away with just a webcam and a light, and the quality would improve. (9:25)

Will: It’s not all about the camera—the camera helps, but once you pump it through Zoom, you probably won’t notice much difference over a decent webcam. (9:25)

Alexey: Not mine, but Macs usually have good webcams. My Windows laptop is powerful, but the camera is not great. Anyway, most laptops, especially Macs, do have good cameras. (9:48)

Alexey: We got off script—amazing setup, thanks for telling us. (10:15)

Alexey: I’m tempted to ask about the Lego in your background, but we don’t have time for that. (10:15)

Alexey: If you’re listening to the podcast and don’t see the video, check YouTube to see why I asked Will about his setup—it looks very professional. (10:15)

10:41 From hackathons to open source: Early experiences and learning

Alexey: Back to the podcast. The usual question I always ask at the beginning is for the guest to tell us about their career journey. (10:41)

Alexey: How did you start? What did you do to get to where you are now? (10:41)

Will: It all started just before 2018, when I was deciding what to study at university. (11:04)

Will: I had done some programming, but I wasn’t completely sure I wanted to make it my career. (11:04)

Will: Engineering was also appealing, so I was weighing my options between the two. (11:04)

Will: I got really into programming during a school module and decided that computer science sounded interesting. (11:22)

Will: So, I chose to study computer science at university. (11:22)

Will: I thought I would find my niche and become a software developer, like most people who take that path. (11:22)

Will: What changed things was getting involved with hackathons. (11:46)

Will: I hadn’t really heard much about them before, but I really enjoyed them and ended up going to five in my first year. (11:46)

Will: Later, I got involved in organizing hackathons in my second and third years. (11:46)

Will: From there, I joined organizations that helped run hackathons. (12:04)

Will: During COVID, these organizations started building programs to help students contribute to open source, since many lost their internships. (12:04)

Will: This allowed students to gain valuable experience by contributing to large open source projects. (12:04)

Will: What started as a 12-week summer contract turned into part-time work while I finished my degree, then into a full-time job for about three years. (12:16)

Will: This was not what I expected when I started university—I thought I’d be a programmer, but I ended up in a different, though still technical, role. (12:16)

Will: After several years running open source programs, I still had the urge to move into a more technical role. (12:42)

Will: My work was focused on helping others do technical things and teaching entry-level skills. (12:42)

Will: The idea of developer advocacy came up often, and I met people in that field through hackathons. (12:42)

Will: I started looking into developer advocacy and asked people I met for advice on how to transition. (13:14)

Will: That’s when I connected with Kestra—Anna, our product lead, and I met on LinkedIn. (13:14)

Will: We had a chat, and I learned more about Kestra and what it does. (13:14)

Will: Part of the reason for hiring a developer advocate was to clarify what Kestra is, which wasn’t very clear at the time. (13:38)

Will: I’ve now been in this role for a year as of last week, and it’s been amazing to continue the work I loved in open source while also doing more technical demos and teaching. (13:38)

Alexey: Congratulations on your work anniversary. (14:03)

Will: Thank you. (14:05)

Alexey: We’ll definitely talk more about developer advocacy, but I’m curious about your hackathon experience. (14:09)

Alexey: Would you recommend that first-year university students do as many hackathons as possible, or should they focus more on their studies? (14:09)

Will: The most valuable things I learned in my first year were at hackathons. (14:21)

Will: For example, I learned how to actually use Git, deal with merge conflicts, and get things merged so they work. (14:21)

Will: At university, we touched on Git, but never really understood it. (14:21)

Will: That skill has been very helpful in my career. (14:21)

Will: At hackathons, we worked as a team and had to get everything merged quickly, so I learned those things fast. (14:58)

Will: I also learned how to build real projects, which many of my peers at university struggled with. (14:58)

Will: Often, they understood the concepts but didn’t know how to combine them into a working program and deploy it. (14:58)

Will: Hackathons taught me real-life engineering skills that university didn’t cover. (14:58)

Will: That said, I wouldn’t say university was a waste of time. (15:40)

Will: A lot of the theory is useful for giving you a grounding that self-taught coders might not have. (15:40)

Will: Even if you don’t use everything, it’s helpful to have that context. (15:40)

16:04 Becoming a hackathon organizer and the value of soft skills

Alexey: So hackathons were definitely useful—100% would recommend. (16:04)

Alexey: How did you actually start organizing them? (16:04)

Alexey: You said you took part in five during your first year and learned a lot, but organizing is quite different from participating. (16:04)

Alexey: What did you learn from becoming an organizer? (16:04)

Will: After doing five hackathons in my first year, I definitely felt a bit burned out. (16:56)

Will: I got to know the people who organized my local hackathon and became part of that core group. (16:56)

Will: They asked if I wanted to get involved, and I saw it as a chance to help others and fill in gaps I’d noticed. (16:56)

Will: It was valuable to help more people and learn new skills. (17:20)

Will: People often say that hackathon organizers get a step up in their careers because they learn useful skills beyond programming. (17:20)

Will: Working with others and developing soft skills is very valuable when you’re part of a team. (17:20)

Will: The stereotype is that developers don’t have the best soft skills, though I don’t think that’s always true. (18:10)

Will: Anything you can do to work on those skills is definitely a win. (18:10)

Alexey: The set of skills is different—if you spend time organizing, you might not develop the same technical depth as someone practicing algorithms. (18:17)

Alexey: When I moved from hands-on data science to organizing courses and events, I felt less technical. (18:17)

Alexey: Do you think it’s a problem to lose technical skills as you move into organizing and teaching? (18:17)

Will: That was something I worried about when working on the MLH Fellowship and open source programs. (19:22)

Will: The longer I spent working on them, the less technical I felt. (19:22)

Will: At first, I was content because helping others is rewarding, but over time I felt a gap—I wouldn’t know how to do something difficult if asked. (19:22)

Will: When I started organizing hackathons, I didn’t think much about it because I knew so little then. (20:07)

Will: But after doing it as a career, I definitely felt something was missing, which is part of why I moved to developer advocacy. (20:07)

Will: Even in developer advocacy, there’s a risk of working on tools that aren’t very technical or are too niche. (20:07)

Will: What I like about Kestra is that it’s such a versatile product—I get to touch everything, not just one specific area of tech. (20:41)

Will: It’s a difficult balance, and you have to figure out what you value more: being super technical or helping others become technical. It depends on what matters most to you. (20:41)

Alexey: I guess developer advocacy is a good blend of both technical and non-technical work. (21:09)

Alexey: You can see if you enjoy doing technical work more and slowly move in that direction. (21:09)

Alexey: For example, at Kestra, you could start contributing more to the internal product rather than focusing only on documentation, if that's possible. (21:09)

Alexey: Or, if you enjoy non-technical work more, you could focus on community activities, talking to users, collecting feedback, and similar things.It's a nice blend of both technical and non-technical work. (21:09)

Will: Definitely. The beauty of Kestra being such a small company is that every month is a bit different. With the open source program, we ran three a year, so it became very routine—twelve weeks for the program, a gap, then another program. (22:02)

Will: Some people loved that routine, and I liked it at first, especially when the economy was good and companies wanted to spend money on these initiatives. We created new courses, like a production engineering course and a web3 course, which was exciting. (22:02)

Will: But what I like about Kestra is that I'm not just writing documentation every month. (22:02)

Will: For example, we did the Zoomcamp in January, which was very different from what I was doing in March. If I worked at a bigger company with a large developer advocacy team, I might have a more specialized area. Here, the variety allows me to do more technical work if I want, or focus on community-oriented work if I prefer. It's a nice blend, and I can lean into one or the other as I like. (22:02)

23:18 How to organize a hackathon, memorable projects, and creativity

Alexey: I still see you helping our course participants—your user picture is still in our Slack. Thank you for doing that. (23:18)

Alexey: I want to go back to hackathons. Let's say I want to organize a hackathon—actually, this is not hypothetical, because we want to organize one in DataTalks Club. (23:18)

Alexey: How do you actually do this? What should I consider? What are the moving parts? How do you come up with ideas? I want to organize one, but I have no idea what to do. (23:18)

Will: A hackathon has a few key parts. The first is the building part, where participants actually build their projects. The other key part is the demo or presentation. (24:05)

Will: When I was a student, our hackathons were usually 24 hours, with one overnight. (24:05)

Will: You would either demo on stage, or there would be a science fair style setup with tables and judges walking around. (24:05)

Will: If you're doing it online, it’s much easier—you don’t need to find a venue or organize catering. (24:42)

Will: I did more online hackathons, especially after the pandemic started. (24:42)

Will: For online events, having a good community space is important. You have Slack, which is great, and Discord is also popular. (24:42)

Will: We used to run lots of online workshops during hackathons, but now there are so many resources available that engagement is low. (25:06)

Will: Instead, it's better to be helpful in Slack and host office hours where people can discuss their ideas. That’s more useful than running lots of workshops. (25:06)

Will: On Sunday, you have the judging part, which is the hardest part to organize, especially online. (25:26)

Will: You can either organize judging and announce winners in real time, which is stressful, or announce winners later, but then you might lose engagement because people move on. (25:26)

Will: For judging, there are matrices online for different categories, and you can weight judges' scores to get a fair result. (25:26)

Will: If there’s a tie, you can discuss and decide. (25:26)

Will: I liked having categories at hackathons. (26:14)

Will: Most hackathons are open-ended, but if you get sponsors, you can have a category like "Best Use of Sponsor Technology." (26:14)

Will: That was one way I enjoyed hackathons—I would look at the sponsors, try their tools, and maybe win a prize. (26:14)

Will: I learned new things and sometimes won cool prizes. I would pick a sponsor tool, think of an idea that uses it well, and try to catch the judges’ attention. (26:40)

Will: I enjoyed that approach. Open-ended prizes can be overwhelming because there are so many possibilities. (26:40)

Will: People often think they’ll build the next Facebook, but then they run out of time and only have a login page that doesn’t work. (26:40)

Alexey: When you were a participant, you looked at the sponsors and their tools, then thought about what you could do with them. It sounds like the problems were open-ended, and the hackathon was just about doing something cool with the available tools. (27:29)

Alexey: Was it like that, or did you have a theme or some direction? (27:29)

Alexey: For me, the problem is that if there are no constraints, people don’t know what to do and the time runs out. How do you deal with this? (27:29)

Will: Open-ended hackathons work well for in-person events because people are committed—they’ve shown up and there’s free food, so they stay. (28:39)

Will: For online hackathons, it’s harder to keep engagement. If things aren’t going well, people can just leave, since there’s no real consequence. (28:39)

Will: Some events have categories like "Best Use of Data" or "Best AI Project." These are broad enough to allow creativity but give some focus. Others are completely open-ended, and you can use sponsor tools. (29:05)

Will: One prize I won was for "Hackiest Hack." We didn’t aim for it, but our project was so barely held together that people said, "This is the most hacked-up thing I’ve ever seen. It’s a miracle it works." (29:05)

Will: That project was called Willmojis. (29:44)

Will: We thought it would be cool to use Microsoft’s Vision API to analyze the emotion in a photo. (29:44)

Will: Then, we used another tool to cut out my face from the photo and turn it into a true type font you could install on your phone or laptop. (29:44)

Will: When you typed the laughing emoji, it would show my face instead of the usual emoji—just like how iPhone and Android have different emoji styles, you could have a Will emoji. (29:44)

Will: We took a lot of photos, figured out the emotions, cut out the faces, and installed them as a font. (30:19)

Will: All the different stages barely worked together. (30:19)

Will: During the demo, the emojis were buggy and didn’t really work, but people were amazed that it worked at all. (30:19)

Will: The idea itself was kind of crazy. (30:19)

Alexey: That is the wildest thing. How did you even come up with the idea to do this? (30:50)

Will: It was very random. (31:04)

Will: I remember Microsoft was sponsoring the hackathon and offered a Surface Go as a prize for the best use of Microsoft Azure. We thought that was really cool, so we looked into what Azure had to offer. (31:04)

Will: By that point, we had done quite a few hackathons and developed a formula for winning: pick a project with a clear scope that processes something and gives a result—nothing too complex, just something that does one thing very well. (31:17)

Will: We thought it would be cool to do something with image recognition. (31:17)

Will: A friend had been reading about TrueType fonts and how you can create them. (31:17)

Will: We wondered if we could use a Linux library to generate fonts in real time and integrate that into our project. (31:17)

Will: All of us had these weird ideas, and we decided to stick them together and see if it worked. (31:59)

Will: The idea evolved as the hackathon went on. (31:59)

Will: We did this at Oxford University, where many people were trying to build useful and impactful projects. (31:59)

Will: Meanwhile, we were being silly with ours. (31:59)

Will: Every time we talked to others, they said, "That's so silly, that's never going to work." (31:59)

Will: But when we demoed it, everyone was surprised and said, "Okay, we take it back. We thought you were just messing around—we didn't realize you'd actually build it." (31:59)

Alexey: But you were still just messing around in the end, right? (32:39)

Will: Yeah, of course. (32:41)

Alexey: But the point is to have fun, not necessarily to have a social impact at the end. (32:46)

Will: Exactly. At a hackathon, the time is so short that it's very hard to have a real impact. (32:52)

Will: The best thing, especially as a student, is to focus on learning new things. (32:52)

Will: In our case, one person wanted to learn about TrueType fonts, another wanted to learn about Microsoft Azure, so we all came out of it feeling good because we got to play with new tools we hadn't used before. It worked out well. (32:52)

Alexey: Was there another Will on the team, or was Willmojis just you? (33:18)

Will: It was me. (33:24)

Will: People saw me taking lots of photos against a white wall, pulling different expressions. (33:24)

Will: We were looking at the emoji list, trying to figure out which facial expressions I needed to make. (33:24)

33:39 Major League Hacking: Building community and scaling student programs

Alexey: Cool. (33:39)

Alexey: Let's talk about MLH. MLH stands for Major League Hacking, right? What is that? (33:39)

Will: Yes, Major League Hacking. (33:46)

Will: MLH started about 12 years ago as an organization to help students run hackathons. (33:46)

Will: Hackathons can be complex, with lots of moving parts, and not every university has experience running them. MLH would provide pre-event support and send a representative to the event. (33:46)

Will: I became friends with many MLH representatives because there weren't many in the UK, so I often saw the same people at different hackathons. (34:12)

Will: Once I started organizing, they encouraged me to apply to become a representative. (34:12)

Will: It sounded great—I could help more people, and travel expenses would be covered, which was important as a student. (34:12)

Will: I applied for the role at the start of 2020, when I was volunteering at many hackathons and judging projects in the UK. (34:47)

Will: Apparently, I had a good sense for what made a winning project. (34:47)

Will: I interviewed with MLH, and they were impressed, but my final interview was scheduled just as the pandemic started. (34:47)

Will: MLH had to figure out how to move from in-person to online events, since their whole business model was built around physical events. (35:12)

Will: After they sorted that out, I finally got my final interview and was offered the job. (35:12)

Will: Unfortunately, there wasn't anything for me to do at first because they hadn't figured out how to train new people online. (35:12)

Will: So, I was just waiting for something to come up. (35:12)

Will: Then I noticed MLH had launched a new program called the MLH Fellowship. (35:43)

Will: Many students, including me, had lost internships, so the idea was to partner with organizations that had open-source projects—like Meta, which has React and other big projects. (35:43)

Will: These organizations could sponsor fellows, and MLH would run the program, providing mentorship and structure to help students contribute to real open-source projects. (35:43)

Will: This way, students could learn how to work on large repositories, not just small personal projects. (36:30)

Will: They could put this experience on their CVs and say they contributed to something like React, and actually built something useful—not just fixed a typo. (36:30)

Will: MLH needed people to interview and vet students for the program. (36:48)

Will: Since I had nothing to do—my university exams were canceled—I volunteered to help. (36:48)

Will: I got very involved, especially with technical interviews, because I had a lot of free time and MLH was still figuring out how to run the program. (36:48)

Will: They asked if I wanted to help out for the summer, working alongside the CEO to figure things out. (37:17)

Will: I thought it sounded great, so what I thought would be a summer internship turned into a part-time job for another eight months. (37:17)

Will: We only planned to run one program, but when the idea came up to do it again, I said yes. (37:17)

Will: I went full-time in the summer of 2021 and worked there for about three years. (37:54)

Will: MLH started as a hackathon company but branched out into developer education, especially for early-stage students who want to become developers. (37:54)

Will: Hackathons are a great way to learn, but the fellowship is the next step—it’s like an internship where you learn valuable skills to help you get a job at your dream company. (37:54)

Alexey: So the idea was to help motivated students who wanted to do something with their time, but didn’t have guidance. (38:29)

Alexey: They wanted to spend their time learning and building something. (38:29)

Will: Exactly. (38:42)

Alexey: You had a bunch of open source projects from sponsors, and you mentored the students on how to find what to work on and how to open pull requests, right? (38:50)

Will: Yes, exactly. We worked with maintainers, who gave us lists of good first issues and valuable tasks. (39:02)

Will: We helped students understand pull requests and made sure they wrote clean code. The main goal was to avoid giving maintainers extra work by submitting poor-quality pull requests. (39:02)

Will: We taught best practices for Git and how to work collaboratively. Many students had never worked in a Git repository with others before. Some were very strong developers in certain areas, like data in Python or React, but didn’t know how to contribute to a larger project. (39:40)

Will: Many students were overwhelmed by the size of open source projects. (40:16)

Will: We taught them not to try to read the entire codebase—just focus on the part they were contributing to. We started them with small issues and gradually ramped up to more substantial contributions over the 12 weeks. (40:16)

Will: Another challenge was setting up development environments. Most students had only used simple Git repositories and virtual environments. Some open source projects have complex setups with multiple stages, so getting used to that was another hurdle. (40:51)

41:16 Mentorship, development environments, and onboarding in open source

Alexey: How did you learn to help students set up development environments for these projects? For some projects, setting up the environment is not trivial. (41:16)

Alexey: I remember trying to prepare the environment for TensorFlow—it felt impossible unless you worked at Google. They use tools like Bazel and CMake, everything is written in C++, and in the end, I just gave up. I thought, "Do your own thing," even though I was an experienced developer. (41:16)

Alexey: How did you learn these things yourself? Did you work closely with maintainers to understand the setup before helping students? (41:16)

Will: The students were organized into small groups called pods, about ten students each. In the first cohort, every pod had a team leader, usually a senior engineer mentoring as a part-time, evening activity. Later, we transitioned to a student-led model, where previous fellows would lead the groups, supported by a group of mentors. (42:23)

Will: We worked with maintainers before the project started to understand setup and requirements. (42:46)

Will: They would show us how to get the project running, and we’d turn that into resources for the students. Sometimes, maintainers would run workshops for all the students, and our team would help them follow along. (42:46)

Will: Some projects were straightforward, but others were difficult. Maintainers were usually understanding, especially if their own project was hard to set up. Over time, we tried to target projects that were more accessible, because students often didn’t have powerful computers. (43:10)

Will: With AI projects, students often lacked enough memory or GPU power, so their computers would crash. We provided cloud VMs or encouraged them to use Google Colab to get around hardware limitations. Data projects were always the hardest because of the computing requirements. (43:40)

Will: As time went on, we avoided projects that were too difficult to set up. For example, Meta has many projects, so we could ask them to switch to something more accessible. (44:12)

Will: But some companies, like one that used Apache Airflow, insisted on their chosen project, and students contributed to specific open issues. Maintainers appreciated getting contributions without extra work, but it was always a balance. (44:12)

Alexey: Not having a powerful enough computer brings back memories for me. I remember trying to compile TensorFlow—my computer couldn’t even handle the compilation, let alone run the model. (45:11)

Alexey: I had to rent a machine on AWS with 32 or 64 GB of RAM just to compile it. Is the MLH Fellowship program still running? (45:11)

Will: Yes, it still runs, though I haven’t been involved since 2023. It runs three times a year. (46:02)

Will: Before I left, I helped make the program more repeatable and structured. It hasn’t expanded much, mainly because companies have cut budgets for open source initiatives due to economic changes. (46:02)

Will: There might be more AI-focused programs soon, which would be exciting. It's great to see students posting on LinkedIn about finishing the 12-week program and contributing to projects like Airflow. We also worked with the Pallets project—Flask and Jinja—and some students even became maintainers. It was rewarding to see people go from contributors to maintainers and realize how powerful open source can be. That outcome was beyond what we imagined when we started. (46:37)

Alexey: Do you have to be a student to take part? I know Google Summer of Code used to require students, and I missed my chance after graduation. Is it the same for the MLH Fellowship? (47:29)

Will: Previously, we required participants to be students, since most of MLH’s community comes from student hackathons. (48:10)

Will: However, we eventually opened the fellowship to anyone. Some people joined while working other jobs and wanted to change careers—they learned Python part-time and passed our technical screen. (48:10)

Will: We can’t teach you to code from scratch, but if you have a basic understanding, we teach you how to contribute to open source. Some career changers did the program part-time and were often the most motivated and successful students we saw. (48:39)

49:14 Developer advocacy, content strategy, and video tips

Alexey: We're coming to the end, which is sad because I wanted to talk more about developer advocacy. Let’s spend the last ten minutes on that. What do you do as a developer advocate? What are your main responsibilities? (49:14)

Will: We recently hired a technical writer, which has made my life easier. My role involves teaching users about Kestra. Workflow orchestration is complex, especially with a tool like Kestra, which can be used in many different ways for various use cases. If people don’t understand it, they won’t use it. (49:41)

Will: I started by improving documentation and creating videos to teach people how to use Kestra and understand its purpose. That approach has worked well. Now, with our technical writer AJ—big shout out to AJ—I can focus more on videos and educational content. (50:14)

Will: My focus this year is to teach the fundamentals of Kestra and show how to implement typical workflow orchestration use cases. (50:37)

Will: I also create content about tools that work with Kestra, like Postgres, and demonstrate interesting use cases. My role has become more focused on outreach and education. (50:37)

Alexey: I think what you do is really cool. Some people who create content, especially videos, prefer to write a script first and then create a video from that script. For others, like me, it's easier to just record the video directly, since writing is more difficult. (51:15)

Alexey: Which approach do you use? (51:15)

Will: I definitely lean more toward your approach. I make rough bullet points about what I want to achieve, get a working demo, and then press record, roughly following my bullet points. (51:49)

Will: Sometimes I've written blog posts or turned other people's blog posts into videos, but I find that following a strict script feels unnatural for me. (51:49)

Alexey: Now that you have a technical writer on your team, you can make a video from bullet points, and the tech writer can help turn that into written content, right? (52:25)

Will: Exactly. We just had a release last week, and we worked together to figure out how some of the new features worked. He wrote the documentation page, and I made a video to showcase it. (52:43)

Will: Sometimes he creates the documentation first, and I use that as a basis for a video, or I create bullet points for him to expand into documentation. It's good that the video doesn't exactly follow the documentation, because otherwise it would be boring. The video should offer something extra that the documentation doesn't. They both have their own purpose. (52:43)

Alexey: Do you have a good recipe for making a good video? (53:33)

Will: The key thing is to have a clear goal—what are you trying to achieve with the video? Is it to showcase a feature of Kestra or to teach about a new tool? If you don't have a clear goal, it's easy to make the video too long or go off on tangents. If I don't understand the goal from the beginning, how will the user? (53:40)

Alexey: So you open a document and write down the key goal for the video. For example, you posted about a new release of Kestra with some features. Let's say you need to make a video about one of these features. Can you give an example? (54:09)

Will: One of the features was a new workflow component called "after execution." My main goal was to explain why we added this feature and why it's useful. On its own, it just runs once an execution is finished, but the value is that you can use it to send notifications with the actual status of the workflow. (54:30)

Will: If the workflow failed, it will say "failed," whereas if it runs during the workflow, it will say it's still running. So I put myself in the user's shoes and think, "Why is this useful to them?" I build my examples around that goal. (54:30)

Alexey: So you prepare a document, or maybe just keep it in your head, with the goal to showcase the new feature. Then you think of a good example, like sending a Slack or Telegram notification, and show exactly how to implement it. Is that right? (55:32)

Will: Exactly. When making guide videos, I don't like to cut corners. I show everything from step one to the end result. I find it frustrating when technical videos skip steps, like setting up Google Cloud, and just assume you know how. (55:56)

Will: I want to show the whole process, from opening Google Cloud to connecting it to Python, so viewers aren't left confused. At the same time, I keep a good pace, because on YouTube, pacing is everything. (55:56)

Will: If a video is too slow, people tune out and the video doesn't do well. For example, our installation guide for Kestra on Google Cloud is 15 minutes long, which is reasonable. If an installation video is an hour long, people won't even try the tool. (55:56)

57:16 Will’s current projects and future plans for content creation

Alexey: Maybe a last question before we wrap up—what are you working on right now? (57:16)

Will: We've started a new "Learn with Kestra" series focused on demoing tools that Kestra works with. Instead of making videos just about Kestra, we make videos about other tools and then show how Kestra can be useful with them. (57:22)

Will: For example, we did one on Docker—explaining what Docker is, why you might use it, and how to run containers with Kestra. We did the same with Git. These aren't always the best examples of workflow orchestration, but I'm planning one on Postgres soon, which is a great use case. (57:22)

Will: People want to automate querying and loading data into a database, so I'm looking forward to making those examples. (57:22)

Will: The start of the video won't talk about Kestra—it will teach why Postgres exists and why it's popular. I'm hoping to expand to other tools, like cloud platforms such as Google Cloud and AWS. So far, these videos have done well on the channel. I'm also working on a video about UV, a new Python package manager. I like to try new things to see if they're just hype or actually useful. It's fun for me and for the viewers. (57:22)

Alexey: I just went to YouTube, typed "Kestra" in the search box, and found the channel. (59:14)

Alexey: If you want to see Will talk about these features, do the same and hit the subscribe button. They need more subscribers, and Will's content is awesome. (59:14)

Alexey: You'll learn a lot by watching. (59:14)

Alexey: Maybe the last thing—do you have any book or resource recommendations for the listeners? (59:38)

Will: When I was at the fellowship, managing a group of student leaders, I felt overwhelmed and unsure if I was giving enough support, especially early in my career. (59:59)

Will: Someone recommended the book "Turn the Ship Around." It's about leadership styles on a Navy ship and how to empower people to lead themselves, rather than just follow commands. After reading it, my team felt more empowered, open, and honest. If you're working with volunteers or community members, it's a great read for anyone who wants to be a better leader. (59:59)

Alexey: Thank you, and I hope you forgive me for keeping you four minutes longer. Thanks a lot, Will—it was amazing talking to you.Thanks for sharing your stories and insights and for the recommendations. I'm sure many listeners will find them useful. (1:01:29)

Alexey: Thanks, everyone, for joining today. I hope you had as much fun as I did. (1:01:29)

Alexey: Thanks, Will, thanks everyone, and we'll see each other soon. (1:01:29)

Alexey: Have a great day everyone! (1:01:29)

Subscribe to our weekly newsletter and join our Slack.
We'll keep you informed about our events, articles, courses, and everything else happening in the Club.

DataTalks.Club. Hosted on GitHub Pages. We use cookies.