The freeCodeCamp Podcast

In this special crossover episode, we celebrate 10 years of The Changelog. It's the home of the biggest podcast focused on open source, and a favorite of freeCodeCamp founder Quincy Larson. This 4-hour episode is actually 2 interviews: 1. For the first 2.5 hours, Quincy interviews Changelog co-hosts Adam Stacoviak and Jerod Santo about how they got into software development and podcasting, and the history of their legendary podcast. 2. Then we end with Adam and Jerod turning the tables and interviewing Quincy about the past and future of freeCodeCamp.org. If you haven't heard of The Changelog before, it is website that hosts a podcast about open source software. Each week they interview new developers from around the software galaxy and explore what makes those projects tick. Adam Stacoviak founded The Changelog exactly 10 years ago. And Jerod Santo joined as co-host 7 years ago. Together - across 370 episodes - they've interviewed everyone from programmer legends, to the maintainers of open source projects you may have never even heard of. Quincy has listened to hundreds of The Changelog episodes over the years, and credits The Changelog with giving him such a broad view of open source, and the philosophies of the developers who started these projects. These interviews were conducted in-person in Adam's Houston-based studio. If you haven't yet, you should subscribe to The Changelog podcast. They have a variety of shows. We recommend starting with their Master Feed, which lets you explore all of their shows: https://changelog.com/master And check out the special website they built to celebrate their 10 year anniversary: changelog.com/ten Follow Adam on Twitter: https://twitter.com/adamstac Follow Jerod on Twitter: https://twitter.com/jerodsanto And Quincy is: https://twitter.com/ossia

This week, for the last podcast episode of 2019, Abbey chatted with freelancer and content creator Jessica Chan - known as CoderCoder on social media - about how she got into tech and started her educational website and YouTube channel.

Quincy interviews Jeff Meyerson, the creator and host of the Software Engineering Daily podcast. Jeff grew up in Texas, played competitive poker, and ultimately worked as a software engineer at Amazon. We talk about how he got into tech, how left Amazon to become an entrepreneur, and the many lessons he learned along the way. Follow Jeff on Twitter: https://twitter.com/the_prion And subscribe to software engineering daily: https://softwareengineeringdaily.com

In this week's podcast episode of the freeCodeCamp podcast, Abbey chats with Harry Wolff, an engineering manager at MongoDB in New York City. Harry has been in the world of tech for over a decade, holding jobs in various startups before ending up at Mongo. They discuss his journey to his current managerial role, what it's like to work at Mongo, how to start a meetup, and dos and don't for migrating from legacy codebases. Harry started his tech career working for startups. He liked the excitement, he liked learning new things, and he liked showing off his skills. After working for a few startups, he stumbled upon a position at MongoDB. One short week after beginning the interview process, he was in. The decision to leave his previous job was easier than he expected, and he reflected on the reasons he made the change: "For me, it was a matter of taking what I could from my job at the time, but knowing when it was time to move on. One of the ways you know it's time to leave is when the company's getting more out of you than you're getting out of the company." Once Harry was settled in at Mongo, he got right to work. After a couple years as an engineer working on various projects, he achieved one of his major goals and became a manager. Harry and I discussed his relatively new position in detail, and while he's still figuring things out, he has some valuable insights into his transition. "One of the most difficult things about being a manager is that there's no easy way to evaluate the success of your day. There are no milestones to say you've accomplished a lot. You might have a eureka! moment where you figure something out, but you're definitely living in the grey a lot more. Because it's people - they change by the day and hour and minute." But one of the best things for Harry is how much he gets to learn - constantly, from many different people, and about many different things. In addition to reading about new programming languages, discussing what's new in the JavaScript ecosystem in his podcast, and making every effort to stay on top of new tech, Harry has learned more nuanced skills as well. "One hard skill I needed to learn was being assertive and truthful when I needed to be. Most humans prefer that uncomfortable situations just resolve themselves...but if you wait six months [to deal with something], it becomes a dealbreaker." In addition to managing his team, working on his podcast, YouTube channel, and blog, and reading programming handbooks for fun, Harry has been working to update MongoDB's tech stack and move away from their legacy codebase. In the process, he's developed some insights into such migrations. "You have to have a good reason for doing it. And part of this is scolding my former self who would say 'yeah, just do it!' But having learned more, you need to have a good reason. For us, it's more maintainable, less error-prone, and better for recruiting." "But don't rewrite everything - that's seldom the right answer. Occasionally there are exceptions, but they're exceptions." When Harry isn't working or creating content, he hangs out with his wife and new son in New York. He encourages people getting into tech to keep at it and not get discouraged.        "Never give up. Just keep hustling. Take with a grain of salt the            feedback you get from companies and have confidence in what            you do and don't know. And stay humble. It's hard but you have          to just want it and keep hustling and stay curious." Find Harry on Twitter here: https://twitter.com/hswolff Find Abbey on Twitter here: https://twitter.com/abbeyrenn

On this week's episode of the freeCodeCamp podcast, Abbey chats with London-based software engineer Linh about how she left the field of biochemical engineering, taught herself to code, struggled to get her first dev job, and now gets to work at LEGO. Linh moved to England when she was 11 years old. She spoke no English, but quickly learned and settled into her life there. She became fascinated with cosmetics and wanted to learn how to create them, so she decided to study biomedical and biochemical engineering in college - she even got her Master's degree in the subject. But something didn't feel right - she didn't have the passion for it she thought she had. So she looked elsewhere. After briefly considering banking, and teaching for a bit, she stumbled into the world of tech through one of London's many fintech meetups. As she started to learn more and meet more people, she realized she'd found her new passion: coding. So she decided to teach herself to code...and the rest is history. Just kidding - but you'll have to listen to find out what comes next :) In this episode of the podcast, you'll learn all about how Linh taught herself to code, how she persevered through a long job search and got her first (and second and third) dev job, what exciting projects she's working on at LEGO, and how she'd advise anyone wanting to break into tech to go about it. Find Linh on Twitter here: https://twitter.com/pinglinh

On this week's episode of the freeCodeCamp podcast, Abbey chats with front-end developer Joe Previte who lives and works in Arizona. Joe shares the story of how he made the tough decision to leave grad school, how he discovered coding, and how he stays motivated and continues to learn.

CS50 is the most popular course at Harvard, and hundreds of thousands of people have taken the free online version of the course as well. We recently posted the lectures for the course on freeCodeCamp's YouTube channel - including the CS50 game development course - all free and commercial-free. During this interview, David Malan and Colton Ogden talk about how they got into technology. They share tips for how to effectively learn computer science, and some advice for teachers and community leaders as well. Colton shares one of his favorite game development hacks, and David tell us the story behind the CS50 catchphrase: "this is CS50" Follow CS50 on Twitter: https://twitter.com/cs50 Subscribe to the CS50 podcast: https://podcasts.apple.com/us/podcast/cs50-podcast/id1459708246 Test out CS50's Integrated Development Environment: https://ide.cs50.io/ And CS50's Sandbox: https://sandbox.cs50.io/ The article Colton mentions about Resident Evil 2 on N64 (PDF): https://twvideo01.ubm-us.net/o1/vault/GD_Mag_Archives/GDM_September_2000.pdf The Steve Ballmer CS50 guest lecture: https://www.youtube.com/watch?v=7lhlKF6MECs And Steve Ballmer's sales pitch of CS50 itself: https://www.youtube.com/watch?v=El2mr5aS8y0 Fun fact: Brian Kernighan, whom David mentions as the CS50 teacher who preceded him, is also the co-creator of the C programming language. He's even has his own card in freeCodeCamp Programmer Playing Cards: https://www.freecodecamp.org/news/introducing-programmer-playing-cards-d3eeeffe9a11/

In this week's episode of the freeCodeCamp podcast, Abbey chats with Madison Kanna, a full-stack developer who works remotely for Mediavine. Madison describes how homeschooling affected her future learning style, how she tackles imposter syndrome and failure, and how she helps others teach themselves to code.

In this episode of the freeCodeCamp podcast, Abbey chats with developer advocate Alejandra Olvera-Novack about how she broke free from her restrictive cult upbringing, moved to the United States, and taught herself how to code. Alejandra was raised without technology, without formal schooling, and in an extremely conservative environment. When she was in her late teens, she left her village and moved to Florida.  After a couple years of googling everything under the sun to catch up on the world's events, and trying to attend college, she ran out of money. Since she was alone - having cut all ties with her family - she took a leap of faith, moved to Seattle, WA, and started looking for work. She worked odd jobs for a while, but quickly realized she'd need something more to survive and thrive. So she started to learn about HTML and CSS, something she never thought she could do. Fast-forward a couple years later, and she was working her way up to a job at Amazon Web Services. Today, Alejandra works with robots, helps developers be as happy and productive as possible at AWS, and runs the non-profit she founded that teaches women, minorities, and disabled how to code for free. She manages her anxiety and PTSD with the help of a service dog and some really great mentors and friends, and she still can hardly believe she's living her dream. Find Alejandra on Twitter here: https://twitter.com/QuetzalliAle Visit her website here: https://alejandraquetzalli.com/ Check out SheCodesNow, Alejandra's non-profit here: https://twitter.com/shecodesnow Find Abbey on Twitter here: https://twitter.com/abbeyrenn

In this episode of the freeCodeCamp podcast, Abbey chats with freelance Ruby on Rails developer Colleen Shnettler about how she switched from electrical engineering to development, how she founded her business, and how she makes time for kids and family - among many other things.

In this episode, Beau chats with Jesse Weigel, who live streams on the freeCodeCamp.org YouTube channel and is a Senior Software Engineer at DICK'S Sporting Goods. He talks about his career path, live streaming, getting a developer job, speaking at conferences, React Native, dealing with mental health issues, and more.    Jesse's career has benefited a lot by live streaming. He talks about the benefits and offers suggestions for other people who want to get started with it.   Jesse currently builds progressive web apps with React and GraphQL. He talks about why more people should be using React Native for their projects. He also talks about getting the confidence to speak at conferences and offers some tips that helped him deal with mental health issues.   Links to topics Jesse discussed: Direct Neural Interface & DARPA: https://youtu.be/nvUHDK59Igw Brain Scan Clinic: https://www.amenclinics.com/   Find Jesse on Twitter: https://twitter.com/JesseRWeigel   Also consider following Jesse's wife, Bekah, on Twitter: https://twitter.com/BekahHW   Find Beau on Twitter: https://twitter.com/CarnesBeau  

Tim Myers is a developer from Denver. In the 1990s he finished high school and immediately enlisted in the US Army. When he got out, he started coding. He was working as a developer at an accounting firm when he got into a drunken brawl and ended up injuring somebody. Tim was convicted of 2nd degree assault and got a 12 year prison sentence. He earned his college degree entirely while in prison, and was released after 8 years for good behavior. He spent the next 3 years working various jobs like fast food while studying to get back into software development. And for the past 4 years, he's worked as software developer at several Denver companies. In today's episode, Quincy interviews Tim about his journey from convicted felon to developer and family man. Follow Tim on Twitter: https://twitter.com/denvercoder Follow Quincy on Twitter: https://twitter.com/ossia Help our community spread the word the old fashion way - tell a friend about this podcast.

In this episode, Abbey interviews social engineering expert Rachel Tobac and learns how she transitioned from teaching to infosec by way of one exhilarating competition.  Growing up, Rachel’s family didn’t have normal dinner table conversations. Her father was in medicine, so their chats revolved around strange diseases and scary edge cases. So when Rachel went to college, she aimed to follow in her father’s footsteps. However, life had other plans, and she ended up becoming a teacher instead. But she wanted to do more than teach a small number of students – she wanted to help more people at scale. So she tried to figure out a way to do that.  After moving across the country to Silcon Valley and learning more about the world of tech, she stumbled upon her true calling (with a little nudge from her husband and now co-founder): social engineering. She took a trip to Defcon four years ago, won second place in a social engineering capture the flag hacking event, and she was hooked. She dove in head first, learned all she could about infosec, social engineering, and security, and never looked back. Now, she and her husband run Social Proof Security, the boutique educational security firm they founded two years ago, and boast some of the largest tech companies in the Valley as clients. Rachel is also chair of the board of the non-profit WISP (Women in Security and Privacy), helps get scholarships for women to attend Defcon each year, and travels and speaks at all kinds of conferences and events herself.  When she isn’t educating companies about making their processes safer, she’s traveling the world, thinking up new ways to hack, or staring at her rescue dog.  In this episode, you’ll learn all about Rachel’s somewhat meandering path into security, how she discovered her passion for educating teams about social engineering, what it takes to get into the field, and why she loves her job. Find Rachel on Twitter: https://twitter.com/RachelTobac Check out Rachel's company: https://www.socialproofsecurity.com/ Learn more about DefCon: https://www.defcon.org/ Read up on WISP: https://www.wisporg.com/ Find Abbey on Twitter: https://twitter.com/abbeyrenn  

On this week's episode of the freeCodeCamp podcast, Quincy interviews Shawn Wang (@swyx). We talk about "learning in public" and his transition into tech from finance, where he left behind a job that paid him US $350,000 per year. Shawn grew up in Singapore and came to the US as a college student. He worked in finance, but at age 30, he burned out. So he decided to learn to code. He used freeCodeCamp and a ton of other resources, and since then he's worked as a freelance developer, and at several companies including Netlify. Follow Shawn on Twitter: https://twitter.com/swyx Follow Quincy on Twitter: https://twitter.com/ossia Here are some links we discuss in the interview. Shawn's Projects: The official React subreddit that Shawn moderates: https://reddit.com/r/reactjs Shawn's article on No Zero Days: https://www.freecodecamp.org/forum/t/no-zero-days-my-roadmap-from-javascript-noob-to-full-stack-developer-in-12-months/164514 Job Search / Salary Negotation articles: Cracking the Coding Interview: https://fcc.im/2UihbNm Hasseeb Qureshi's story of getting a $250K/y developer job at Airbnb: https://haseebq.com/farewell-app-academy-hello-airbnb-part-i Steve Yegge's "Get that job at Google" essay: http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html Patrick McKenzie on Salary Negotiation https://www.kalzumeus.com/2012/01/23/salary-negotiation/ Quincy's recommended article: I spent 3 months applying to jobs after a coding bootcamp. Here's what I learned: https://medium.freecodecamp.org/9a07468d2331 Algorithm Expert: https://www.algoexpert.io Full Stack Academy https://www.fullstackacademy.com Shawn's Learn In Public movement: Shawn's Learn In Public essay https://gist.github.com/sw-yx/9720bd4a30606ca3ffb8d407113c0fe5‌‌ Kent C Dodds' Zero to 60 in Software Development: How to Jumpstart Your Career https://www.youtube.com/watch?v=-qPh6I2hfjw&app=desktop‌‌ Cory House on Becoming an Outlier: https://vimeo.com/97415346‌‌ Brad Frost on Creative Exhaust: http://bradfrost.com/blog/post/creative-exhaust/‌‌ Patrick McKenzie on the origin of the word "friendcatcher": https://news.ycombinator.com/item?id=511089‌‌ Chris Coyier on "Working In Public": https://chriscoyier.net/2012/09/23/working-in-public/ Links to other things we discuss: Shawn's Software Engineering Daily Interview with Sacha Greif: https://softwareengineeringdaily.com/2017/08/09/state-of-javascript-with-sacha-greif/‌‌ The origin of No Zero Days: https://www.reddit.com/r/getdisciplined/comments/1q96b5/i_just_dont_care_about_myself/cdah4af/‌‌ John Resig, creator of jQuery, telling his team to rip out jQuery: http://bikeshed.fm/180 ‌‌Jeff Bezos' Two Pizza Team rule: https://buffer.com/resources/small-teams-why-startups-often-win-against-google-and-facebook-the-science-behind-why-smaller-teams-get-more-done‌‌ Shawn's "You can learn so much on the internet for the low, low price of your ego" quote draws from Paul Graham's Keep Your Identity Small: http://paulgraham.com/identity.html‌‌ Shawn's Impostor Syndrome Bootcamp Podcast: https://player.fm/series/impostor-syndrome‌‌ TypeScript's growth via npm surveys: https://mobile.twitter.com/seldo/status/1088240877107965953

In this week's episode, Abbey interviews Ariel Leslie, a software developer with an interesting background (she was once a knife salesperson, among other things!) who lives and works in Colorado. While she can't discuss all the details of her super-secret job, she fills us in on how she got to where she is now. You'll hear about the benefits of her university degrees and how supportive communities have helped her along the way, why she loves tough problems and how she battles her insecurities, and why she takes time to learn new things, like how to play the Appalachian Mountain Dulcimer. Ariel offers an interesting perspective on being a woman in tech, how various mentors have helped her become the developer she is today, and how she tackles imposter syndrome. Find Ariel on Twitter: https://twitter.com/ArielLeslie Find Abbey on Twitter: https://twitter.com/abbeyrenn  

Guest: Adam Hollett, developer at Shopify: https://twitter.com/admhlt Host: Quincy Larson, the teacher who founded freeCodeCamp: https://twitter.com/ossia On today's episode of the freeCodeCamp podcast, Quincy interviews Adam Hollett. He's a software developer at Shopify in Ottawa, Canada. Adam started building basic websites and forums when he was in high school, but he never saw coding as something he could do professionally. He got a degree in English Literature, worked in food prep, and taught at a community college. He later worked as a technical writer, and set his eyes on working at Shopify, a major Canadian tech company based in Ottawa. Adam was able to gradually to learn new tools on the job that helped him transition into a role as developer. We talk about Adam's journey - from meandering college student to software developer - and the many lessons he learned along the way.  

On today's episode of the freeCodeCamp.org podcast, Abbey chats with Jennifer Bland, a Google Developer Expert, software engineer, prolific speaker, entrepreneur, and world traveler. You'll learn how Jennifer got into tech (twice!), what she's working on now, and how she helps many different communities of developers learn and grow. Find Jennifer on Twitter: https://twitter.com/ratracegrad Check out Jennifer's podcast: https://www.codeprep.io/podcast/ A bit more about Jennifer: Jennifer Bland is a senior software engineer out of Atlanta, Georgia. Jennifer has a fascinating background - she started in tech at an early age after studying computer science in school, but then left the field, worked elsewhere, and retired at the age of 51. Once she had some time to explore other interests, she rediscovered programming - through a JavaScript book on the clearance table at a local bookstore. A number of years later, she's now working on some very exciting tech at Stanley, Black and Decker, she's an extremely active volunteer in her local tech community, she's on the leadership team for Women who Code Atlanta chapter, she speaks at numerous conferences, and she's recently become a Google Developer expert! So in this episode, you'll hear about how she got to where she is, what she's passionate about, and her advice for getting into tech, conquering those pesky whiteboard interviews, how to network if you're an introvert (like she is) and much more...

On this episode of the freeCodeCamp.org podcast, Abbey chats with Lauren Mayers, a web developer working in Ottowa, Canada. Lauren hasn't always lived in North America, however - she's from Australia - and hasn't always been in tech. We'll hear about how she transitioned from being a registered nurse into the world of coding, how she moved halfway around the world, why she loves the open source community, and what she's learned along the way...among many other things. Connect with Lauren on Twitter: https://twitter.com/laurenalexm Connect with Abbey on Twitter: https://twitter.com/abbeyrenn  

On today's episode of the freeCodeCamp podcast, Abbey chats with  Tracy Lee, a prolific speaker, founder, JavaScript advocate, and open-source enthusiast. Tracy is a Google Developer Expert and the founder of This Dot. She organizes numerous meetups, runs the Modern Web podcast, and is on the RxJS core team. Tracy will share with us how she got into tech, what she's passionate about, and how you can become a badass person in tech, too. Connect with Tracy on Twitter: https://twitter.com/ladyleet Connect with Abbey on Twitter: https://twitter.com/abbeyrenn Find Tracy on the web: https://www.thisdot.co/ Learn to code for free: https://www.freecodecamp.org/  

Zubin Pratap is a corporate lawyer who taught himself to code using freeCodeCamp.org and other learning resources. Zubin develops software in Melbourne, Australia. He's a lover of hackathons and competed in freeCodeCamp's first hackathon at GitHub headquarters last November. Follow Zubin on Twitter: https://twitter.com/ZubinPratap Follow Quincy on Twitter: https://twitter.com/ossia The following is a note from Zubin himself about a course he just launched. Note that freeCodeCamp.org does not receive any benefit from this, and has not reviewed his course - we just want to help him publicize it. --- Zubin was a non-technical person for a long time, and set a goal to become his own tech cofounder. But he quit from discouragement twice.  It was much harder than it should've been, and Zubin put together a course on all the things he wish he'd known and all the techniques that made him not quit the third time. In 3 hours you can learn the roadmap that could save you months, thousands of dollars, and a lot of stress. For podcast listeners, Zubin has a special promotion. The first 20 people to buy the course on Udemy before the end of March can get it for free using the Promo Code: FCC_FREE_PROMO   Course link: https://www.udemy.com/how-not-to-quit-coding/   If you're not among the first 20, the next 50 can get it before April 30 at the discounted rate of US$10, using the Promo Code: FCC_PROMO_50   If you're a later listener, get in touch at the webform on https://matchfitmastery.weebly.com, and mention FCC in the message to get a discount code.

Abbey and Quincy talk about the freeCodeCamp podcast itself, and the new weekly episodes starting on Monday. Abbey on Twitter: https://twitter.com/abbeyrenn Quincy on Twitter: https://twitter.com/ossia Links mentioned: The article Quincy mentioned: "The best podcasts for new coders, and the best tools for listening to them": https://fcc.im/2T2lMHT Tools: Listen Notes: https://listennotes.com Audacity: https://www.audacityteam.org Zencastr: http://zencastr.com Libsyn: https://libsyn.com

Abbey Rennemeyer interviews Erica Peterson, the founder of Moms Can: Code and Science Tots, and Founder Gym alumna.  Erica started her career in biology, but after being told that she should leave her graduate program once she became pregnant with her first child, she started to look for other options. Three years ago, inspired by her desire to understand how her children were learning, she founded Science Tots, a non-profit that helps introduce children to the world of STEM. And just over a year ago, Erica founded Moms Can: Code, an organization that helps mothers learn to code so they can both support their children's learning and open new doors for themselves. In 2018, Erica has been a South By Southwest accelerator pitch finalist, Project Entrepreneur finalist, and Startup of the Year semifinalist - so it's been a busy year for her! Erica is extremely active in her local community, and spends a great deal of her time helping people learn. Today, she'll tell us all about how she got into the tech world, how and why she became a founder, and why being a mom who codes is so awesome. Interview by Abbey Rennemeyer: https://twitter.com/abbeyrenn Erica Peterson on Twitter: https://twitter.com/foundermama Moms Can: Code website: https://www.momscancode.com/ Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02

Quincy Larson interviews Sacha Greif, who's a designer, developer, and prolific open source project creator. Sacha created the Vulcan.js framework, the Sidebar.io daily design newsletter, and so many other important projects in the developer community. Most recently, Sacha started the State of JavaScript survey, where he asks developers a ton of questions about which web development tools they use. He just finished the third annual survey, and soon he'll release the results from the more than 20,000 developers who took the survey. Sacha grew up in Paris. His grandparents were Jewish refugees who fled to France from Poland during World War II. Sacha's father was an author who wrote books about computers, and shared this passion with his son. Sacha has spent much of his adult life living abroad in China, Switzerland, and Japan. He and his wife currently live in Kyoto and they just had their first child. During this interview, Sacha talks about how he got his start as a professional developer in Beijing, then got deeper and deeper into user interface design. He shares how his passion for both of these disciplines resulted in him creating so many important open source projects. Sacha also talks about how he followed in his father's footsteps and wrote the "Discover Meteor" book - the most popular resource for Meteor.js - and how the book's financial success helped bankroll his other projects. Sacha Greif is one of the most prolific developers I know. And it was a blast getting to learn more about his coding journey. So without further ado, here's Sacha. Interview by Quincy Larson: https://twitter.com/ossia Sacha Greif on Twitter: https://twitter.com/SachaGreif   Sacha's personal website with links to many of his projects: http://sachagreif.com/   Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02

Quincy Larson interviews Lyle Troxell, who's a senior software engineer at Netflix. Lyle has hosted his own technology radio show for the past 18 years, and now he hosts the official Netflix podcast, too. Lyle's parents were artists and a part of the 1960s hippy movement. Lyle didn't enjoy school, and in middle school he dropped out so he could focus on learning math and electronics. He eventually went to community college, got a 2-year degree, and did some basic web design work at a few companies during the dot com boom of the late 1990s. Lyle spent the next 11 years as a teacher and administrator at University of California in Santa Cruz. Eventually he decided he wanted get into software development. He was able to dust off his skills and through a remarkable series of events get a software engineer job at Netflix. Lyle and Quincy have known one another for years and had a lot to talk about, including the story behind how he built Apple co-founder Steve Wozniak's personal website. Interview by Quincy Larson: https://twitter.com/ossia Lyle Troxell on Twitter: https://twitter.com/lyle   Lyle's 18-year running tech podcast: https://geekspeak.org   The "Wat?" talk Lyle mentions: https://www.destroyallsoftware.com/talks/wat   Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02

On today's episode, Quincy Larson interviews Ali Spittel. She's a Washington DC-based developer and artist. Ali runs the popular Zen of Programming blog, where she writes about design, data visualization, and other programming topics. She talks about how her interests in political journalism lead to a passion for data and data journalism. Ali also talks about her love of Python. She reads the poem "The Zen of Python" and talks about how it has influenced her programming style and her way of thinking about software development. Interview by Quincy Larson: https://twitter.com/ossia Ali Spittel on Twitter: https://twitter.com/aspittel   Zen of Programming website: https://zen-of-programming.com/ Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02

On today's episode, Quincy Larson interviews Laurence Bradford. She's the creator the LearnToCodeWith.me blog and podcast, and the Newbie Coder Warehouse Facebook group. As a college student, Laurence was so technologically illiterate that her school made her take a remedial computer class. This made her doubt that she had a future in technology. And she ended up studying Economics instead, and moving to Asia to work in economic development. Years later, Laurence decided to learn some basic web development skills. She found a help-wanted ad on Craigslist and landed her first gig as a freelance developer. Since then, Laurence has worked as a developer and a product manager. She's written extensively about technology and programming in Forbes and on her blog. And she's interviewed nearly 100 developers on her LearnToCodeWith.me podcast.   Interview by Quincy Larson: https://twitter.com/ossia Laurence Bradford on Twitter: https://twitter.com/learncodewithme   LearnToCodeWith.me Website: https://learntocodewith.me Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02

On today's episode, Quincy Larson interviews Alexander Kallaway, the creator of the #100DaysOfCode challenge.   In addition to talking about the 100DaysOfCode challenge itself - a challenge which, at this point, thousands of people have taken - Alex and I also talk about how he and his wife moved from Russia to Canada to advance their careers, and how he used freeCodeCamp to gain the skills he needed to get his first developer job.   Alex is an incredibly motivated person, and in this interview we'll delve into how he keeps himself so fired-up day after day. Interview by Quincy Larson: https://twitter.com/ossia Alexander Kallaway on Twitter: https://twitter.com/ka11away   100DaysOfCode Website: https://www.100daysofcode.com/ Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02

Dylan is a software engineer, YouTuber, and creator of several programming courses. Quincy talks to him about how he dropped out of college, drove from California to Florida, and hustled to get his first developer job. On top of that, you'll learn how he was able to leverage a few job offers to get a massive raise at his current company.  Quincy Larson: https://twitter.com/ossia Dylan's YouTube channel: https://fcc.im/2NypFgS Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Description:   On today's episode of the freeCodeCamp podcast, Quincy Larson interviews Dylan Israel.   Dylan is a software engineer, a YouTuber, and the creator of several programming courses. We talk about how he dropped out of college, drove from California to Florida, and hustled to get his first developer job.    We also talk about how important his YouTube channel has been in helping him land job offers. And Dylan shares some details of his latest job search, which resulted in 4 job offers.   Dylan was ultimately able to use those job offers a bargaining chip so he could get a massive raise at his current company without having to change jobs.

Are you trying to get a jump-start on your tech career while you're still in school? Have you found that perfect internship - or job - but you're not sure how to approach it? If so, this is the resource for you. Michael discusses how to craft your résumé, how to prepare for interviews, and much more. Written by Michael Deng: https://twitter.com/themichaeldeng Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2BCESfo Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: Seven semesters ago, I started college with no programming background. The only thing I had was lofty aspirations of working in tech. When recruiting season first rolled around, I applied to a bunch of companies. I got a few callbacks, but that’s it. No follow-ups. No onsite interviews. Nothing. I kept trying. I applied to over 150 companies. I faced dozens of interviews. I failed way more than I succeeded. But that’s all right. Because those failures made my moments of triumph all the more memorable. Along the way, I met helpful mentors and guided ambitious mentees. These people are now working at places like Airbnb, Facebook, Google, SpaceX, and Snap. As for me, I landed an internship at Uber last summer. And I’m on track to accept a full-time job at one of my favorite companies when I graduate. Now that I’m in my final year of school, I want to share everything I’ve learned over the years. This isn’t meant to be the ultimate handbook. It’s only a modest guide born out of my love of helping others reach their goals (and my love of Legos). By the end of this article, you’ll know everything I wish I had known when I first started sending in applications. A few words before we begin… Don’t let your struggle for the perfect job take over your life. School is a time of self-discovery and all-around personal growth. So go out there and meet people who are doing different things. Join diverse student organizations and take part in activities outside your comfort zone. It’s all too easy to associate your self-worth with how prestigious of a job you can get. But remember: there are so many more important things in life than work. My best memories of college aren’t spending weeks on end prepping for interviews or even getting offer phone calls. They’re exploring San Francisco for the first time with my closest friends. They’re playing volleyball with my hilarious teammates. I value these unique experiences I shared with people I love much more than any job. To paraphrase my favorite quote by Twitter and Medium founder Ev Williams: “Failure of your [work] is not failure in life. Failure in your relationships is.” Don’t lose sight of what’s important. It’s also no coincidence that everyone I know with a strong support system eventually found success. When you fall into a slump — and all of us do — you need your friends to be there for you. I would never have made it through my first year without amazing friends who kept me afloat. Now, let’s get started. You pumped? I’m pumped! Building fundamentals Before we get to the good stuff, you need to build solid fundamentals. Seems obvious? Absolutely. But this is the hardest step of this guide, so listen up. Now, this guide is designed for college students, so if you’re in high school, scram! Just kidding. In fact, I admire your initiative. When I was in high school, I didn’t have the faintest idea what I wanted to do. Leading up to college, your top priority should be solidifying your math skills. Computer science relies heavily on mathematic concepts like probability, logic, and number theory. Without math, you’re not going to get far in hard weeder classes and technical interviews. If you’re already proficient in math, keep reading. Most of this guide is just as applicable to you as it is to college students. Skip to the online classes section below and progress through the rest of this guide. Landing an internship as a high schooler is challenging, but certainly not impossible. OK. Back to college students. Building fundamentals starts with your intro programming classes. Pay attention and master the basics. A popular but misguided notion is “GPA doesn’t matter.” Although it’s true that most companies won’t scrutinize your GPA, any gaps in your fundamental knowledge will come back to bite you later. By getting a decent GPA, you’re also most likely getting a grasp of the basics. Your classes will cover a lot of basic knowledge, but they’ll barely scratch the surface of modern technology. Go explore interesting topics around the core concepts taught in class. This is how you gain a breadth of knowledge and come up with future project ideas. If you’re not studying computer science, don’t worry. I have friends who changed their minds and started CS their Junior year. They still graduated on time with great job offers, so you’re not too late at all. This said, you will need to make sacrifices and take extra classes every semester. If you’re not able to take CS classes in college, there are plenty of awesome online resources to help you out. Two of the best online intro courses are Harvard CS50x on edX and CS101 on Udacity. After this intro, you need to master data structures and algorithms. I recommend Princeton Algorithms Part 1 and Part 2 on Coursera, or CS61B by UC Berkeley. To make sure you’re on track, reference Google’s Technical Development Guide. Don’t worry if you struggle at first. A few weeks into my first semester, I was completely overwhelmed. I spent days studying concepts that took other students hours to grasp. I thought about giving up every week. “How am I ever going to catch up to those prodigies?” But if you ask me or any of my friends who made it through, we’ll all tell you the same thing: Learning to program isn’t about how talented you are or how early you started coding. It’s about perseverance. Building up your programming intuition takes a long time — much like learning a human language. You won’t see the light at the end of the tunnel for a long time. But trust me. If you take one step at a time, you will eventually get there. Staying motivated is difficult, but there’s a secret. Focus on mastery instead of results. Make it your goal to get better at a skill rather than achieve a certain result. Dr. Heidi Grant Halvorson did a study where she asked two groups of people to solve various problems. The first group was told to score as high as they could. The second group was told to treat the problems as a learning opportunity. The results were surprising. The first group got frustrated, whereas the second group persisted and solved more problems.​ By focusing on mastery, you view obstacles and time pressure as things that will help you grow. In contrast, a result-oriented mindset frames problems as irritating roadblocks impeding your way. What’s more, you’ll see continual progress if you concentrate on mastery. Every time you read a new paragraph or solve a new question, you’re improving your skills. This kind of continuous gratification is incredibly satisfying. So next time you’re studying for class or practicing for interviews, focus on getting better instead of acing the exam or landing the offer. You can read more about this tactic in Edmond Lau’s Quora post. Beyond basic coding skills, you need to know what’s happening in the tech industry. This goes beyond sounding smart during recruiting. By paying attention to the industry, you’ll be the first to discover new opportunities to propel your career forward.​ For online reading, check out TechCrunch, Techmeme, Product Hunt, and Hacker News. If you’re a frequent Twitter user, follow tech news sources. On Medium and Quora, personalize your feeds to get insightful takes on the industry. If you’re into email newsletters, look into Axios Pro Rata, CB Insights, and Mattermark Daily. To do a deep dive on a particular company, use Crunchbase and the company’s blog. You can also learn about the company’s culture from Glassdoor. Finally, don’t forget to actually talk to people. I learned so much about the tech world from casual conversations with friends and classmates. Over time, you’ll read about a lot of interesting companies. Begin compiling a spreadsheet of companies you’re interested in from day 1. When you apply to these companies in the future, use this spreadsheet to track your progress. Once you have the fundamentals down, it’s time to apply your skills. One of the best ways to do that is by… Building projects If you’re like me, you don’t have much experience to begin with, and that’s OK! The first step is populating that empty resume with projects. When I first decided to work on a project, I had decision paralysis for days. “What should I make? What if it’s not original? What if people don’t like it?” Later, I realized it doesn’t really matter what the project is. Learning something and finishing what you start is much more important. But this doesn’t mean you can make whatever you want. If your project is too trivial, you won’t impress any recruiters. If yourq project is too complex, you’ll lose momentum before completing it. Aim to do a project you think you can complete in one to two months. The project should involve data structures, algorithms, and design decisions. And do something you’re interested in so you’ll actually take it all the way to completion. Here’s a compilation of project ideas on Reddit for inspiration. After coming up with an idea, take some time to plan, but don’t take too long. You want to start as soon as possible. Now, you might be wondering “Isn’t it irresponsible to jump in prematurely?” Generally, yes. But personal projects are different from company projects. Personal projects should teach you something new and strengthen your background during recruiting. Unlike company projects, you don’t need to obsess over design and code quality. If you’re feeling stuck at the beginning, write down some code — any code. Building a personal project is like writing, you just start. Don’t worry if it doesn’t make sense. Seeing code in an editor will get your juices flowing. Track your project with version control. If you don’t know what that is, make a Github account and learn how to use Git. You need Github as it’s the primary way you save and display your projects. If you can, make your project live so recruiters can play with it. Most recruiters won’t inspect your code, so a live demo is the best way to show off your project. Aim to complete three to five projects by the time you start applying. A terrific first project is a personal website. You learn the basics of web development and get your own space on the internet to display your work. Codecademy has two excellent tutorials on building websites: Make a Website teaches you the basics of HTML, CSS, and Bootstrap. Deploy a Website teaches you how to put your website on the internet. Step 3 of this tutorial isn’t necessary, just use the free .github.io domain. Too easy? Convert your personal website into a dynamic blog. To do this, you need to learn a web development framework like Rails or Django. Check out the Ruby on Rails Tutorial or The Django Girls Guide. The Muse and Awwwards have examples of personal websites if you need design inspiration. Also, you have to check out this wicked personal website. Hackathons are great for motivating yourself to do projects. Schools and organizations around the world host hackathons, which are project-building competitions lasting several days. In this short span of time, you’ll learn a lot, come up with unique ideas, and meet interesting people. Many hackathons reimburse travel, so there’s no excuse not to go. Use Hackalist or Hackevents to discover upcoming ones. Some of the top North American hackathons I know of are PennApps, HackMIT, HackNY, MHacks, HackTech, HackIllinois, CalHacks, TreeHacks, Hack the North, YC Hacks, and Greylock Techfair. You can also contribute to open source projects. Working on open source is an awesome way to add value to meaningful projects. Plus, you learn a lot from seeing code written by more experienced engineers. Jumping into open source for the first time can be intimidating. Two good entry points are Google Summer of Code and Sayan Chowdhury’s article on open source for beginners. Github also just released their very own open source guide. Find a cool project and dive in. You’ll get the hang of it soon enough. Research is an alternative to projects. If your school has a student research program, great! Apply asap. If it doesn’t have one, look up what research your professors are doing. If their work seems interesting, email them and ask if you can contribute. You’d be surprised at how receptive they are to eager undergrads. In the future, you can even ask your team to refer you to cutting-edge companies. Keep in mind research belongs under Experience rather than Projects on your resume. It can be tough balancing projects and school. One complaint I hear frequently is “I don’t have time to do side projects while taking classes.” I’m personally guilty of saying that from time to time. It’s tough to set aside time for projects because, unlike school, you’re not held accountable by deadlines and exams. After a day of studying, it’s tempting to choose social media or video games over your project. But if you keep putting it off, the semester will be over before you know it. To combat procrastination, force yourself to work on your project a little bit every day. Even if it’s just 15 minutes, you’ll form a habit of making continual progress. This is also why hackathons and research projects are so great. They impose external deadlines and expectations so you can’t drag your heels. Now that you have some experience, you need to put it somewhere. Creating a resume Writing a resume might seem pretty straightforward, but there are lots of nuances. After all, it’s the first thing recruiters will read about you. It’s crucial to make a good first impression. …And you need to make that impression fast. Recruiters spend an average of six seconds reviewing a resume. You heard that right. Six seconds. Almost all that time is spent on your name, companies, job titles, start/end dates, school, major, and project titles. Everything on your resume should be tailored towards helping recruiters find these key pieces of info as fast as possible. Here are some important guidelines. Easy to scan. Stick to one page. Keep it black and white if you’re not skilled at design. Colors are noisy. Stick to a standard format (chronological, no weird fonts, 10.5 to 12 pt font size, 0.5 to 1 inch margins). Standard formats are more readable by resume-parsing programs and easier to skim by recruiters. Keep it concise. Text walls discourage readers. Highlight the key points Make your name big. Highlight company names, job titles, start/end dates, school name, major, and project titles. Important content should be higher up. For a student, the order of importance is usually Education > Experience > Projects > Skills. Cut the fat. Objective and Summary are unnecessary. Descriptions should say something tangible. “Exceptional team player” doesn’t work. “Increased user conversion rates by 20%” does. People without technical background will be reading your resume, so get rid of convoluted details. Don’t neglect the details: Include the higher of your cumulative GPA and your major GPA. If they’re both less than 3.0, leave it off. Include links to a live demo or Github repo for each project. Don’t include anything you wouldn’t be comfortable answering questions about. Most people make this mistake when listing their skills. After finishing your resume, have your peers review it. Ask them to be honest and harsh. My first draft was awful compared to my tenth draft. Use online resume builders if you’re short on time. Standard Resume and CakeResume are two outstanding tools that make it a breeze to generate a handsome resume. If you don’t have a LinkedIn profile, create one. LinkedIn enables recruiters to find you and helps you maintain your professional network. Plus, you need it for the cold-emailing recruiters later. With a few projects under your belt and resume in hand, you’re ready to begin preparing for interviews. Getting battle-ready for interviews Interview problems can be separated into two buckets, behavioral questions and technical questions. You need to start practicing both at least two months before applying. Since recruiting season kicks off in August/September, summer break is a good time to begin. Behavioral questions The purpose of behavioral questions are to find out more about your background and if you actually did what you said on your resume. Don’t take the behavioral interview lightly. A poor performance can sink your chances of getting the offer. To ace behavioral questions, you need a strong answer to “Tell me about yourself” and three stories to handle all other questions. “Tell me about yourself” is the most common behavioral question you’ll get and you need to crush it. Don’t make the cardinal mistake of regurgitating your resume. Instead, tell a story. Capture the attention of the interviewer with a strong introduction. Then, transition into a commentary about your key projects and experiences. Don’t prattle on about the details — keep it simple and emphasize the outcomes. Finally, explain why you’re interested in the position. It’s tempting to talk about every single thing you did, but you’ll lose your interviewer. Keep it concise. Your answer should be one to two minutes long. Prepare three stories you can tell in response to all other behavioral questions. Typically, you’ll be asked to give examples of leadership, overcoming a challenge, or failure. Each of your three stories should show at least one of these themes. A story needs an initial summary, a problem, three to five action steps, and a final outcome. Here’s an example. Summary: Lead an unmotivated team to complete CS project Problem: Two team members didn’t do their work and wanted to drop CS Action 1: Talked to them one-on-one to understand why they’re studying CS Action 2: Told them although it’s tough now, they can succeed if they work hard Action 3: Emphasized that they’re invaluable to the rest of the team Action 4: Used google calendar to plan meetings and Trello to track progress Action 5: Held social events to bring the team closer Outcome: Finished the project and all got at least A- This story can be used to answer any question about leadership or overcoming a challenge. Now go think of your own! Not all your stories have to be about tech. For example, I always talk about how I helped my volleyball team overcome defeat. With this, you should be able to pass any behavioral interview. To learn more, read the Behavioral Questions section in Cracking the Coding Interview. Technical questions Technical questions are the essence of the tech interviewing process. Here’s a list of topics you need to know to pass technical interviews. To master these topics, use the following four resources: Cracking the Coding Interview (~2 months before applying) LeetCode (~1 month before applying) Mock interviews (~2 weeks before applying) Glassdoor (~2 days before interviewing) Cracking the Coding Interview is one of the best resources out there. Gayle Laakmann McDowell’s Cracking the Coding Interview is the quintessential tech recruiting manual. First, read the Technical Questions section. Take notes to help you remember the main ideas. As for practice questions, concentrate on the Arrays and Strings, Linked Lists, Stacks and Queues, Trees and Graphs, Objected-Oriented Design, Recursion, and Sorting sections. Also, familiarize yourself with the Bit Manipulation, Scalability, Databases, and Threads and Locks sections. If you’re having trouble with any of the topics, study the first couple pages of that section. They contain a short and sweet explanation of the topic. Attempt each question for at least 30 minutes before looking at the solution. After reading the solution, you should still implement it and test it on your own. Otherwise, you won’t fully understand the logic. Finishing CtCI should take three to four weeks of dedicated effort. LeetCode is the second resource you should tackle. It has a huge list of problems ranked by difficulty. Each problem has its own tests, time complexity requirements, and solutions. Aim to complete 30 to 50 questions and be comfortable with medium level questions before you start applying. If you do just three a day, you can finish 42 in two weeks. It’s easy to get frustrated by Leetcode at first. In the beginning, I couldn’t solve a single easy problem. I improved over time, but I still get stuck frequently on medium and hard level problems. The good thing is interviews are different from Leetcode. In an interview, you get hints if you’re stuck. Plus, deducing the correct logic is more important than writing runnable code. Although Leetcode isn’t the best simulation of real interviews, it’s phenomenal for building problem solving intuition. Mock interviews are highly effective if you do them right. The trick is emulating a real interview as closely as possible. If you’re the interviewee, be professional, ask questions, and talk out loud. If you’re the interviewer, time the interview, engage in the conversation, and write down feedback. I suggest booking a private room on campus and grinding through back-to-back interviews. Make sure the room has a big whiteboard to draw on. Take turns interviewing and being interviewed by a friend who’s also recruiting. Being able to understand the interviewer’s perspective will improve your own interviewing skills. Glassdoor is an invaluable resource for company-specific info. In most cases, you don’t need Glassdoor until a few days before your interview. Unless the company is very large, Glassdoor won’t have many specific interview questions. Glassdoor is better for learning about the company’s general interview process. Navigate to the Interviews section and filter by the position you’re applying for. Sometimes there are different labels for the same job, so look through all of them. Read candidates’ experiences and think through the interview questions they posted. You likely won’t get the same questions, but working through them will give you an idea of what to expect. Making your application stand out It’s finally time to send out applications and start seeing your hard work pay off! Recruiting season begins in August/September, but you can reach out a month or two earlier. For off-season jobs, apply at least 6 months before. First, you need a list of companies to apply to. If you’ve been following the tech industry, you should already have some companies in mind. To add to your list, check out The Breakout List, Wealthfront’s Career-Launching Companies List, and the CrunchBase Unicorn Leaderboard. For more ideas, here’s a list of 163 companies I looked at when I was recruiting. Don’t be picky about which companies to apply to. If you think the product is interesting or you’ve heard good things about the company, then apply. Worry about choosing after you get a few offers. The application process I recommend first applying and interviewing for companies you’re less interested in. This is a good way to train for future interviews of companies you want more. But don’t do too many — you don’t want to burn out. When I recruit, I try to keep the process under 3 months and not do more than 10 onsite interviews. Anything more than that, I run out of steam and my performance suffers. When you’re scheduling your interviews, spread them out. Interviews are mentally draining, so you need time to rest in between. Companies won’t mind if you ask for a week or two before starting their process. Once you’re ready to apply, use a 5-pronged approach: Referrals Emailing recruiters Career fairs Online applications This list is ordered by success rate and time commitment. For example, referrals have the highest success rate but require the most time. Referrals are the single best way to land interviews. When an employee refers someone, that’s the golden endorsement. Referrals make up for less than 10% of applications, but 20-50% of eventual hires. Ask your friends or older students to refer you. You can also ask employees for a phone chat or coffee to learn more about the company and request a referral at the end. Don’t be shy about this. If you get hired, the employee who referred you gets a bonus — it’s win-win for both of you. Cold-emailing recruiters is the next best thing to referrals. For smaller companies without a formal recruiting pipeline, reach out to an Engineering Manager instead. For even smaller companies, just email the CEO or CTO. The easiest way to get email addresses is asking your network for recruiter contacts. You need a LinkedIn account to find email addresses. Look up the companies you want to apply to on LinkedIn and filter their employees by recruiters. Next, install Hunter or Slik, which lets you get the email address from a LinkedIn profile. Hunter doesn’t like it if you try to sign up using a personal email, so use your school email. Your emails should be concise. State your interest in a position and include a summary of your background. Remember to attach your resume. To save time, make a template. You just have to change the name of the recruiter, the name of the company, and your statement of interest. If you don’t get a reply in a week, follow up. If you don’t get a reply in another week, follow up again. Career fairs get you face time with recruiters and engineers. For career fairs, check which companies are attending beforehand. Jot down the ones you’re most interested in because you might not have time to talk to all of them. Print out 10 to 20 copies of your resume to pass to recruiters. Be ready to answer questions about your experiences and projects. I recommend going early — miss class if you have to. You’ll avoid the lines and catch recruiters before they’re exhausted from chatting nonstop. Don’t feel pressured to ask recruiters questions if you don’t have any. You won’t offend anyone if you get straight to the point and ask if they have openings. After your conversation, make sure to get their emails so you can follow up later. Oh yeah, and actually follow up! Don’t let those business cards gather dust with the free t-shirts and drawstring bags. For hackathons, you’ll be targeting one company you really like instead of 10 to 20. Company sponsors will set up shop at the venue. This is your in. Before the hackathon, find the sponsoring company you want to target. When you arrive, introduce yourself to its engineers and recruiters. Use their API in your project and interact with them throughout the hackathon. On the last day, go show them your project. Then, ask about job/internship opportunities. At this point, they’ve already seen your work ethic, creativity, and interest in their company. You’re pretty much guaranteed an interview. Hackathons can function as indirect career fairs also. I know people who’ve landed interviews through talking to engineers and recruiters from sponsoring companies at hackathons. For more advice on this strategy, read Ryan Norton’s article. Online applications are the easiest way to apply. Use a shotgun approach. Most applications only ask for your resume, so it’s easy to apply to a lot of companies in one go. Intern Supply, the Easy Application List, and your school’s career website are essential for finding open positions. Most of the time, you don’t need a cover letter. But if the company makes the cover letter mandatory or asks for a short answer response, be careful. In this case, the company really cares about fit, so craft a meticulous response. I’ve been burned many times by disregarding mandatory cover letters and short answers. Take your time when writing — a hurried response will show. For applying online, I also recommend TripleByte. You first complete a coding quiz. Then, TripleByte matches you with top companies and fast-tracks you through their hiring processes. Bear in mind this resource only works for finding full-time jobs. Conquering the interview For many people, this is the most nerve-wracking part of the process, but there’s no need to be anxious. The interviewer is on your side (even if it doesn’t seem like it). Before we go any further, there’s one thing you have to keep in mind. Show enthusiasm! Enthusiasm plays a huge role in whether you get an offer. Companies these days love to talk about how much they value culture fit. What they basically mean is they want someone who’s enthusiastic about their mission and product. The truth is most candidates aren’t good at being enthusiastic. The best way to ensure you do it is preparing a list of things you like about the company in advance. When answering behavioral questions or asking questions, bring up the items on your list. Use the company’s blog and its Crunchbase profile to find things you can talk about. Now, let’s go over some best practices for technical interviews. When you first hear the problem, write it down. Then, clarify with your interviewer what you think the question is asking. Don’t assume you understood the question the first time you heard it. Next, write down a few example inputs and outputs and verify they’re correct. This gives you time to think of a solution and provides tests you can run later. If you need more time to think, don’t be afraid ask for a minute to brainstorm. It shouldn’t be too hard to devise a brute-force solution. Talk through it with your interviewer while thinking of ways you can improve it. Continue bouncing ideas off your interviewer until you come up with a better solution. Explain it to your interviewer and only start coding after they’re satisfied. While you’re working through the problem, continuously communicate your thought process. How you think is more important than the actual answer. Be outspoken, but don’t blab on endlessly. Take pauses to think and let the interviewer make suggestions. Don’t space out or look distant. You should direct your full attention towards the interviewer to engage them. If they’re engaged, they’ll give you positive signals if you’re on track and hints if you’re not. What’s more, they’ll be emotionally invested in you and want you to succeed. At the end of the interview, you’ll get time to ask questions. Remember an interview is two-way. Don’t just ask questions you think the interviewer will like to hear. Ask questions you actually want to know the answers to. I suggest asking about personal experiences to get more authentic answers. Remember these tips and you’ll be ready to ace technical interviews. The average interview process looks like this: Coding challenge > Recruiter chat > Phone interview > Onsite interview The process varies by company. Sometimes the recruiter chat will be first. Sometimes you won’t have a coding challenge. But the general structure is similar. The coding challenge is a straightforward test. It’s usually hosted on Hackerrank. I suggest doing a couple of questions on it ahead of time to get familiar with the format. There’s no trick to the coding challenge. Pass as many tests as you can. With enough practice on Leetcode, this should be a walk in the park. The recruiter chat is an informal conversation. It’s usually for setting up the phone interview and answering any questions you have. You might get one or two behavioral questions. Once in a while, you might get trivia-esque technical questions like “Explain how a hashmap works.” Candidates rarely get rejected at this stage (although I’ve managed to do just that a few times). Treat this as a chance to learn more about the company. Ask high-level questions — recruiters generally don’t know technical details. Make sure to ask about the format of the rest of the interview process so you aren’t caught off guard by anything. The phone interview stage is one to two rounds of technical interviews. Sometimes you’ll do a video chat instead of a phone call. You’ll typically code out the answer in a shared editor like Collabedit. If the connection is bad or you’re having trouble understanding the interviewer, speak up. You’re not going to get docked points, so don’t try to tough it through. The onsite interview is three to six rounds of interviews with a lunch in between. A day of back-to-back interviews is exhausting — get enough sleep beforehand! Onsite interviews are mostly technical, but some companies mix in behavioral and design rounds. The lunch is for you to learn more about the company, so relax a little. During the interview, use the whiteboard to your advantage. Leave plenty of space on the right side and between the lines so you have room to make edits. After the interview, don’t dwell on it. Thinking about it isn’t going to change the final result. Treat it as if you were rejected and continue applying and practicing. Evaluating the offer Congratulations! You got an offer! Give yourself a big pat on the back — you earned it. But your work isn’t done yet. First, thank your recruiter and re-express your enthusiasm for the company. Then, ask for your offer in writing. It’s time to negotiate. A job offer isn’t an act of generosity — it’s a proposal to strike a deal. Naturally, a deal involves negotiation. I’m not going to elaborate too much on negotiation tactics. Just read Haseeb Qureshi’s killer guide on negotiation. Bear in mind some offers are non-negotiable, but it never hurts to try. Avoid unpaid jobs. In 90% of cases, it’s not worth it. I’m all for prioritizing learning over pay, but at least work for a company that values you enough to pay you. If you have more than one offer, congrats! You’re awesome. But now you have to make a decision. Choosing which offer to accept is a nice problem to have. The best offer depends on the specific candidate, but here’s one universal suggestion I hope serves you well. Make a list of 10 professional and personal goals you want to achieve in the next 10 years. It could be anything, like paying off student loans, founding a startup, or mastering a new hobby. Choose the job that brings you closest to these goals. Here are a couple more tips to remember: Your future manager is vital to your career growth. Find a great mentor who will double as your champion. Do internships at different companies to gain broader experiences. You’ll learn more and expand professional network. Optimize for learning and growth over pay, unless the pay is really bad. Work at one brand name company. It’ll make recruiting in the future easier, but know that it’s not the end of the world if you don’t have one. Choice of programming language doesn’t matter. What matters is learning good engineering practices and how to work in a team. Choose an engineering-first company with a software/hardware product. Don’t forget about passion. It’s an amazing feeling building a product you believe in. Conclusion This brings us to the end of this guide. I hope that with this, you’ll be much better prepared than I was when starting a career in tech. In the beginning, getting an offer might seem impossible, but the key is treating it as a series of milestones rather than one enormous task. If you make a little bit of progress every day, you’ll be there before you know it! When you do get that dream job, don’t forget to give back. Share your experiences and extend referrals. Pass on the love, and we’ll all fly higher.

As a software engineer, it's your responsibility to write a good design doc so that your team knows how to solve the problem you're addressing. But what makes a design doc good, what should you include, and how should you write it? Angela shares all her tips so you can make your design docs as effective and helpful as possible. Written by Angela Zhang: https://twitter.com/zhangelaz Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2vAL4io Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: As a software engineer, I spend a lot of time reading and writing design documents. After having gone through hundreds of these docs, I’ve seen first hand a strong correlation between good design docs and the ultimate success of the project. This article is my attempt at describing what makes a design document great. The article is split into 4 sections: Why write a design document What to include in a design document How to write it The process around it Why write a design document? A design doc — also known as a technical spec — is a description of how you plan to solve a problem. There are lots of writings already on why it’s important to write a design doc before diving into coding. So all I’ll say here is: A design doc is the most useful tool for making sure the right work gets done. The main goal of a design doc is to make you more effective by forcing you to think through the design and gather feedback from others. People often think the point of a design doc is to to teach others about some system or serve as documentation later on. While those can be beneficial side effects, they are not the goal in and of themselves. As a general rule of thumb, if you are working on a project that might take 1 engineer-month or more, you should write a design doc. But don’t stop there — a lot of smaller projects could benefit from a mini design doc too. Great! If you are still reading, you believe in the importance of design docs. However, different engineering teams, and even engineers within the same team, often write design docs very differently. So let’s talk about the content, style, and process of a good design doc. What to include in a design doc? A design doc describes the solution to a problem. Since the nature of each problem is different, naturally you’d want to structure your design doc differently. To start, the following is a list of sections that you should at least consider including in your next design doc: Title and People The title of your design doc, the author(s) (should be the same as the list of people planning to work on this project), the reviewer(s) of the doc (we’ll talk more about that in the Process section below), and the date this document was last updated. Overview A high level summary that every engineer at the company should understand and use to decide if it’s useful for them to read the rest of the doc. It should be 3 paragraphs max. Context A description of the problem at hand, why this project is necessary, what people need to know to assess this project, and how it fits into the technical strategy, product strategy, or the team’s quarterly goals. Goals and Non-Goals The Goals section should: describe the user-driven impact of your project — where your user might be another engineering team or even another technical system specify how to measure success using metrics — bonus points if you can link to a dashboard that tracks those metrics Non-Goals are equally important to describe which problems you won’t be fixing so everyone is on the same page. Milestones A list of measurable checkpoints, so your PM and your manager’s manager can skim it and know roughly when different parts of the project will be done. I encourage you to break the project down into major user-facing milestones if the project is more than 1 month long. Use calendar dates so you take into account unrelated delays, vacations, meetings, and so on. It should look something like this: Start Date: June 7, 2018 Milestone 1 — New system MVP running in dark-mode: June 28, 2018 Milestone 2 - Retire old system: July 4th, 2018 End Date: Add feature X, Y, Z to new system: July 14th, 2018 Add an [Update] subsection here if the ETA of some of these milestone changes, so the stakeholders can easily see the most up-to-date estimates. Current Solution In addition to describing the current implementation, you should also walk through a high level example flow to illustrate how users interact with this system and/or how data flow through it. A user story is a great way to frame this. Keep in mind that your system might have different types of users with different use cases. Proposed Solution Some people call this the Technical Architecture section. Again, try to walk through a user story to concretize this. Feel free to include many sub-sections and diagrams. Provide a big picture first, then fill in lots of details. Aim for a world where you can write this, then take a vacation on some deserted island, and another engineer on the team can just read it and implement the solution as you described. Alternative Solutions What else did you consider when coming up with the solution above? What are the pros and cons of the alternatives? Have you considered buying a 3rd-party solution — or using an open source one — that solves this problem as opposed to building your own? Monitoring and Alerting I like including this section, because people often treat this as an afterthought or skip it all together, and it almost always comes back to bite them later when things break and they have no idea how or why. Cross-Team Impact How will this increase on call and dev-ops burden? How much money will it cost? Does it cause any latency regression to the system? Does it expose any security vulnerabilities? What are some negative consequences and side effects? How might the support team communicate this to the customers? Discussion Any open issues that you aren’t sure about, contentious decisions that you’d like readers to weigh in on, suggested future work, and so on. Detailed Scoping and Timeline This section is mostly going to be read only by the engineers working on this project, their tech leads, and their managers. Hence this section is at the end of the doc. Essentially, this is the breakdown of how and when you plan on executing each part of the project. There’s a lot that goes into scoping accurately, so you can read this post to learn more about scoping. I tend to also treat this section of the design doc as an ongoing project task tracker, so I update this whenever my scoping estimate changes. But that’s more of a personal preference. How to write it Now that we’ve talked about what goes into a good design doc, let’s talk about the style of writing. I promise this is different than your high school English class. Write as simply as possible Don’t try to write like the academic papers you’ve read. They are written to impress journal reviewers. Your doc is written to describe your solution and get feedback from your teammates. You can achieve clarity by using: Simple words Short sentences Bulleted lists and/or numbered lists Concrete examples, like “User Alice connects her bank account, then …” Add lots of charts and diagrams Charts can often be useful to compare several potential options, and diagrams are generally easier to parse than text. I’ve had good luck with Google Drawing for creating diagrams. Pro Tip: remember to add a link to the editable version of the diagram under the screenshot, so you can easily update it later when things inevitably change. Include numbers The scale of the problem often determines the solution. To help reviewers get a sense of the state of the world, include real numbers like # of DB rows, # of user errors, latency — and how these scale with usage (remember your Big-O notations?). Try to be funny A spec is not an academic paper. Also, people like reading funny things, so this is a good way to keep the reader engaged. Don’t overdo this to the point of taking away from the core idea though. If you, like me, have trouble being funny, Joel Spolsky (obviously known for his comedic talents…) has this tip: One of the easiest ways to be funny is to be specific when it’s not called for [… Example:] Instead of saying “special interests,” say “left-handed avacado farmers.” Do the Skeptic Test Before sending your design doc to others to review, take a pass at it pretending to be the reviewer. What questions and doubts might you have about this design? Then address them preemptively. Do the Vacation Test If you go on a long vacation now with no internet access, can someone on your team read the doc and implement it as you intended? The main goal of a design doc is not knowledge sharing, but this is a good way to evaluate for clarity so that others can actually give you useful feedback. Process Ah yes, the dreaded P-word. Design docs help you get feedback before you waste a bunch of time implementing the wrong solution or the solution to the wrong problem. There’s a lot of art to getting good feedback, but that’s for a later article. For now, let’s just talk specifically about how to write the design doc and get feedback for it. First of all, everyone working on the project should be a part of the design process. It’s okay if the tech lead ends up driving a lot of the decisions, but everyone should be involved in the discussion and buy into the design. So the “you” throughout this article is a really plural “you” that includes all the people on the project. Secondly, the design process doesn’t mean you staring at the whiteboard theorizing ideas. Feel free to get your hands dirty and prototype potential solutions. This is not the same as starting to write production code for the project before writing a design doc. Don’t do that. But you absolutely should feel free to write some hacky throwaway code to validate an idea. To ensure that you only write exploratory code, make it a rule that none of this prototype code gets merged to master. After that, as you start to have some idea of how to go about your project, do the following: Ask an experienced engineer or tech lead on your team to be your reviewer. Ideally this would be someone who’s well respected and/or familiar with the edge cases of the problem. Bribe them with boba if necessary. Go into a conference room with a whiteboard. Describe the problem that you are tackling to this engineer (this is a very important step, don’t skip it!). Then explain the implementation you have in mind, and convince them this is the right thing to build. Doing all of this before you even start writing your design doc lets you get feedback as soon as possible, before you invest more time and get attached to any specific solution. Often, even if the implementation stays the same, your reviewer is able to point out corner cases you need to cover, indicate any potential areas of confusion, and anticipate difficulties you might encounter later on. Then, after you’ve written a rough draft of your design doc, get the same reviewer to read through it again, and rubber stamp it by adding their name as the reviewer in the Title and People section of the design doc. This creates additional incentive and accountability for the reviewer. On that note, consider adding specialized reviewers (such as SREs and security engineers) for specific aspects of the design. Once you and the reviewer(s) sign off, feel free to send the design doc to your team for additional feedback and knowledge sharing. I suggest time-bounding this feedback gathering process to about 1 week to avoid extended delays. Commit to addressing all questions and comments people leave within that week. Leaving comments hanging = bad karma. Lastly, if there’s a lot of contention between you, your reviewer, and other engineers reading the doc, I strongly recommend consolidating all the points of contention in the Discussion section of your doc. Then, set up a meeting with the different parties to talk about these disagreements in person. Whenever a discussion thread is more than 5 comments long, moving to an in-person discussion tends to be far more efficient. Keep in mind that you are still responsible for making the final call, even if everyone can’t come to a consensus. In talking to Shrey Banga recently about this, I learned that Quip has a similar process, except in addition to having an experienced engineer or tech lead on your team as a reviewer, they also suggest having an engineer on a different team review the doc. I haven’t tried this, but I can certainly see this helping get feedback from people with different perspectives and improve the general readability of the doc. Once you’ve done all the above, time to get going on the implementation! For extra brownie points, treat this design doc as a living document as you implement the design. Update the doc every time you learn something that leads to you making changes to the original solution or update your scoping. You’ll thank me later when you don’t have to explain things over and over again to all your stakeholders. Finally, let’s get really meta for a second: How do we evaluate the success of a design doc? My coworker Kent Rakip has a good answer to this: A design doc is successful if the right ROI of work is done. That means a successful design doc might actually lead to an outcome like this: You spend 5 days writing the design doc, this forces you to think through different parts of the technical architecture You get feedback from reviewers that X is the riskiest part of the proposed architecture You decide to implement X first to de-risk the project 3 days later, you figure out that X is either not possible, or far more difficult than you originally intended You decide to stop working on this project and prioritize other work instead At the beginning of this article, we said the goal of a design doc is to make sure the right work gets done. In the example above, thanks to this design doc, instead of wasting potentially months only to abort this project later, you’ve only spent 8 days. Seems like a pretty successful outcome to me.

Everyone makes mistakes, especially when they're first learning a new skill or tool. If you've just entered the world of programming, chances are you'll make your fair share of mistakes, too. In this episode, Jack discusses some of the missteps he's taken early on in his career, and how you can learn from them and avoid them. Written by Jack Finlay Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2mOhFfY Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: When you first start out in the world of software development, things may seem daunting and unknown. Leaving university and venturing into the real world is a big step, and you will stumble many times on the path before finding your feet and confidence. You may have confidence in your abilities already. But I ask you, “How many mistakes have you made?” The start of a career in software development is the start of a journey in mastering your craft. As with any field, there will be challenges and chances to be correct, and chances where you can be completely wrong. This piece acts as a reflection on the mistakes I have made early in my career — and a guide to avoiding them. Getting the job Landing your first job out of university isn’t always easy. Make sure it’s the right one for you. A company has to be a good fit for you, and where you want your career to go. Find out what you are worth I made this mistake twice. When I got my first software development job during university, in my second year, I was struggling financially. This led me to accept the first salary offer I was given. I felt I needed to just take the offer, as it was great compared to the abysmal pittance I was receiving from student benefits. Little did I know that it was well under the market rate for the location, position, and time. As I said earlier, I made this mistake twice. Upon graduating, I managed to land a job elsewhere. They were going to pay me 25% more than I was earning at the time! It was still at the low end of the market rate. I was low-balled, and I was happy to take it. I hadn’t learned yet that not all the power is in the employer’s hands. You too can make an offer. If I had taken the time to do some proper research, I would have seen what I was really worth. I recommend sites like PayScale to give you an indication. You can even use sites like this as a source when negotiating. Read the reviews Glassdoor is a great resource. Real employees of the companies listed have taken the effort to rate the companies they work for. Generally the reviews can be quite polarized as to whether employees have had good or bad experiences. Search out some of each and you’ll find the middle-ground for yourself. Had I read some of these reviews earlier, I would have avoided some terrible experiences when interviewing and beyond. Know what you’ll really be working with Earlier in my career, I was so keen to work for a particular company (a friend was working there and was enjoying it) that I forgot to stop and ask what I would actually be working on. It turned out that I would not be in the same department as my friend, and that I would be on the other side of the building, and later even on different floors. And I didn’t take the time to make sure the job would really fit me. Another side of this mistake was not asking enough about the environments, tools, and languages I would be using. When going for the next step in my career, I made sure to ask about the following: Version control strategy and tooling Is it industry standard? Git, TFS, SVN or Mercurial? If you’ve heard of it, it should be okay. Is there CI/CD tooling and environments in place? Deployments should be as automated as possible. It’ll make your life so much easier. How often are deployments? What frameworks/languages will I be working in? What tooling do you use? Which IDE? Visual Studio, Rider or IntelliJ are some good options. What kind of projects will I be working on? What kinds of technologies will the company be looking to use next? Also, what kind of horizon are these changes at? How far off are they from becoming day-to-day in use at the company? In the job The challenges don’t stop once you are in the job. Every day will present some new way to challenge you. Code is never self documenting “My code is self-documenting, I don’t need comments”.

Learning how to code can be overwhelming - especially if your intro course asks you to build a Facebook clone. But if you focus on the fundamentals, have the right guidance, and develop a strong inner motivation to succeed, you'll master the basics and be ready to move on. In this episode, you'll learn how to do just that. Written by Rainer Hahnekamp: https://twitter.com/rainerhahnekamp Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2LOmUao Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02  Transcript I have been programming for more than 20 years. During that time, I’ve had the pleasure to work with many people, from whom I learned a lot. I’ve also worked with many students, coming fresh from university, with whom I had to take on the role of a teacher or mentor. Lately, I have been involved as a trainer in a program that teaches coding to absolute beginners. Learning how to program is hard. I often find that university courses and bootcamps miss important aspects of programming and take poor approaches to teaching rookies. I want to share the five basic pillars I believe a successful programming course should build upon. As always, I am addressing the context of mainstream web applications. A rookie’s goal is to master the fundamentals of programming and to understand the importance of libraries and frameworks. Advanced topics such as the cloud, operations in general, or build tools should not be part of the curriculum. I am also skeptical when it comes to Design Patterns. They presume experience that beginners never have. So let’s look at where new programmers should start. Test-Driven Development (TDD) TDD brings a lot of benefits. Unfortunately, it is an advanced topic that beginners are not entirely ready for. Beginners shouldn’t write tests. This would be too much for their basic skill levels. Instead, they should learn how to use and work with tests. Each programming course should center around exercises. I extend my exercises with unit tests and provide the students an environment which is already setup for running those tests. All the students have to do is write their code and then watch the lights of the testrunner turning from red to green. The resulting gamification is a nice side effect. For example: If the selected technology is Spring, I provide the exercises and tests within a Spring project. The students don’t need to know anything about Spring. All they need to know is the location of the exercises and the button to trigger the tests. Additionally, students must know how to use a debugger and have a Read-Eval-Print Loop (REPL) handy. The ability to analyse code during runtime and to have a playground for small experiments is essential in TDD. The main point is to ensure students don’t have to learn basic TDD behaviours after they’ve acquired core programming skills. Changing habits later in the students’ career will be much harder than learning those habits now. That’s why they should live and breath unit tests from the beginning. Later in their professional life, they should have an antipathy for projects without unit tests. They should intuitively see the absence of unit tests as anti-pattern. Fundamentals First I hear very often that rookies should immediately start with a framework. This is like teaching people how to drive by placing them in a rally car and asking them to avoid oversteering. This simply ignores the fact that they still mistake the brake for the throttle. The same applies when we start students with a framework like Angular. Beginners need to understand the fundamentals of programming first. They need to be familiar with the basic elements and what it means to write code before they can use somebody else’s. The concept of a function, a variable, a condition, and a loop are completely alien to novices. These four elements build the foundations of programming. Everything a program is made of relies on them. Students are hearing these concepts for the very first time, but it is of the utmost importance that the students become proficient with them. If students do not master the fundamentals, everything that follows looks like magic and leads to confusion and frustration. Teachers should spend more time on these fundamentals. But, sadly, many move on far too quickly. The problem is that some teachers struggle to put themselves into the role of a student. They have been programming for ages and have forgotten what types of problems a beginner has to deal with. It is quite similar to a professional rally driver. He can’t imagine that somebody needs to think before braking. He just does it automatically. I design my exercises so that they are challenging but solvable in a reasonable amount of time by using a combination of the four main elements. A good example is a converter for Roman and Arabic numbers. This challenge requires patience from the students. Once they successfully apply the four elements to solve the challenge, they also get a big boost in motivation. Fundamentals are important. Don’t move on until they are settled. Libraries and Frameworks After students spend a lot of time coding, they must learn that most code already exists in the form of a library or a framework. This is more a mindset than a pattern. As I have written before: Modern developers know and pick the right library. They don’t spend hours writing a buggy version on their own. To make that mindset transition a success, the examples from the “fundamentals phase” should be solvable by using well-known libraries like Moment.js, Jackson, Lodash, or Apache Commons. This way, students will immediately understand the value of libraries. They crunched their heads around those complicated problems. Now they discover that a library solves the exercise in no time. Similar to TDD, students should become suspicious when colleagues brag about their self-made state management library that makes Redux unnecessary. When it comes to frameworks, students will have no problem understanding the importance once they understand the usefulness of libraries. Depending on the course’s timeframe, it may be hard to devote time to frameworks. But as I already pointed out, the most important aspect is shifting the mindset of the student away from programming everything from scratch to exploring and using libraries. I did not add tools to this pillar, since they are only of use to experienced developers. At this early stage, students do not need to learn how to integrate and configure tools. Master & Apprentice In my early 20s I wanted to learn to play the piano. I did not want a teacher, and thought I could learn it by myself. Five years later, I consulted a professional tutor. Well, what can I say? I’ve learned more in 1 month than during the five years before. My piano teacher pointed out errors in my playing I couldn’t hear and made me aware of interpretational things I never would have imagined. After all, she instilled in me the mindset for music and art, both of which were out of reach for me as a technical person. It is the same in programming. If somebody has no experience in programming, then self-study can be a bad idea. Although there are many success stories, I question the efficiency of doing it alone. Instead, there should be a “master & apprentice” relationship. In the beginning, the master gives rules the apprentice must follow — blindly! The master may explain the rules, but usually the reasoning is beyond the apprentice’s understanding. These internalised rules form a kind of safety net. If one gets lost, one always has some safe ground to return to. Teaching should not be a monologue. The master has to deal with each student individually. He should check how the students work, give advice, and adapt the speed of the course to their progress. Once the apprentices reach a certain level of mastery, they should be encouraged to explore new territory. The master evolves into a mentor who shares “wisdom” and is open for discussions. Challenge and Motivation “Let’s create a Facebook clone!” This doesn’t come from a CEO backed by a horde of senior software developers and a multi-million euro budget. It is an exercise from an introductory course for programmers. Such an undertaking is virtually impossible. Even worse, students are put into wonderland and deluded into believing they have skills that are truly beyond their reach. No doubt the teacher is aware of that, but creates such exercises for motivational reasons. The main goal of an exercise is not to entertain. It should be created around a particular technique and should help the students understand that technique. Motivation is good, but not at the sacrifice of content. Programming is not easy. If the students don’t have an intrinsic motivation, coding might not be the way to go. Newbies should experience what it means to be a professional developer. They should know what awaits them before they invest lots of hours. For example, many business applications center around complex forms and grids. Creating these is an important skill that exercises can impart. Building an application similar to Facebook might not be the best lesson for students to learn right away. Similarly, a non-programmer might be surprised at how few code lines a developer writes per day. There are even times where we remove code or achieve nothing. Why? Because things go wrong all the time. We spend endless hours fixing some extremely strange bugs that turn out to be a simple typo. Some tool might not be working just because a library got a minor version upgrade. Or the system crashes because somebody forgot to add a file to git. The list can go on and on. Students should enjoy these experiences. An exercise targeting an unknown library under time pressure might be exactly the right thing. ;) The sun isn’t always shining in real life. Beginners should be well-prepared for the reality of programming. Final Advice Last but not least: One cannot become a professional programmer in two weeks, two months or even a year. It takes time and patience. Trainers should not rush or make false promises. They should focus on whether students understand the concepts and not move on too fast.

Learning to code - or learning any new skill - is hard, but it doesn't have to be overwhelming. In this episode, Preethi discusses her tried and true strategies for learning, how to tackle challenging problems, and the methods that help her add new tools to her kit.  Written by Preethi Kasireddy: https://twitter.com/iam_preethi Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2uG4B0F Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript Being an efficient learner is at least as important as being an efficient coder. When you’re a developer, your job requires you to learn every single day — in spite of the constant lure of distractions like Hacker News, Twitter, Reddit, and Facebook. You constantly encounter new code bases and new technical challenges at work. Home is no better, as you tackle open source repos and personal projects, each with their own processes and challenges to tackle. The tech world changes fast, and it can feel like a full-time job just keeping up with the latest tools, languages and frameworks. Long story short: learning is hard. Yet, we need to be able to learn quickly and effectively to thrive. In the past year, I went from not knowing how to use the Chrome debugger to working as a software engineer for a leading cryptocurrency company. In the process, I rapidly learned a new skill (coding). That said, learning didn’t come easy for me. Honestly, every new concept was a struggle. There were too many unknowns, and too much uncertainty. “How in the world is this sustainable?” I thought to myself. “If this is what learning to code is supposed to feel like every day, I’ll be miserable. Is this really my passion?” “Wouldn’t this be easy for me if this was my passion? Do artists struggle to produce art? Do writers struggle to write a great book? Do athletes struggle to do well in a race? Are we supposed to struggle when we’re pursuing our passions?” “Shouldn’t I be finding pleasure in this?” Does it ever get easier? Yes, it does. A year later, tackling new programming concepts is still “difficult” in the sense that it requires discipline and hard work. But it’s also become an enjoyable process, rather than an overwhelming one. What happened in the last year to make that shift possible? Simple: I changed my perspective on learning. What once struck me as “difficult” became “engaging.” In the rest of the post, I’ll explain how this transformation happened. Just getting started Learning to code is hardest at the beginning. For example, think about the first programming language you have to learn. You want to tackle the small things like syntax and style. But first, you have to comprehend difficult core concepts like values, types, operators, control flow, functions, higher order functions, scopes, closures, recursion, and so much more. It feels like learning to juggle — but starting with eighteen pins instead of two. When I first learned about closures, it took me many weeks to truly understand the concept. I thought I understood it when I read about it. But when I tried to identify and use closures in practice, I’d find myself stumped. That wasn’t unusual. I’ve observed this process as a teacher as well: new concepts don’t usually click the first time around. Or the second. Or even the tenth. But for those who stick it out long enough, there will be a “breaking point” where things suddenly begin to make sense. In my example, I read literally every blog post, Stack Overflow post, and spec on the internet about closures. Everything I read and experimented with gave me a new perspective, until eventually, I had a 360-degree mental picture of how closures worked. Closures “clicked.” Getting to a point where I felt this sense of understanding of closures was super important, because it was rewarding and encouraged me to go for more — including writing my own blog post that explained the concept. Learning is a process, not a goal If we see learning as something we “have” to do, then we rush to get it done so that we can spend the rest of our time doing something more “fun” — something we “want” to do. The problem is that it’s impossible to know everything about anything, so viewing learning as a race leads to burnout and disappointment. Instead, if you see learning as a process, you’ll appreciate the small victories and insights along the way. This will drive you to constantly move forward. You can compare it to exercise. Workouts hurt, and then the pain ends as soon as your workout ends. But it’s never gone. It’s waiting for you the next time you workout. Except each time, the pain becomes less piercing. You learn to cope with it. You become familiar with the pain, and it just becomes part of the routine. You are rewarded by better health and a better physique and are incentivized to keep going. Exercise creates a positive feedback loop. The same is true for learning. Turning learning into an engaging process Imagine building your very first web application. At first, all you’ve got is a daunting, blank text editor. The task of building the app seems almost insurmountable. You know nothing, and have so much to learn before you can make this happen. Thankfully, you decide to go for it anyway. From then on, your main focus becomes to do one small step at a time. First, you create an idea. What will you build? Who’s the end user? What are the constraints? Second, you prototype or sketch out some rough designs for what you think it might look like. You ask your friends or the internet for feedback, and iterate to make it better. Third, you research languages, tools, and frameworks that will work best with your requirements. Step by step you discipline your mind to channel all its energy towards this one goal. Sometimes you’re writing code. More often than not you’re stalled at some bug or error. Sometimes you’re too tired to do any work, so you take a break. Other times, you don’t feel like writing code. That’s okay. You spend your time researching or reading up on topics related to your project. Eventually, after a few weeks of hard work, you’ve built a foundation that can handle your big ideas. Suddenly, working on your app doesn’t feel as painful. You see the reward of the initial set of hard work, and now it’s just another piece of code you need to write or another bit of refactoring you need to do — which you’ve done 100s of times already, no problem. You turned what was once a daunting or dreadful activity into one that is complex and engaging. This is how we grow. This is how we get better. Whether it’s programming, dancing, running, or reading: it’s not easy, and there won’t ever be a time or place when you’re “done” learning. Instead, enjoy the process of investing your energy into something, and enjoy the pain that comes along with it. You’ll start to notice that you no longer describe it as “pain” — because what was once painful becomes a symbol for what’s next: a sense of personal accomplishment and self-satisfaction. In other words, struggle and enjoyment will start to mean one and the same thing. Remember the cycle: One approach to learning technical topics Let me tell you a little about the learning process I follow. This isn’t the be-all-end-all of learning styles, so if something different works for you, please share it in the comments! In case you can’t tell, I’m a nerd about this stuff :) Let’s use the process of learning the React.js library as an example. What is the motivation for learning this? First step: I’d start with a Google search for the React.js documentation and read a bit about the background and motivation for the library. Knowing the “why” behind any topic is incredibly helpful for framing the learning process. It answers questions like: How is this different from other solutions? How useful is this to me? What problems does this solution aim to solve? Is this just a new shiny tool that’ll only be useful for a few months or will it fundamentally change the way I think and code? Reading and understanding core concepts Second, I’d read through any intro articles or examples provided in the docs. Notice I’m not touching any code yet. Reading and sinking in the core concepts comes before hands-on experimentation. It’s incredibly important to do this because it lays the foundation for the rest of my learning. Even though I might be able to get away with blindly using React.js without learning the core concepts, eventually it’ll catch up to me when I run into a bug. First time coding After spending some time on the above steps, I start to get the gist of what’s going on, or maybe even feel like I totally get it. Then it’s time to jump into some code. I typically try to build something really small with any new tool by following a video tutorial (e.g. on egghead.io) or a written tutorial before jumping into custom projects. When you get stuck …And then, inevitably, I get stuck. Reading the docs seemed like a piece of cake, but actually using it in practice makes me realize I have no idea what’s going on. This is when I start to feel that dreaded “just give up” feeling. But instead of giving in when the going gets tough, I remind myself that pain == gain. Turning back would be cowardly. Here’s what I do instead: I first narrow down and figure out what I’m actually stuck on — i.e. define the problem. Then I come up with a hypothesis for what I think could be the root cause or causes of the problem. Even if I have no idea, I just make a guess. Then I step away from the problem and my computer and do something that relaxes me. This is incredibly hard to do when I’m so upset about the problem I’m stuck on, but letting go of the problem works wonders. (Ever notice how great ideas always strike in the shower?) Now I try to debug with my hypothesis in mind. I get as far as I can on my hypothesis without looking for answers online — there’s something beautiful that happens when you try to solve problems by truly thinking deeply about them on your own first. Even if you’re going down the wrong path, the fact that you made the effort teaches you a lot and you remember the problem space much better next time you run into it. If my hypothesis leads to an answer, hooray! I’m done. If not, I Google search for documentation, blog posts, or Stack Overflow posts that could help me get closer to the answer. While reading, I take notes on any and all pieces of information that could potentially be helpful. Still no solution? That’s fine. I’m sure I learned something valuable by reading through all that, even if it didn’t directly help me solve the problem at hand. Who knows when this knowledge might come in handy next time? At this point, if I’m truly stuck, I will either post a question on Stack Overflow or ask a co-worker or developer I know. Otherwise, I rinse and repeat until I get closer to the final solution. At some point, the answer always comes. At times this process takes a few seconds, and other times it takes hours (or days). Either way, the process itself is incredibly beneficial to your skill set as a developer. Getting stuck on a bug feels like stumbling in a dark tunnel looking for a ray of light. You eventually find it, but along the way you discover so much about the tunnel — and it’s knowledge about the “tunnel” that makes you strong as a coder. Think of debugging as a chance to explore rather than a detour from your goal, and it becomes much more fun. Rinse and repeat By this point in the learning process, I’ve built something small and tackled some small hurdles along the way. As you can see, it was a struggle — clearly, I need some more practice with the new tool. So, once again I try to build something on my own. Rather than jumping straight to a big custom project, I’ll look for a repo to base my application on. For example, if there’s an online CRUD todos example (of course) using React.js, maybe I’ll build a different type of CRUD application. Just different enough to keep me engaged, but not so different as to make me discouraged if something goes wrong. Mastery Mastery requires repetition, so I keep building more small projects until I feel like I’ve got the core concepts down. Eventually, I begin to be able to piece things together on my own without constantly referencing documentation or examples. Only then do I finally adventure out and build something from scratch on my own. Throughout this process, I aim to make the process fun and engaging. I’m constantly pushing myself to work on things that are harder than what I am capable of in the moment, but not throwing myself into the deep end so that I get discouraged and never finish. Finally, I make sure to step away as soon as I find myself getting too frustrated to enjoy the project. Learning is fun With some effort and structure, learning programming turns out to be incredibly fun. At first it’s incredibly complicated, and in my opinion that’s why so many people get scared away — not because it’s “boring,” but because it’s “hard.” After you go through this learning process a few times, processing new information becomes a muscle memory. You don’t really think about it. You just learn to ride the pain wave and find joy in the reward. Like magic, it becomes “easier” to learn.

Have you ever had to deal with legacy code - code that someone else wrote a long time ago? Are you temped to just rip everything apart and rewrite it? Bill explains why this is a bad idea and how to approach - and respect - legacy code instead. Written by Bill Sourour: https://twitter.com/billsourour Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2KJahRe Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: At some point in your developer career, your boss will hand you a piece of legacy code — code that someone else wrote a long time ago. Your boss will tell you to learn this legacy code, fix it, and add new features to it. I’ve been in this situation many times over the last two decades. I can help. How to understand legacy code If you’re lucky, you’ll have documentation, or at least in-line comments. Maybe one or two of the original authors will still even be around to help. But most of the time, you will not be so lucky. Let’s talk about what you’re going to do in those unlucky cases. First, you need to be humble. Respect the code, and the developers who wrote it. It’s easy to look at work that came before you and decide it’s no good and that you can do better. This is the wrong attitude. It will lead you down a very dangerous path. If you go down this dangerous path, you’ll start making changes before properly understanding the impact of those changes. You’ll “fix” things that aren’t broken, because they are written in a style that you don’t like, or are based on an older way of doing things. Ultimately, you’ll waste an incredible amount of time with this attitude. So stop. Take a step back and realize that everything in that codebase was done a certain way for a reason. Until you know the code forward and backward, you have to assume that there were good reasons for it to be written the way it is, and that you just haven’t figured them out yet. This is a much more productive attitude, and it will save you from breaking everything, then just wanting to jump out of a window when you can’t put it back together quickly enough. Don’t Humpty Dumpty your codebase. The best way that I’ve found to learn a codebase is to start at the user interface level, then work my way back into the code. Pick a single user flow, like logging in, placing an order, writing a review, or whatever is relevant to your particular application. Go through the flow as an end user. Then look at the code, starting with the user interface code — it should be the easiest to recognize — and follow each step on back, all the way to the database. As you go along, draw a sequence diagram to help illustrate what is happening. If you’re not sure what a sequence diagram is, or how to draw one, check out this free tutorial. If you don’t have a good tool for drawing UML, here’s a free one. Once you’ve completed your first sequence diagram, using a local copy of the codebase that you can easily restore, start to make subtle changes to some of the components you’ve encountered. See if you can predict the effects of your changes on the application. This is a good way to test your understanding. Keep repeating this process, adding to your diagrams until you have a complete picture of the entire application (or at least all the parts you are responsible for). For bonus points, make sure you share your notes and diagrams. Put them in a highly visible place where the next developer who comes along can easily discover them. Don’t worry about making them perfect, or even pretty. Just do what you can. Every little bit helps. Overall, the most important thing is to be patient, and avoid beating yourself up. Code is a complex thing. Understanding legacy code takes time. Stay calm. How to fix legacy code The biggest challenge you’ll face when fixing legacy code is deciding how far to go with your fix. I strongly advise you to make the minimum viable change first. This means you should make the least disruptive change that completely fixes the problem before attempting to clean and refactor any code. This gives you an escape hatch. Worse case scenario, if you get pulled away to address some other priority — or if you’re on a tight deadline — at least you’ll have pulled together some working code that you can fall back on. Once you’ve gotten your code working, if you still have time left, you can start making small, incremental improvements. Martin Fowler has put together a catalog of refactorings which will give you a good idea of the types of changes you can make to incrementally improve a codebase. Check it out here. The idea is to always leave the code in better shape than it was when you found it. Sometimes, you’ll encounter a bug that is actually the result of a structural defect. These bugs can’t be fixed by a simple change to some conditional logic. They require more invasive changes. This is where things get hairy. You have to be brutally honest with yourself about what the minimum viable change is. Every fiber of your being will want to pull the code apart and re-write the whole thing. Don’t do it! Stick to a quick fix, followed by an incremental improvement that refactors it and cleans it up as much as time permits. Your goal is just to make the code a little better every time. The longer you maintain the codebase, the better it will get. To truly make this approach work, make sure you’re always padding your estimates to allow time for a bit of refactoring. Sometimes, the structural defects are so bad that a strategy of forever patching just won’t work. This situation is actually much more rare than you might think. Again, you have to be brutally honest with yourself about the cost/benefit of a rewrite or redesign. You need to accept that, ultimately, this will be a business decision and not a technical one. Prepare to state your case in business terms. What will it cost to do a major restructuring of the code? What are the real business risks of not doing it? If you have a solid case, you will eventually be heard. Don’t be surprised if it takes a few more cycles of patching first, though. Remember: if you are doing a major overhaul, first make sure there’s support for the change and a reasonable budget to go along with it. Don’t try to fly under the radar with this. Unless, of course, you relish awkward conversations with management when you start breaking things and missing deadlines. How to add new features to legacy code Finally, you will eventually be called upon to add features to legacy code. At this point, you have an important decision to make. Do you “go with the flow” of the current codebase, or take things in a new direction? Again, I advise you to be brutally honest in your evaluation. Would continuing to follow the patterns and practices evident in the existing codebase make it worse, or pile onto an existing problem? Most of the time, you’ll want to keep things stable. Just make incremental additions using the existing patterns and practices of the code. Re-use existing elements. Make the least disruptive changes possible, while making small, incremental improvements by cleaning and refactoring. If you believe that a new direction is absolutely necessary, then you’ll need to find a way to isolate your changes and couple them as loosely as possible to the existing codebase. Try carving out the new feature as a separate project. You can then expose an API that lets the legacy code plug into your new code. This makes it so that your new code and the old legacy code don’t need to know much about each other. This starts to get a bit tricky when you need to use functionality from the legacy code in order to implement the new feature. The best way to isolate the old code from the new code is to use the Adapter Pattern. DO Factory has a good explanation of the Adapter Pattern: “The Adapter pattern translates one interface (an object’s properties and methods) to another. Adapters allow programming components to work together that otherwise wouldn’t because of mismatched interfaces. The Adapter pattern is also referred to as the Wrapper Pattern. One scenario where Adapters are commonly used is when new components need to be integrated and work together with existing components in the application. Another scenario is refactoring in which parts of the program are rewritten with an improved interface, but the old code still expects the original interface.” Here are some links to explanations and examples in various languages. JavaScript example of the Adapter Pattern C# example of the Adapter Pattern Java example of the Adapter Pattern Key takeaways In summary, here are the key points that will help you tackle and ultimately conquer any codebase: Never judge legacy code or change it until you’ve taken the time to fully understand it. Sequence diagrams are your friend. Prefer small, incremental improvements over wholesale re-writes or changes. Each change should attempt to leave the code a little better off than it was when you found it. If you need to make big changes, make a business case and get approval first. When adding new features, try to “go with the flow.” If you need to take the code in a new direction, isolate your changes and use the Adapter Pattern to integrate. Hopefully you found this article useful. My mission is to help as many developers as I can.

When Maxime worked at Facebook, his role started evolving. He was developing new skills, new ways of doing things, and new tools. And — more often than not — he was turning his back on traditional methods. He was a pioneer. He was a data engineer! In this podcast, you'll learn about the rise of the data engineer and what it takes to be one. Written by Maxime Beauchemin: https://twitter.com/mistercrunch Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2tHLCST Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: I joined Facebook in 2011 as a business intelligence engineer. By the time I left in 2013, I was a data engineer. I wasn’t promoted or assigned to this new role. Instead, Facebook came to realize that the work we were doing transcended classic business intelligence. The role we’d created for ourselves was a new discipline entirely. My team was at forefront of this transformation. We were developing new skills, new ways of doing things, new tools, and — more often than not — turning our backs to traditional methods. We were pioneers. We were data engineers! Data Engineering? Data science as a discipline was going through its adolescence of self-affirming and defining itself. At the same time, data engineering was the slightly younger sibling, but it was going through something similar. The data engineering discipline took cues from its sibling, while also defining itself in opposition, and finding its own identity. Like data scientists, data engineers write code. They’re highly analytical, and are interested in data visualization. Unlike data scientists — and inspired by our more mature parent, software engineering — data engineers build tools, infrastructure, frameworks, and services. In fact, it’s arguable that data engineering is much closer to software engineering than it is to a data science. In relation to previously existing roles, the data engineering field could be thought of as a superset of business intelligence and data warehousing that brings more elements from software engineering. This discipline also integrates specialization around the operation of so called “big data” distributed systems, along with concepts around the extended Hadoop ecosystem, stream processing, and in computation at scale. In smaller companies — where no data infrastructure team has yet been formalized — the data engineering role may also cover the workload around setting up and operating the organization’s data infrastructure. This includes tasks like setting up and operating platforms like Hadoop/Hive/HBase, Spark, and the like. In smaller environments people tend to use hosted services offered by Amazon or Databricks, or get support from companies like Cloudera or Hortonworks — which essentially subcontracts the data engineering role to other companies. In larger environments, there tends to be specialization and the creation of a formal role to manage this workload, as the need for a data infrastructure team grows. In those organizations, the role of automating some of the data engineering processes falls under the hand of both the data engineering and data infrastructure teams, and it’s common for these teams to collaborate to solve higher level problems. While the engineering aspect of the role is growing in scope, other aspects of the original business engineering role are becoming secondary. Areas like crafting and maintaining portfolios of reports and dashboards are not a data engineer’s primary focus. We now have better self-service tooling where analysts, data scientist and the general “information worker” is becoming more data-savvy and can take care of data consumption autonomously. ETL is changing We’ve also observed a general shift away from drag-and-drop ETL (Extract Transform and Load) tools towards a more programmatic approach. Product know-how on platforms like Informatica, IBM Datastage, Cognos, AbInitio or Microsoft SSIS isn’t common amongst modern data engineers, and being replaced by more generic software engineering skills along with understanding of programmatic or configuration driven platforms like Airflow, Oozie, Azkabhan or Luigi. It’s also fairly common for engineers to develop and manage their own job orchestrator/scheduler. There’s a multitude of reasons why complex pieces of software are not developed using drag and drop tools: it’s that ultimately code is the best abstraction there is for software. While it’s beyond the scope of this article to argue on this topic, it’s easy to infer that these same reasons apply to writing ETL as it applies to any other software. Code allows for arbitrary levels of abstractions, allows for all logical operation in a familiar way, integrates well with source control, is easy to version and to collaborate on. The fact that ETL tools evolved to expose graphical interfaces seems like a detour in the history of data processing, and would certainly make for an interesting blog post of its own. Let’s highlight the fact that the abstractions exposed by traditional ETL tools are off-target. Sure, there’s a need to abstract the complexity of data processing, computation and storage. But I would argue that the solution is not to expose ETL primitives (like source/target, aggregations, filtering) into a drag-and-drop fashion. The abstractions needed are of a higher level. For example, an example of a needed abstraction in a modern data environment is the configuration for the experiments in an A/B testing framework: what are all the experiment? what are the related treatments? what percentage of users should be exposed? what are the metrics that each experiment expects to affect? when is the experiment taking effect? In this example, we have a framework that receives precise, high level input, performs complex statistical computation and delivers computed results. We expect that adding an entry for a new experiment will result in extra computation and results being delivered. What is important to note in this example is that the input parameters of this abstraction are not the one offered by a traditional ETL tool, and that a building such an abstraction in a drag and drop interface would not be manageable. To a modern data engineer, traditional ETL tools are largely obsolete because logic cannot be expressed using code. As a result, the abstractions needed cannot be expressed intuitively in those tools. Now knowing that the data engineer’s role consist largely of defining ETL, and knowing that a completely new set of tools and methodology is needed, one can argue that this forces the discipline to rebuild itself from the ground up. New stack, new tools, a new set of constraints, and in many cases, a new generation of individuals. Data modeling is changing Typical data modeling techniques — like the star schema — which defined our approach to data modeling for the analytics workloads typically associated with data warehouses, are less relevant than they once were. The traditional best practices of data warehousing are loosing ground on a shifting stack. Storage and compute is cheaper than ever, and with the advent of distributed databases that scale out linearly, the scarcer resource is engineering time. Here are some changes observed in data modeling techniques: further denormalization: maintaining surrogate keys in dimensions can be tricky, and it makes fact tables less readable. The use of natural, human readable keys and dimension attributes in fact tables is becoming more common, reducing the need for costly joins that can be heavy on distributed databases. Also note that support for encoding and compression in serialization formats like Parquet or ORC, or in database engines like Vertica, address most of the performance loss that would normally be associated with denormalization. Those systems have been taught to normalize the data for storage on their own. blobs: modern databases have a growing support for blobs through native types and functions. This opens new moves in the data modeler’s playbook, and can allow for fact tables to store multiple grains at once when needed dynamic schemas: since the advent of map reduce, with the growing popularity of document stores and with support for blobs in databases, it’s becoming easier to evolve database schemas without executing DML. This makes it easier to have an iterative approach to warehousing, and removes the need to get full consensus and buy-in prior to development. systematically snapshoting dimensions (storing a full copy of the dimension for each ETL schedule cycle, usually in distinct table partitions) as a generic way to handle slowly changing dimension (SCD) is a simple generic approach that requires little engineering effort, and that unlike the classical approach, is easy to grasp when writing ETL and queries alike. It’s also easy and relatively cheap to denormalize the dimension’s attribute into the fact table to keep track of its value at the moment of the transaction. In retrospect, complex SCD modeling techniques are not intuitive and reduce accessibility. conformance, as in conformed dimensions and metrics is still extremely important in modern data environment, but with the need for data warehouses to move fast, and with more team and roles invited to contribute to this effort, it’s less imperative and more of a tradeoff. Consensus and convergence can happen as a background process in the areas where the pain point of divergence become out-of-hand. Also, more generally, it’s arguable to say that with the commoditization of compute cycles and with more people being data-savvy then before, there’s less need to precompute and store results in the warehouse. For instance you can have complex Spark job that can compute complex analysis on-demand only, and not be scheduled to be part of the warehouse. Roles & responsibilities The data warehouse A data warehouse is a copy of transaction data specifically structured for query and analysis. — Ralph Kimball A data warehouse is a subject-oriented, integrated, time-variant and non-volatile collection of data in support of management’s decision making process. — Bill Inmon The data warehouse is just as relevant as it ever was, and data engineers are in charge of many aspects of its construction and operation. The data engineer’s focal point is the data warehouse and gravitates around it. The modern data warehouse is a more public institution than it was historically, welcoming data scientists, analysts, and software engineers to partake in its construction and operation. Data is simply too centric to the company’s activity to have limitation around what roles can manage its flow. While this allows scaling to match the organization’s data needs, it often results in a much more chaotic, shape-shifting, imperfect piece of infrastructure. The data engineering team will often own pockets of certified, high quality areas in the data warehouse. At Airbnb for instance, there’s a set of “core” schemas that are managed by the data engineering team, where service level agreement (SLAs) are clearly defined and measured, naming conventions are strictly followed, business metadata and documentation is of the highest quality, and the related pipeline code follows a set of well defined best practices. It also becomes the role of the data engineering team to be a “center of excellence” through the definitions of standards, best practices and certification processes for data objects. The team can evolve to partake or lead an education program sharing its core competencies to help other teams become better citizens of the data warehouse. For instance, Facebook has a “data camp” education program and Airbnb is developing a similar “Data University” program where data engineers lead session that teach people how to be proficient with data. Data engineers are also the “librarians” of the data warehouse, cataloging and organizing metadata, defining the processes by which one files or extract data from the warehouse. In a fast growing, rapidly evolving, slightly chaotic data ecosystem, metadata management and tooling become a vital component of a modern data platform. Performance tuning and optimization With data becoming more strategic than ever, companies are growing impressive budgets for their data infrastructure. This makes it increasingly rational for data engineers to spend cycles on performance tuning and optimization of data processing and storage. Since the budgets are rarely shrinking in this area, optimization is often coming from the perspective of achieving more with the same amount of resources or trying to linearize exponential growth in resource utilization and costs. Knowing that the complexity of the data engineering stack is exploding we can assume that the complexity of optimizing such stack and processes can be just as challenging. Where it can be easy to get huge wins with little effort, diminishing returns laws typically apply. It’s definitely in the interest of the data engineer to build [on] infrastructure that scales with the company, and to be resource conscious at all times. Data Integration Data integration, the practice behind integrating businesses and systems through the exchange of data, is as important and as challenging as its ever been. As Software as a Service (SaaS) becomes the new standard way for companies to operate, the need to synchronize referential data across these systems becomes increasingly critical. Not only SaaS needs up-to-date data to function, we often want to bring the data generated on their side into our data warehouse so that it can be analyzed along the rest of our data. Sure SaaS often have their own analytics offering, but are systematically lacking the perspective that the rest of you company’s data offer, so more often than not it’s necessary to pull some of this data back. Letting these SaaS offering redefine referential data without integrating and sharing a common primary key is a disaster that should be avoided at all costs. No one wants to manually maintain two employee or customer lists in 2 different systems, and even worse: having to do fuzzy matching when bringing their HR data back into their warehouse. Worse, company executive often sign deal with SaaS providers without really considering the data integration challenges. The integration workload is systematically downplayed by vendors to facilitate their sales, and leaves data engineers stuck doing unaccounted, under appreciated work to do. Let alone the fact that typical SaaS APIs are often poorly designed, unclearly documented and “agile”: meaning that you can expect them to change without notice. Services Data engineers are operating at a higher level of abstraction and in some cases that means providing services and tooling to automate the type of work that data engineers, data scientists or analysts may do manually. Here are a few examples of services that data engineers and data infrastructure engineer may build and operate. data ingestion: services and tooling around “scraping” databases, loading logs, fetching data from external stores or APIs, … metric computation: frameworks to compute and summarize engagement, growth or segmentation related metrics anomaly detection: automating data consumption to alert people anomalous events occur or when trends are changing significantly metadata management: tooling around allowing generation and consumption of metadata, making it easy to find information in and around the data warehouse experimentation: A/B testing and experimentation frameworks is often a critical piece of company’s analytics with a significant data engineering component to it instrumentation: analytics starts with logging events and attributes related to those events, data engineers have vested interests in making sure that high quality data is captured upstream sessionization: pipelines that are specialized in understand series of actions in time, allowing analysts to understand user behaviors Just like software engineers, data engineers should be constantly looking to automate their workloads and building abstraction that allow them to climb the complexity ladder. While the nature of the workflows that can be automated differs depending on the environment, the need to automate them is common across the board. Required Skills SQL mastery: if english is the language of business, SQL is the language of data. How successful of a business man can you be if you don’t speak good english? While generations of technologies age and fade, SQL is still standing strong as the lingua franca of data. A data engineer should be able to express any degree of complexity in SQL using techniques like “correlated subqueries” and window functions. SQL/DML/DDL primitives are simple enough that it should hold no secrets to a data engineer. Beyond the declarative nature of SQL, she/he should be able to read and understand database execution plans, and have an understanding of what all the steps are, how indices work, the different join algorithm and the distributed dimension within the plan. Data modeling techniques: for a data engineer, entity-relationship modeling should be a cognitive reflex, along with a clear understanding of normalization, and have a sharp intuition around denormalization tradeoffs. The data engineer should be familiar with dimensional modeling and the related concepts and lexical field. ETL design: writing efficient, resilient and “evolvable” ETL is key. I’m planning on expanding on this topic on an upcoming blog post. Architectural projections: like any professional in any given field of expertise, the data engineer needs to have a high level understanding of most of the tools, platforms, libraries and other resources at its disposal. The properties, use-cases and subtleties behind the different flavors of databases, computation engines, stream processors, message queues, workflow orchestrators, serialization formats and other related technologies. When designing solutions, she/he should be able to make good choices as to which technologies to use and have a vision as to how to make them work together. All in all Over the past 5 years working in Silicon Valley at Airbnb, Facebook and Yahoo!, and having interacted profusely with data teams of all kinds working for companies like Google, Netflix, Amazon, Uber, Lyft and dozens of companies of all sizes, I’m observing a growing consensus on what “data engineering” is evolving into, and felt a need to share some of my findings. I’m hoping that this article can serve as some sort of manifesto for data engineering, and I’m hoping to spark reactions from the community operating in the related fields!

You've probably heard a lot about bitcoin over the last few years. But do you truly understand how it works? This article explains the concepts in straightforward language (like you were 5) so you'll never be out of the loop again. Written by Nik Custodio: https://twitter.com/nik5ter Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2tzvh1E Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: We’re sitting on a park bench. It’s a great day. I have one apple with me. I give it to you. You now have one apple and I have zero. That was simple, right? Let’s look closely at what happened: My apple was physically put into your hand. You know it happened. I was there. You were there. You touched it. We didn’t need a third person there to help us make the transfer. We didn’t need to pull in Uncle Tommy (who’s a famous judge) to sit with us on the bench and confirm that the apple went from me to you. The apple’s yours! I can’t give you another apple because I don’t have any left. I can’t control it anymore. The apple left my possession completely. You have full control over that apple now. You can give it to your friend if you want, and then that friend can give it to his friend. And so on. So that’s what an in-person exchange looks like. I guess it’s really the same, whether I’m giving you a banana, a book, or say a quarter, or a dollar bill…. But I’m getting ahead of myself. Back to apples! Now say, I have one digital apple. Here, I’ll give you my digital apple. Ah! Now it gets interesting. How do you know that that digital apple that used to be mine, is now yours, and only yours? Think about it for a second. It’s more complicated, right? How do you know that I didn’t send that apple to Uncle Tommy as an email attachment first? Or your friend Joe? Or my friend Lisa too? Maybe I made a couple of copies of that digital apple on my computer. Maybe I put it up on the internet and one million people downloaded it. As you see, this digital exchange is a bit of a problem. Sending digital apples doesn’t look like sending physical apples. Some brainy computer scientists actually have a name for this problem: it’s called the double-spending problem. But don’t worry about it. All you need to know is that, it’s confused them for quite some time and they’ve never solved it. Until now. But let’s try to think of a solution on our own. Ledgers Maybe these digital apples need to be tracked in a ledger. It’s basically a book where you track all transactions — an accounting book. This ledger, since it’s digital, needs to live in its own world and have someone in charge of it. Say, just like World of Warcraft. Blizzard, the guys who created the online game, have a “digital ledger” of all the rare flaming fire swords that exist in their system. So, cool, someone like them could keep track of our digital apples. Awesome — we solved it! Problems There’s a bit of a problem though: 1) What if some guy over at Blizzard created more? He could just add a couple of digital apples to his balance whenever he wants! 2) It’s not exactly like when we were on the bench that one day. It was just you and me then. Going through Blizzard is like pulling in Uncle Tommy(a third-party) out of court(did I mention he’s a famous judge?) for all our park bench transactions. How can I just hand over my digital apple to you, like, you know— the usual way? Is there any way to closely replicate our park bench, just you-and-me, transaction digitally? Seems kinda tough… The Solution What if we gave this ledger — to everybody? Instead of the ledger living on a Blizzard computer, it’ll live in everybody’s computers. All the transactions that have ever happened, from all time, in digital apples will be recorded in it. You can’t cheat it. I can’t send you digital apples I don’t have, because then it wouldn’t sync up with everybody in the system. It’d be a tough system to beat. Especially if it got really big. Plus it’s not controlled by one person, so I know there’s no one that can just decide to give himself more digital apples. The rules of the system were already defined at the beginning. And the code and rules are open-source. It’s there for the smart people to contribute to, maintain, secure, improve on, and check on. You could participate in this network too and update the ledger and make sure it all checks out. For the trouble, you could get like 25 digital apples as a reward. In fact, that’s the only way to create more digital apples in the system. I simplified quite a bit …but that system I explained exists. It’s called the Bitcoin protocol. And those digital apples are the “bitcoins” within the system. Fancy! So, did you see what happened? What does the public ledger enable? 1) It’s open source remember? The total number of apples was defined in the public ledger at the beginning. I know the exact amount that exists. Within the system, I know they are limited(scarce). 2) When I make an exchange I now know that digital apple certifiably left my possession and is now completely yours. I used to not be able to say that about digital things. It will be updated and verified by the public ledger. 3) Because it’s a public ledger, I didn’t need Uncle Tommy(third-party) to make sure I didn’t cheat, or make extra copies for myself, or send apples twice, or thrice… Within the system, the exchange of a digital apple is now just like the exchange of a physical one. It’s now as good as seeing a physical apple leave my hand and drop into your pocket. And just like on the park bench, the exchange involved two people only. You and me — we didn’t need Uncle Tommy there to make it valid. In other words, it behaves like a physical object. But you know what’s cool? It’s still digital. We can now deal with 1,000 apples, or 1 million apples, or even .0000001 apples. I can send it with a click of a button, and I can still drop it in your digital pocket if I was in Nicaragua and you were all the way in New York. I can even make other digital things ride on top of these digital apples! It’s digital after-all. Maybe I can attach some text on it — a digital note. Or maybe I can attach more important things; like say a contract, or a stock certificate, or an ID card… So this is great! How should we treat or value these “digital apples”? They’re quite useful aren’t they? Well, a lot of people are arguing over it now. There’s debate between this and that economic school. Between politicians. Between programmers. Don’t listen to all of them though. Some people are smart. Some are misinformed. Some say the system is worth a lot, some say it’s actually worth zero. Some guy actually put a hard number: $1,300 per apple. Some say it’s digital gold, some a currency. Other say they’re just like tulips. Some people say it’ll change the world, some say it’s just a fad. I have my own opinion about it (and you can check out the link in the original article). That’s a story for another time though. But kid, you now know more about Bitcoin than most.

One day, Sean was working as a route setter at a rock climbing gym in Tennessee. The next, he was driving to San Francisco, without a plan, to start his career in tech. This is the story of his challenging, winding, but ultimately successful path to his first job as a software engineer. Written by Sean Smith: https://twitter.com/bonham_000 Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2JQwSXI Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: One year ago, I was working part-time as a route setter at a rock climbing gym in Tennessee. Today I’m working as a software engineer at a cyber-security startup in San Francisco. My journey to this point has been unforgettable and life-changing. And yet as challenging as everything was, I think that any sufficiently-motivated person could do the same. Knowledge has become democratized. All you need to reach a competitive level in your field is time and dedication. This is especially true for the field of software engineering. In 2016, my life was falling apart When I started learning to code in 2016, I guess you could say my life was falling apart. I’d gone to college as a pre-med student, with degrees in biochemistry and anthropology. But I quickly became disenchanted with science and medicine, and left college with no clear path. I started working as a routesetter at rock climbing gyms for almost 2 years, but things were not going so well. I knew I was in need of a big change. I had been putting off learning to code for a long time, but I knew this was what I wanted to do. Finally, on my birthday in 2016, I committed to learning to code. I didn’t look back. At this point in time, I was vaguely familiar with the coding bootcamps that have become quite ubiquitous over the last few years. Luckily, I quickly discovered freeCodeCamp. When I realized that finishing their curriculum entailed writing software for non-profit organizations, I promptly joined and resolved that I would finish freeCodeCamp’s open-source curriculum before even considering a bootcamp. freeCodeCamp rapidly became the core of my education. I supplemented it with many other resources, such as podcasts, tutorials, open-courseware, and healthy doses of documentation and Stack Overflow when needed. Typical days involved me working through freeCodeCamp challenges and projects, which allowed me to progressively improve my skills. When sitting and writing code became unproductive, I would absorb material through other channels: audio, video, and so on. I moved back and forth between different learning methods, which was very useful in maintaining a strong level of engagement and focus. This was basically my process, and it allowed me to dedicate many hours to learning. Here it is by the numbers (roughly estimated): Total duration learning: less than 12 months Total hours: ~2,500 Total projects completed: 70+ Total CS courses watched: ~10 Total GitHub commits: 1,500+ Total lines of JavaScript written: 20,000+ Most of this learning took place in Knoxville, Tennessee, where I was living at the time. I had a strong desire to move to one of the major tech cities, so one day I woke up and naturally decided it was time to drive to San Francisco. That’s about exactly how it happened. That night I left, and about 3 weeks later arrived in the Bay Area. Plenty of time to listen to podcasts on the road. Arriving in San Francisco for my first real job search After arriving in San Francisco and completing the core freeCodeCamp curriculum (front-end, data visualization, and back-end certifications) I had a brief go at job applications. Around 65 or so. Literally no response. Remember, I had just driven into the Bay Area from across the country. I had no idea how competitive it would be, nor how much my skills were even worth to employers at their current level. Did freeCodeCamp actually measure up to the education of an in-person coding bootcamp? These feeler applications gave me a clear reading: I had to do more. The market is pretty competitive. So I rapidly revised my plans, extended my time horizon, and reached out to freeCodeCamp to begin a non-profit project, since I was now eligible to start one. Meanwhile, I began networking in the city as much as possible. The networking came easily enough, as freeCodeCamp has many self-organized campsites throughout the world’s cities. I got a quick response from freeCodeCamp’s team about the nonprofit projects. Some of my React projects had caught the eye of Michael D. Johnson and Quincy Larson, and they asked me whether I’d be interested in helping write their React curriculum. (freeCodeCamp itself is a nonprofit.) I also helped build a conference management tool for the Conference on Crimes Against Women. I was very excited about the opportunity to give back to this awesome community, so I quickly accepted the challenge. My React and Redux challenges are being incorporated into their newly expanded curriculum, which is now live in beta form live here. In addition, I chose to advance my timeline to 2017. I would continue studying on my own for the remainder of 2016 before applying for jobs again. I left San Francisco, droving north through Portland and Seattle to Bellingham, Washington. It was during these weeks in the Pacific Northwest that I worked non-stop to complete the React and Redux challenges. I collaborated with another freeCodeCamp contributor from New York, Peter Weinberg, and built around 80 coding challenges in total. This was probably one of the key moves that helped set my resume apart, because it represented a significant project that served a real-world organization’s needs. In late December, we finished the initial draft of the challenges and moved them into an official alpha release which is still generating feedback from the community. My triumphant return to San Francisco Back in San Francisco, I was almost ready to dive into job applications again. I had decided to join Outco, a crash course in interview preparation for software engineers. I had always been pretty opposed to spending money at a coding bootcamp (partly because I didn’t have the money), but I chose to join Outco because in my view they are trying to serve a different purpose. Outco is specifically targeting the interview process for software engineers, a process which causes friction for many, even experienced and skilled engineers. Although I could write JavaScript pretty well at this point, I definitely was not prepared to solve arbitrary algorithm questions on a whiteboard. That’s one of the key areas Outco tries to prepare students for, because, for better or worse, whiteboarding remains a favorite interview tactic of tech companies. In addition, I could defer payment to Outco until after I got a job. And, a reality check: I had been going many months now at a strong pace of probably 50+ hours a week of coding and learning, and I was now literally risking it all on my ability to get a job in one of the most expensive and competitive cities in the US. I had already made a sincere effort to apply to companies and failed miserably! The pressure and stress were definitely bearing down on me at this point. I knew success was going to depend heavily on my performance of the next few months. I joined Outco because I expected that their structured program and support would prove indispensable in this last miles of my journey, and it did. 2017 arrived and I started Outco. I began to work even harder than before. Tons of algorithms and data structures practice, whiteboarding questions, technical questions, pair programming, mock phone screens, systems-design questions—you name it, and lots of it. Not to mention applying to jobs again, and a lot more than I did the first time. And, of course, once you begin to get responses from companies it becomes very time-consuming (not to mention very stressful) to begin juggling all of these interviews at once. Practicing for interviews everyday is hard enough. Standing in front of a whiteboard in a real interview as they ask you about binary trees is much harder (and yes, interviewers asked me about binary trees). Again, the numbers tell the story more eloquently: Total applications: 192 (including the 65 from 2016) Total phone interviews: 17 Total take-home code challenges: 6 Total technical screens: 5 Total onsites: 3 Total offers: 1 Total time to offer: 6 weeks Success Rate: 0.52% That one offer was from TruSTAR Technology, and I have been so happy to join their team! TruSTAR is building a platform that allows companies to share cyberintelligence data in order to prevent and mitigate cyberattacks. I’m working on the frontend side of their application and putting to use the JavaScript skills I gained through freeCodeCamp. The experience has been incredible so far, and I have been honestly surprised by how well prepared I have been to begin making meaningful contributions to their codebase. Lessons I learned over the past 12 months Now, finally, here is some advice I would have for anyone looking to do something like this: You need real-world skills and you have to learn a lot. That means a lot of hours of work, there’s no way around it. Passion helps. Building projects is an excellent way to learn, and once you know enough it is not very hard to find open-source projects or other high impact projects to work on. JavaScript and React are great to learn and in high demand! But learn what interests you. It’s critical that you cultivate a community of others who are learning to code or working as engineers. Network in your city. Network online. Find collaborative projects to work on. Ask for help. If you can afford it, try to have some patience. This is what I struggled with the most. There you have it — the journey that led me across the US to begin a career as a software engineer! I’m sure everyone’s path will look different, that’s part of the fun. Find your own path and don’t be afraid to disregard other people’s views if you believe strongly enough in your own. That includes my views. The opportunities in the tech industry are real, and if you want them badly enough, you can find a way there. As an engineer, your job will be to solve problems, and if you are self-taught, the first problem you must solve is how do you teach yourself? Cheers everyone, and happy coding! P.S. A huge shoutout and thank you to the entire freeCodeCamp community and everyone I mentioned in this article (and a few others: Archie, Christian, Susan, Beemer Girl and all my friends from home). You have all proven invaluable in helping me accomplish this goal.

In this episode, Oh My Zsh founder Robby Russell tells the story of how he unexpectedly launched one of the most popular zsh configuration frameworks out there. He shares his process, some mean tweets, and his advice for people starting open source projects. Written and read by Robby Russell: https://twitter.com/robbyrussell  Original article: https://fcc.im/2HzyjYN Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: How I unexpectedly built a monster of an open source project It was the summer of 2009. I found myself helping a coworker debug something in their terminal. As I attempted to type in a few command lines, I noticed that the prompt wasn’t responding to the shortcuts that my brain had grown accustomed to. Frustrated, I exclaimed, “when are you finally going to switch over to Zsh?!” (yeah, I was the type of annoying coworker that would constantly point out that X was better than Y when given the chance. In hindsight, I don’t know how they put up with me…but between you and me, I had a point.) At that point in time, I had been a daily Zsh user for a little over three years. Some of my #caboose friends shared a few of their .zshrc configurations within our IRC channel. After a few years, my .zshrc file grew into a tangled rat's nest. Honestly, I didn’t know what ~30% of the configuration did. I trusted my friends enough to run with it, though. What I did know was that I had some git branch and status details, color highlighting for a few tools (i.e., grep), autocompleting file paths over SSH connections, and a handful of shortcuts for Rake and Capistrano. Working on a machine with a default Bash profile felt remarkably archaic; I’d become dependent on these shortcuts. A few coworkers were happy to copy/paste the .zshrc file that I shared and begin using it. A few others wouldn’t because they knew that I didn’t know what some of it did. Fair enough. After a few attempts to convert them and getting nowhere, I opted for a different approach. First, I reorganized my .zshrc configuration, which involved breaking it up into a collection of smaller files. My thinking here was that this would a) help me better understand how all of these bits worked while b) helping educate my peers when they went to read the code. Pre-empting their next question, “how do I get this to work on my machine?”, I drafted the first setup instructions. Most importantly, I packaged all these files into a shiny new git repository. I figured that if I tossed it up on Github, my peers would be able to collaborate with me on improving it. While not a huge leap, it was a step above inviting people to copy/paste a text file from Pastie. On Aug. 28th, 2009, Oh My Zsh was born. …but, wait a minute!! Where are the themes? Where are the plugins? Installation scripts? Logo? This might come to a surprise to most of the Oh My Zsh user base, but none of those were features that I had considered. My goal with the project was not to build a framework for maintaining Zsh configurations but to share my own config with my coworkers so that they’d use Zsh. Within a day of sharing it with all of my coworkers, everyone at Planet Argon had migrated from Bash to Zsh. Victory! …or so I thought. The first feature request came in the next day. “How do I customize MY prompt?” Two coworkers asked me how they could customize their prompt. They wanted to change the colors and the information that was displayed. What the hell!? Wasn’t my prompt compelling enough for them? So nitpicky. ;-) I pointed to the prompt.zsh file and said they could modify that. Quickly, this became an issue as they now had their own version of that file. As a result, this would add some complexity if we all wanted to share some of our shortcuts and features as we’d have conflicts to deal with. Hmm… So, a day after first announcing Oh My Zsh on my blog, I began introducing the initial concept of themes. Meanwhile, I got my first external pull-request from Geoff Garside to add a few aliases for TextMate. (Notice how that went straight into a catch-all aliases.zsh file) A day later, another theme was sent over. Groovy, I better add a link on the README to see some screenshots on the wiki. Within a month, we had a dozen themes contributed to the project. This began to be a really popular aspect to Oh My Zsh and we had to start hitting the brakes on accepting themes once we passed 100. (we’re currently at ~140 and rarely accept new ones) Simplifying setup with an installer It occurred to me that the initial setup was requiring people to run a handful of commands. Rather than asking people to re-type and/or copy/paste a handful of commands, I felt that it would be more efficient for both parties (as it’d reduce the questions my coworkers would have when they hit a problem and/or skipped a step). An installer was born. My initial thoughts were to handle save folks a few steps by automating the installer. If everyone ran the same commands, then we could cut down on human error (skipping a command, typos, etc.). I also wanted to be mindful that people might be switching from either Bash or an existing cobbled-together Zsh configuration. To help them with a possible switch back to the previous shell, we made a backup of their original configuration file. Finally, we’d switch their default shell to Zsh. “Hooray! Oh My Zsh has been installed.” Oh, right. How will people be able to stay updated with the new changes to the project? The next day, I added an upgrade script that strolls over to the Oh My Zsh directory, fetch updates from the git repository, and returns you to your previous working directory. Far from rocket science. About three weeks later, it became obvious that my coworkers weren’t manually keeping up with all of the new updates to the project. Rather than reminding them to do that from time-to-time, I added functionality that would periodically prompt the user to check for updates. Up until this point, this felt like the most complicated piece of code in the project. I wish that I could remember who gave me the great idea to use an epoch value here. In my opinion, it was also the turning point for the project. While a handful of people were using it, this functionality would allow nearly every user to stay up-to-date on project changes and more importantly, stay engaged. When they would run the updater, they’d see a list of files changed and that would, subtly, introduce them to new features… a la, “I wonder what that theme looks like..” Sadly, not everyone has been a fan. Despite a few vocal opponents over the years, I’ve stood by my decision to keep this as a default setting. Back in 2012, we made a change to reduce the frequency of auto-update prompts by 50%. The auto-update has allowed us to ship new features, performance improvements, and bug fixes without relying on everyone manually doing it. I’m convinced that this feature has helped keep the community engaged. This Muffin Needs Candy While the project was attracting a lot of themes, I really felt like the project could benefit from branding. My solution? Ascii art. I have no idea what prompted the git commit message. My thought process here was… sure, you get a bunch of useful shortcuts and themes when you begin using Oh My Zsh, but I really felt like the first impression after the installer would run was an opportunity to delight new users. People have been asking me to print shirts with the ascii art for quite some time. (we’ll likely do that this summer — follow us on twitter) Plugins Ten months after open sourcing the project, users had begun to request the ability to not have everything get loaded up. For example, a Python developer might not need the Rake and Capistrano related aliases to get loaded like a Ruby developer would. So, we implemented a basic plugin system that would allow folks to decide which to load on initialization by changing a value in .zshrc. When this feature was released, there were five plugins bundled. Within a few months, I started to get pull requests for new plugin ideas. Within a year, I had accepted over 40 plugins. Within two years? Over 70 plugins. Currently, we have plugins for adb, ant, apache2-macports, archlinux, autoenv, autojump, autopep8, aws, battery, bbedit, bgnotify, boot2docker, bower, branch, brew, brew-cask, bundler, bwana, cabal, cake, cakephp3, capistrano, cask, catimg, celery, chruby, chucknorris, cloudapp, codeclimate, coffee, colemak, colored-man-pages, colorize, command-not-found, common-aliases, compleat, composer, copydir, copyfile, cp, cpanm, debian, dircycle, dirhistory, dirpersist, django, dnf, docker, docker-compose, emacs, ember-cli, emoji, emoji-clock, emotty, encode64, extract, fabric, fancy-ctrl-z, fasd, fastfile, fbterm, fedora, forklift, frontend-search, gas, gem, git, git-extras, git-flow, git-flow-avh, git-hubflow, git-prompt, git-remote-branch, gitfast, github, gitignore, glassfish, gnu-utils, go, golang, gpg-agent, gradle, grails, grunt, gulp, heroku, history, history-substring-search, httpie, iwhois, jake-node, jhbuild, jira, jruby, jsontools, jump, kate, kitchen, knife, knife_ssh, laravel, laravel4, laravel5, last-working-dir, lein, lighthouse, lol, macports, man, marked2, mercurial, meteor, mix, mix-fast, mosh, mvn, mysql-macports, n98-magerun, nanoc, nmap, node, npm, nvm, nyan, osx, pass, paver, pep8, per-directory-history, perl, phing, pip, pj, pod, postgres, pow, powder, powify, profiles, pyenv, pylint, python, rails, rake, rake-fast, rand-quote, rbenv, rbfu, rebar, redis-cli, repo, rsync, ruby, rvm, safe-paste, sbt, scala, scd, screen, scw, sfffe, singlechar, spring, sprunge, ssh-agent, stack, sublime, sudo, supervisor, suse, svn, svn-fast-info, symfony, symfony2, systemadmin, systemd, taskwarrior, terminalapp, terminitor, terraform, textastic, textmate, thefuck, themes, thor, tmux, tmux-cssh, tmuxinator, torrent, tugboat, ubuntu, urltools, vagrant, vault, vi-mode, vim-interaction, virtualenv, virtualenvwrapper, vundle, wakeonlan, wd, web-search, wp-cli, xcode, yii, yii2, yum, z, zeus, zsh-navigation-tools, zsh_reload. In total… 214 plugins. Admittedly, not everyone has been impressed by this. I do agree that could be drastically improved. The few times that I considered it, I found the proposed approaches to be too complicated for folks who aren’t yet familiar and/or comfortable with the terminal. Perhaps a more sophisticated approach for version 2 of the framework. (more on this later) There has, also, been a part of me that has felt like this project would only be of interest to people for a few years. As users gained more experience and/or as technology evolved, the framework would be left behind by shiny new projects that solved problems far better than we had. I never thought Oh My Zsh would still be building momentum nearly seven years later. Where do all these new users keep coming from? I ❤ you people! While I have many stories to share (and intend to write more on this topic), I wanted to speak to those who have been debating the idea of open sourcing a project. Eight Considerations For Your Open Source Project Don’t start with a wildly ambitious goal. Start your project with a simple, attainable goal. What does success look like? In my scenario, I wanted 1–2 people on my team to use my scripts. The project was a success in under 24 hours. Everything since has been extra-credit. Don’t try to account for every scenario. If I had gotten hung up on some long-term details for the project, Oh My Zsh would never have happened. Nearly everything that has been added to the project has come organically post-initial release. One of the beautiful aspects of an open source project is that your user base can help shape it. Don’t try to make it perfect. Worrying how other people are going to react about your code shouldn’t be your biggest concern. Does it work? How do they feel when they’re interacting with it should be a higher concern. In my case, I’ve had some great contributors over the years who have helped tidy up and improve the quality of the code that I originally released. Rarely has anyone said anything critical about my old code — maybe they should have, though. ;-) Don’t try to be everything to everyone. There have been a few points in the history of the project where we hit a crossroads. In particular, there was a time when a huge rebuild was proposed, which I was quite excited about until I was able to wrap my head around some of the changes. As a result, a fork was rebranded and we agreed to follow different paths. Not everyone was happy with my decision here, but it was during this period that it became clear (to me) that I wanted to focus my attention on folks who weren’t too comfortable with the terminal and/or git. Don’t stop thanking contributors. If anybody helps your project out, please let them know how much you appreciate their effort. I can’t thank my contributors enough. One of my biggest self-critiques related to this project is that I’ve not been consistent enough in being vocal about my appreciation. There are 910 people from all over the world who have their code accepted into the master branch of Oh My Zsh at the time of writing this. It’s such a long list that Github can’t even list them all. In particular, thank you. (you know who you are) Don’t forget the documentation. Over the years, documentation of plugins and functionality has been vital to helping inform users on how to take advantage of the framework. I wish we had adopted this convention several years before. The README file is going to be seen the most…so make it count. In my case, I opted to introduce people to my personality and dry sense of humor. Honestly, seeing tweets like this means the world to me. Don’t forget about the rest of your life. Again, I never anticipated the project turning into what it is today. Are you familiar with the anecdote about the frog in a pot of boiling water? It took me 3–4 years, too many, to finally bring in another person to help maintain the project. I kept thinking that I could catch up with all the open pull requests and issues. What I kept telling myself was that folks who know how to fork the project can make their desired changes and work off of that, so reviewing and approving pull requests is a nice-to-happen versus a need-to-happen. In practice, it’s somewhere in between. I do feel a bit bad for old pull requests lingering, but I also don’t keep Oh My Zsh as one of the top few projects on my plate. Outside of Oh My Zsh, I run a 19-person agency, play guitar in an instrumental post-rock band, sit on the board of directors of a local homeless shelter non-profit, travel with my camera a lot, ride my motorcycle, ride my bicycle, and try to keep a social life with my friends. Oh My Zsh fits somewhere in amongst all of these. It’s not at the top of my priority list. It’s not at the bottom. It’s somewhere between. This isn’t an excuse to not being able to keep up with the community, but more of a reminder that those other things should matter to you, too, if you’re about to start your own project. (I will write more on the topic of leading an open source project w/maintainers in another story… ❤ are you following me? ❤) Don’t forget to have some fun. When you start your project, decide if this is going to be serious work time or play time. Perhaps it can be somewhere in the middle. Oh My Zsh has, always, been a play time activity project for me. Knowing that one of my playful projects has been and continues to be enjoyed by people is such a wonderful feeling. Some might call it a passion project. I call it playtime. Interested in my fun open source project? You can learn more at http://ohmyz.sh.